Forward-deployed AI work has one honest definition: you walk into someone else's live operation, rebuild parts of it on AI agents, and leave the team more capable than you found it. Not a demo, not a pilot deck — a running system the team keeps using after you're gone.
I rebuilt my own company's operations this way first — an orchestrator of role agents, a client-communication relay, a nightly autonomous dev contour, telemetry on every LLM call — before proposing the approach to anyone else. That origin shaped the playbook: every principle below exists because skipping it broke something real, and every claim comes with a number from that system. Some client work behind this sits under NDA; what I share are the methods and the shape of the results, not anyone's data. That discipline is part of the job.
The framework is five principles. The thread connecting them: an agent earns its place in a live operation the same way a new hire does — grounded in how things actually work, fenced by real permissions, judged on delivered work, with costs visible and autonomy expanded only as trust accrues.
1. Ground definitions in the system, not the system in definitions
An agent's definition — prompt, config, role file — is documentation, and documentation rots at the speed of the code under it. Treat the running system as the source of truth and reconcile definitions to it on a schedule, not the other way around.
Case. I opened the definition of my most-used agent after a few weeks and found three drifts: the config named a different model than the code called; the described execution path no longer existed; and the path to the identity layer pointed at a missing directory — so personality silently failed to load for all eight role agents at once. The fix for the worst drift was one line. The same week, the skill layer showed the same disease at scale: 48 skills split across two stores, 20 diverged, 21 with broken metadata. Merging them into a single git source of truth turned two mutually lying copies into one accountable one. Drift count after reconciliation: zero — until the next cycle, which is the point: grounding is a loop, not an event.
2. Boundaries live in tools, not prompts
Anything you forbid in prompt text, the model can ignore under pressure. Anything you forbid in the tool layer, it cannot. Path confinement, blocked command patterns, commit-only-never-push, bounded iterations, timeouts — safety welded into what the agent physically can do.
Case. My autonomous coding agent runs a confined loop: it can read and write only inside its sandbox, destructive and push commands are blocked at the tool level, iterations are capped, every run times out. Given a live spec, it opened an isolated branch, did the work, committed locally, and stopped — not because the prompt asked nicely, but because the rails made anything else impossible. In a client deployment this is the difference between "we trust your prompt" (they won't) and "we reviewed your permission model" (they can).
3. Prove by running, not by reading
A definition can be proofread to the last character and the agent still may not work. Roles are verified by cheap, isolated, live runs — and third-party tools are verified by testing the one risk that would kill the adoption, before touring the features.
Case. After reconciling the agent's definition, I proved the role layer with a disposable-repo run: short spec, four iterations, one local commit on an isolated branch, total cost $0.018. That commit — not the tidied config — was the evidence. Same logic outward: before adopting a deck-generation tool for bilingual client work, I tested only whether Cyrillic and Chinese survive side by side in native text objects. One go/no-go test decides; everything else is secondary.
4. Meter every run from day one
The $0.018 above is not a flourish — it exists because cost telemetry was wired in before it was needed. Every agent run should emit spend and outcome events into a log something reviews. Unmetered autonomy is unaccountable autonomy, and in someone else's operation, unaccountable means dead on arrival.
Case. Every LLM-backed routine in my system records spend per agent per run; autonomous runs emit structured events (task done, budget spent, fallback triggered). The discipline has teeth because gaps are visible: an internal audit found one content skill invoked 60 times while only 12 runs landed in the eval log — roughly 20% compliance — meaning 80% of runs were invisible to the improvement loop. You can only fix a leak you can see; metering is what makes the seeing possible.
5. Autonomy is earned through gates
Full autonomy is not the goal — calibrated autonomy is. Place a human gate wherever trust hasn't been earned yet, and move the gate outward deliberately as evidence accumulates. The gate's position is your trust dial, and it should be visible to the client team.
Case. My nightly dev contour wakes at 03:00, takes exactly one task from the tracker, and opens a pull request — it never merges; merging is human. My client-communication relay auto-drafts replies grounded in a voice corpus — but every outbound message passes operator approval. Neither gate is a limitation to apologize for; both are the reason the systems are allowed to run at all.
Choosing what to rebuild first: the business lens
The playbook says how to deploy; it doesn't say what. For that I use a companion framework, Three AI Business Effects: less money (cut cost in existing processes) → more money (earn more on the same base) → new money (earn where the business never earned). Forward-deployed engagements should almost always enter through less money — rule-describable, judgment-light work with the fastest ROI and the cleanest before/after numbers — and use the trust earned there to reach the deeper effects. Segment and job selection on top of that is its own method (AI-CPO), but the entry rule alone prevents the most common FDE failure: starting with the impressive thing instead of the measurable thing.
How to apply: the first week inside an operation
- Map the real system, not the org chart. Read the code, the logs, the actual message flows. Write definitions from what runs.
- Pick one judgment-light process with visible cost (the less money entry) and a numeric before-state you record now.
- Build the confinement before the agent. Decide what the agent physically cannot do; implement that in tools, then write the prompt.
- Wire telemetry before the first real run. Spend per run, outcome events, an eval log — even a JSONL file is enough.
- Run the proof. Cheap, isolated, live — a disposable-scope run whose artifact (a commit, a draft, a filed record) the client team can inspect.
- Place the gate conspicuously. Human approval at the trust boundary, shown to the team as a feature, not a caveat.
- Schedule the grounding loop. A recurring reconcile of definitions against the system — because by principle 1, they are already drifting.
An agent that survives this week has something most AI initiatives never get: a number for what it costs, a fence for what it can't do, an artifact proving what it did, and a team that watched all three happen. That — not the demo — is what forward-deployed work is for.