How we scope, quote, and ship an agent

A fixed-scope engagement only works if the scoping is genuinely rigorous, the quote is genuinely binding, and there's a real answer for what happens when reality doesn't match the plan. Here's what that looks like in practice, stage by stage.

1. Scope call

Every engagement starts with a call, usually 60 to 90 minutes and occasionally split across two sessions for more tangled workflows, with whoever actually owns the process today, not just the executive sponsor. We ask for the workflow as it currently runs, including the parts that are embarrassing: the spreadsheet nobody admits to using, the exception that gets handled by "whoever picks up the phone," the step that only one person on the team actually knows how to do.

Specifically, we're mapping:

• Inputs: what triggers the workflow, and in what format (an email, a form submission, a webhook, a phone call transcript).
• Systems touched: every tool the workflow reads from or writes to, including the ones nobody thinks to mention until the second call.
• Decision points: where a human currently exercises judgment, and what information they're using to make that call.
• Edge cases: the 10-20% of cases that don't fit the happy path, because that's usually where most of the actual human time goes.
• Success criteria: what "working" means in numbers, not adjectives. "Faster" isn't a criterion; "under two minutes from ticket creation to first response, 90% of the time" is.

We leave this call with either a scopeable workflow or an honest answer that it isn't scopeable yet, usually because the client hasn't documented the decision logic themselves. In the latter case, we'll sometimes propose a short, separately priced discovery engagement to document the workflow before quoting the build; we won't quote a fixed price against something nobody can describe.

2. Fixed quote

Within one to two business days of the scope call, you get a written quote: a fixed price, a fixed delivery date, and a one-page scope document listing exactly what's included: which systems get integrated, which edge cases are handled automatically versus escalated, and what counts as acceptance. This document is what we build against and what we're held to. It is also, deliberately, short enough that someone non-technical on your side can read the whole thing and know what they're getting.

Anything raised on the scope call that didn't make it into the written scope isn't part of the engagement, which is why we push hard during scoping to surface everything up front rather than leave it implicit.

3. Build & weekly review

We build in one- to two-week increments depending on total engagement length, with a working version available for you to test against real (or realistic sample) inputs at the end of each increment. Not a slide, not a Figma mockup, but an agent you can actually run inputs through. This is partly quality control and partly a deliberate check on our own assumptions: workflows described verbally on a scope call almost always reveal small gaps once someone tries to break the running system, and we'd rather find those gaps in week one than week five.

For anything client-side we need (API credentials, sample historical data, access to a staging instance of your help desk or CRM) we ask during week one specifically so that access delays don't eat into the timeline later.

4. Ship & integrate

Delivery means the agent is live inside the systems you already use, not a new dashboard you have to remember to check. If the workflow lives in Zendesk, Salesforce, an EHR, or an internal tool, the agent operates through that system's existing interface and APIs wherever technically possible. We do this because a technically impressive agent that requires your team to change how they work in order to benefit from it usually gets quietly abandoned within a quarter. We've seen it happen to other vendors' builds, and we scope specifically to avoid it.

5. Thirty-day hypercare

The 30 days immediately following go-live are included in every fixed quote. This isn't a courtesy. Real production traffic reliably surfaces patterns that didn't show up in scoping or testing: a phrasing of a request nobody anticipated, an integration edge case that only appears at a certain volume, a decision boundary that needs tightening once you see real outcomes. We monitor closely during this window and tune the agent against what actually happens, at no additional cost, before handing off to a standard support arrangement.

Tooling & architecture defaults

We don't lock every engagement into one stack, because the right architecture depends on the workflow, but our defaults reflect a bias toward boring, inspectable systems over clever ones:

• Agents are built on hosted foundation models accessed via API, not a self-hosted or fine-tuned model, unless a client's data residency or latency requirements specifically require otherwise.
• Every agent decision that affects a customer or a business outcome is logged with the inputs, the reasoning summary, and the action taken, so a human can audit any individual decision after the fact.
• We favor deterministic guardrails around the model wherever a wrong answer has real cost: hard-coded policy limits, explicit escalation rules, and validation steps that don't depend on the model "deciding" to follow them.
• Integrations use each target system's own API or, where no API exists, a narrowly scoped automation layer built specifically for that system rather than a generic browser-automation approach, which we consider too brittle for anything customer-facing.

Data handling

Specifics are always finalized in writing during scoping, since requirements vary meaningfully by industry (see the healthcare and fintech case studies for what that's looked like in practice), but the defaults are: data stays within infrastructure covered by a data-processing agreement with the model provider, nothing is used to train or fine-tune a foundation model, and access to logs containing customer data is limited to the engineers actively working the engagement. For regulated data such as health information and financial account data, we scope the specific compliance requirements (HIPAA, relevant state lending regulations, and so on) as part of the scope call rather than treating it as an afterthought.

When it doesn't go to plan

Out of roughly 180 engagements, the delivery date has slipped twice. Once, a healthcare client's legal review of a data-sharing agreement took three weeks longer than either side anticipated, pushing the go-live date by the same amount. We flagged it the day we saw the review stalling, not the week the deadline arrived. The other time, a scope call underestimated the complexity of a legacy system's undocumented API, and we absorbed the additional two weeks of engineering time at no extra charge, because the estimation error was ours.

We'd rather tell you this than pretend the record is spotless. A vendor whose website claims a 100% on-time record either hasn't done enough engagements to have hit a hard case yet, or isn't being straight with you about the ones that didn't go cleanly.