Topology and handoffs
Deciding who supervises whom, and what crosses the boundary. Handoffs are typed payloads with required fields, not pasted summaries — a summary drops the implicit decision the next agent needed most.
Handoff contractsAI & data
Agent teams that finish work you can audit
Several agents sharing one goal, one state store and one budget. We build the coordination layer around them: who decides, who acts, what gets checkpointed, and where a human signs off.
- Fixed scope
- Demo in 14 days
- Full IP transfer
- 30-day warranty
Coordination is the hard part
Agentic means the system decides its own next step. One agent doing that inside a bounded job is AI Agent Development. This is the harder case: several agents sharing a goal, a state store and a budget, running long enough that something fails mid-run. The agents are the easy part. What breaks is quiet — one agent hands a plausible wrong answer to the next, which believes it, and the run finishes looking successful.
So the control plane is what we actually hand over. The agents themselves are prompts and tool definitions; a competent team rewrites those in a week. What takes months is everything underneath — the part that survives a crash mid-run, refuses to send the same invoice twice, stops short of an irreversible action, and leaves a trace someone can read three months later. That is the half nobody demos, and the half that is still there in year two.
| What is true of this work | What it forces | What we do about it |
|---|---|---|
| Step errors multiply, not average | Fewer boundaries than feel natural | Single-threaded baseline before any split |
| Runs outlive the process running them | State cannot live in memory | Checkpoint to Postgres after every step |
| No orchestrator gives exactly-once side effects | A step can execute twice | Idempotency keys at every tool boundary |
| Some actions cannot be undone | Autonomy must be per action class | Approval gate before irreversible writes |
| Agents resend history at every step | Cost grows with run length | Per-run token and step ceilings |
In scope
- Agent topology and typed handoff contracts
- Durable orchestration with checkpoint and replay
- Approval queue, escalation rules, audit trail
- Trajectory eval suite and cost dashboards
Not in scope
- Single-agent assistants with one bounded job
- Building the source systems agents call
- Warehouse and pipeline work feeding retrieval
Handled by
- AI Agent DevelopmentOne agent, one bounded job, no supervisor.
- Software IntegrationThe APIs and events the agents call.
What we build
Durable run state
A run that waits days for a human outlives the process that started it. State lives in the database, not memory, so a crash resumes at the last completed step.
Durable orchestratorTool surface and access
Every system an agent touches becomes a declared tool with a schema, a scope and its own identity. Agents get short-lived credentials for the action in front of them, not standing keys.
Scoped agent credentialsApproval and escalation
Reversible steps run unattended; irreversible ones queue for a person who sees the proposed action, its arguments and its reasoning. Escalation rules are explicit: an uncertain agent stops rather than guessing.
Approval queueTrajectory evaluation
Scoring the path, not just the answer. A run can reach the right result by a route that fails the next case, so we grade tool choice, recovery and step count.
Trajectory eval suiteBudgets and kill switches
Each run carries a step ceiling, a token budget and a wall-clock limit, enforced by the orchestrator, not hoped for. Spend is attributed per workflow, and one flag disables a misbehaving agent.
Per-run cost dashboardsHow the work runs
- 01Weeks 1–2
Trace and baseline
We shadow whoever runs this workflow today and draw it as a graph, every action classed reversible or not. Then one linear agent with the real tools, scored on real jobs. That score is the bar.
You getWorkflow graph and scored baseline
- 02Weeks 3–5
Split and supervise
We split only where the baseline stalls: context too large, tools too many, branches truly independent. Each worker gets a narrow brief and typed handoff contract. A supervisor holds the plan, budget and stop condition.
You getTopology, handoff contracts, run budgets
- 03Weeks 6–9
Build the control plane
The unglamorous half: durable state and replay, idempotent writes, per-agent credentials, the approval queue and its interface, structured traces, per-run cost attribution. This is where a demo becomes a system your on-call engineer can reason about.
You getControl plane and audit trail
- 04Weeks 10–14
Shadow then widen
It runs beside your team on live work, proposing rather than acting. Every disagreement becomes a test case. Autonomy rises one action class at a time, on evidence, with the eval suite and runbook handed over.
You getAutonomy ladder and production runbook
What you are handed
- Workflow graph with reversible and irreversible actions
- Agent topology diagram with handoff contracts
- Running multi-agent system in your cloud
- Durable orchestrator with checkpoint and replay
- Approval queue and escalation interface
- Trajectory eval suite wired to CI
- Per-run cost and latency dashboards
- Scoped agent credentials and audit log
- Runbook, failure playbook, handover session
Typical stack
Orchestration and runtime
LangGraphTemporalCeleryRedis StreamsFastAPI
State and memory
PostgrespgvectorRedisObject storageAlembic
Tools and access
Model Context ProtocolOpenAPIOAuth 2.1HashiCorp VaultDocker sandboxesPlaywright
Evals and observability
OpenTelemetryLangfuseGrafanaSentrypytestGitHub Actions
The calls we make, and why
Do we actually need multiple agents, or is one enough?
One agent, until it demonstrably is not.
Splitting feels like decomposition and behaves like distribution: every boundary is a new failure surface, and context you have paid for gets re-sent across it. If steps depend on one another, keep them in one thread and compress the history rather than sharding it across agents.
We’d choose otherwise whenthe tool surface outgrows one context, or branches are genuinely independent — separate suppliers, separate documents.
Should the agents plan freely, or should we code the plan?
Code the skeleton; let the model decide inside a step.
Deterministic control flow gives you retries, resumption and a diff you can review. Free-form planning gives you a system that solves the same task differently every Tuesday, and a bug you cannot reproduce. Most workflows that look open turn out to be branches nobody wrote down.
We’d choose otherwise whenthe task space is genuinely open — research, investigation, triage across cases nobody has enumerated.
Agent framework or durable workflow engine underneath?
Both, at different layers — reasoning above, run state below.
The agent framework holds reasoning and tool calls; a durable engine holds the run — retries, timers, human pauses, replay after a crash. Pick one and you rebuild the other badly: a framework grows a queue, or a workflow engine grows a prompt loop nobody can evaluate.
We’d choose otherwise whenruns are short, read-only and finish inside a request — the engine is then pure overhead.
How much autonomy should it have on day one?
Full autonomy on anything reversible, a gate on everything else.
Refunds, customer emails, deletions and ledger writes start gated; reads, drafts and internal updates do not. An action class moves up the ladder when its approval queue clears an acceptance rate you set in advance, over an agreed number of runs.
We’d choose otherwise whenevery side effect has a cheap, complete rollback and the blast radius is one internal record.
This fits if
- A repeatable process spans four or more systems and takes hours
- You run a single agent and it stalls on branching work
- Auditors need to see who decided what, and why
- Volume is high enough that cost per completed task matters
- You have people who can review proposals and settle edge cases
Look elsewhere if
- You need a conference demo — a scripted flow is cheaper
- The process is undocumented and your team disagrees on correct answers
- One agent with good context already handles this work well
EngagementFixed-scope build
Typical length8–14 weeks
How it startsSend us the one workflow you would automate first; we return a topology and a fixed price.
Questions we get asked
What does it cost to run, not just to build?
Running cost is driven by tokens per completed task, and agents are expensive because they resend accumulated history at every step. We size this during discovery on real jobs, not a hello-world prompt, then design against it: compaction between steps, smaller models for classification, caching, and hard budget ceilings per run. A per-workflow cost dashboard ships from week one.
Who owns the code, the prompts and the eval set?
You do, all of it, on full IP transfer at the end of the engagement. That covers orchestration code, prompt and policy files, the golden task set with its expected outcomes, the traces we collected, and the infrastructure definitions. The eval set matters most — without it, the next team cannot change a prompt without guessing.
What happens when the agents get something wrong in production?
You find out from the trace, not from a customer. Every run is recorded step by step with inputs, tool calls and costs, so a bad outcome can be replayed and the exact step identified. Irreversible actions were gated, so the blast radius is usually a draft. The failing case then becomes a test in the eval suite.
How do you prove it works before we trust it with real traffic?
With a scored task set and a shadow period, in that order. We agree twenty to fifty real jobs with known-good outcomes, run each several times because agents take different routes on identical input, and report pass rate, median steps and cost per task. Then the system runs alongside your team, proposing actions it cannot take.
Can this run inside our own environment and satisfy an audit?
Yes — it deploys into your cloud account and your network, with data staying where your policy says it stays. Each agent gets its own identity and short-lived scoped credentials rather than a shared service account, and every delegation, tool call, approval and result is written to an append-only log built for that question.
Often bought alongside
Tell us the requirement.
Thirty minutes with the engineers who would build it. You leave with a scope, a timeline and a fixed price — or an honest no, and the reason why.