Agentic Systems Engineering·Engagement model
We work inside your organization, not alongside it.
An engagement is a standing capacity your team draws against, for work described in advance — each capability with a named deliverable and a published delivery target. You are not buying a report, and you are not buying hours.
This page is about how working together actually runs. What our engineers do once they are in is on the practice page.
Why capacity, and not a fixed date
Most engineering programs that slip do not slip on the build. They slip because an environment was not ready, an access request sat in a queue, a decision needed someone who was on leave, or a dependency belonged to a team that had not been told the project existed.
None of that is unusual, and none of it is a failure of planning — it is what large organizations are like. But under a fixed-deliverable contract, all of it lands on a date the supplier is holding, and the engagement turns into a discussion about whose fault the delay was. That discussion is expensive and nobody wins it.
Capacity is consumed as work is drawn down. If your side is not ready, the clock is yours — and there is no missed date to argue about.
We would rather you drew down slowly because an environment was not ready than have both of us in a room defending a date that depended on something neither of us controlled.
It also means we are never quietly pricing your delay risk into a number and hoping it does not land.
Five phases
An engagement can begin at any of them — most teams come to us somewhere in the middle. What does not change is that each phase has someone on your side it belongs to.
- 01
Assess
Whether this is tractable with agents at all — the problem, the data it depends on, where it will fail, and what it costs to run. This is the phase where the answer is sometimes no.
Who you work with
Your sponsor and the engineers who own the workflow
- 02
Architect
Task decomposition, orchestration topology, tool and MCP boundaries, state and memory, where a human stays in the loop, and what happens when a step fails. Validated by building the risky part rather than by drawing it.
Who you work with
Your architects, and your security reviewer early rather than late
- 03
Activate
The build. Production code in your repository, through your review process, deployed and profiled for cost and latency. This is where the five delivery stages run.
Who you work with
Your engineers, your CI, your review gates
- 04
Adopt
Handover as a deliverable rather than an afterthought: runbooks, on-call, and the security and compliance review passed rather than deferred. Your engineers own it and can change it without us.
Who you work with
Your on-call rota and your auditors
- 05
Optimize
Eval suites in CI that block merge on regression, drift detection, and automated re-baselining when a provider ships a new model version. This is the part that persists after we leave.
Who you work with
Your CI and your model-risk function
Where we interlock
A supplier that only touches one function is a supplier you have to translate for. Our engineers sit in your repository and your review process; capacity is drawn down inside your own delivery cadence rather than tracked in a system we own.
The row that matters most is the one that runs the whole width. Your delivery function is our counterparty for capacity — which is what puts the clock on the right side of the line.
Security and audit appear early on purpose. A compliance review that starts after the build is a compliance review that finds things too late to be cheap.
| Your organization | 01Assess | 02Architect | 03Activate | 04Adopt | 05Optimize |
|---|---|---|---|---|---|
| Executive sponsorOwns the outcome, clears the path | Executive sponsor: primary interlock during Assess | Executive sponsor: involved during Architect | Executive sponsor: involved during Activate | Executive sponsor: primary interlock during Adopt | Executive sponsor: involved during Optimize |
| PMOWork is drawn down inside your cadence | PMO: primary interlock during Assess | PMO: primary interlock during Architect | PMO: primary interlock during Activate | PMO: primary interlock during Adopt | PMO: primary interlock during Optimize |
| EngineeringOur engineers in your repo, through your review | Engineering: involved during Assess | Engineering: primary interlock during Architect | Engineering: primary interlock during Activate | Engineering: primary interlock during Adopt | Engineering: primary interlock during Optimize |
| CI / CDEval gates block merge in your pipeline | CI / CD: not engaged during Assess | CI / CD: involved during Architect | CI / CD: primary interlock during Activate | CI / CD: primary interlock during Adopt | CI / CD: primary interlock during Optimize |
| Security & complianceReviewed during the build, not after it | Security & compliance: not engaged during Assess | Security & compliance: primary interlock during Architect | Security & compliance: involved during Activate | Security & compliance: primary interlock during Adopt | Security & compliance: involved during Optimize |
| Model risk & auditEvidence as a by-product of delivery | Model risk & audit: not engaged during Assess | Model risk & audit: not engaged during Architect | Model risk & audit: involved during Activate | Model risk & audit: primary interlock during Adopt | Model risk & audit: primary interlock during Optimize |
Each turn starts higher than the last
The second workflow costs less to get into production than the first, because the harness and the evidence base already exist. That is the whole reason we instrument on day one instead of at the end.
- 01
The harness goes in on day one
Not at the end, and not as an upsell. It is how we know the thing we are building works.
- 02
Evidence accumulates in your tenant
Eval suites, baselines, and audit history — held by you, in your environment.
- 03
The engagement ends; the harness does not
It re-baselines when a provider ships a new version, whether or not we are still there.
- 04
Your reviewers have already accepted the format
The evidence a workflow produces is evidence the next one does not have to argue for.
- 05
The next workflow starts higher
Less to build, less to prove, less capacity to get there. Which is the whole point of instrumenting first.
Then back to 01, on the next workflow
How it is contracted
A master agreement and an order form, with the capabilities described up front. The structure is built so that drawing on something already described is an authorization against terms both sides agreed at the start, rather than a new negotiation each time.
Work that varies from a described capability, or that is not described yet, is handled by a short variation naming the deliverable and the date, within an envelope agreed at the start. Past that envelope, it goes back to your counsel.
How much friction that actually removes depends on your own approval thresholds and review policies. We would rather work that through with your procurement team while scoping than promise you a number of signatures now.
What we commit to
- Every draw against your capacity resolves to a named deliverable with a published delivery target. If it does not, it is not billable.
- A proposal you can take to procurement within two business days of a scoping call.
- A system running in production and a handover your engineers can hold — not a set of recommendations.
- We will tell you early if we think the answer is no. A workflow a script can do reliably should not become an agent.
- We do not write your business case. We will tell you whether it can be built, how, and what it costs to run.
Capacity and terms are sized per engagement. Ask and we will walk you through it.
Tell us what is stuck.
The first conversation is with the engineers who would do the work, not a sales qualification.