Price an Ask the Agent capability

What an Ask the Agent capability includes

A capability is not a workflow diagram and not a chatbot. It is a standing arrangement with a defined shape: the agent scans on a cadence, reads the complete history of a task, works out what is being asked, executes it against approved systems, verifies the result against the live platform, recovers when a safe recovery path exists, returns the task to whoever opened it, and leaves an audit record of every action with its before and after state.

Every one of those eight stages is real work. An estimate that prices only “connect the API and make the change” is pricing about half the capability, which is why implementations scoped that way tend to run over.

What an FDE does during an implementation

The work divides into roughly six kinds of activity. Diagnosis: understanding which real request the team keeps making and what currently blocks it. Access: getting approved API access configured so the agent can act without anyone handing over a credential. Context: loading enough about the client that the agent’s output is usable rather than generic. Action design: deciding exactly which families of change the agent may make, and which it must escalate instead. Verification: proving a change persisted rather than trusting a successful response. Handover: training the team and documenting how to ask.

None of these is optional, and their relative weight moves a lot between engagements. A client with organised brand and strategy material and one already-connected platform is a fundamentally different job from a client whose material has to be researched from scratch across four platforms that each need their own developer application.

Infrastructure setup versus capability implementation

These are separate line items and conflating them is the most common estimating error. Infrastructure is the machine, the runtime, the connected services, and the approved access paths — largely reusable, largely one-off. Capability implementation is the specific job the team wants done: the intake, the classification, the action families, the verification path, the reporting format.

Once infrastructure exists, the second capability on the same foundation is markedly cheaper than the first. But that saving is real only if the second capability genuinely reuses the access, the context, and the runtime. If it needs a different intake surface, a different control flow, or unique client context, most of the saving evaporates and the estimate should say so rather than assume the discount.

Initial API setup versus per-client rollout

A platform’s first connection is expensive in a way its tenth is not. The developer application, the consent screen, the access-tier request, the review evidence, and the business verification are organization-level work that happens once and then keeps paying off.

What repeats per client is smaller but never zero: the client granting access to their own account, mapping the specific accounts or resources that workspace may touch, confirming which actions are in scope there, and re-running the runtime proof. An estimate that charges the full setup again for every client is wrong; so is one that assumes a new client costs nothing because “the API is already connected”.

Why OAuth, developer access, and provider approval affect the estimate

Ad and analytics platforms do not simply hand out write access. Depending on the platform you may need a developer application, a consent configuration, an access-tier request with justification, a recorded demonstration for a reviewer, and a verified business entity behind it all. Each is preparation work with a real hour cost.

Crucially, none of that preparation guarantees approval, and the waiting is not work. An honest estimate separates the hours spent preparing a submission from the calendar days spent waiting on a verdict, and never implies that a provider will say yes.

How client context and the memory layer affect capability quality

The same capability, given the same permissions, produces very different output depending on what the workspace knows about the client. Who the audience is, what the offer is, which claims are approved and which are prohibited, who may request what, and where results should go. Without that, the agent produces work that is technically correct and commercially useless.

This is why context readiness is a single choice in the estimate rather than a checklist. Material that is ready and structured adds nothing. Material that exists but is scattered needs organising and checking for contradictions. Material that does not exist yet needs an intake process with the client. And where the positioning itself has to be researched and synthesised, that is a substantial piece of work that should be priced as one package rather than assembled from overlapping parts.

How a paid media optimization capability works

The worked example: a performance marketing manager opens a task asking to move budget between two campaigns within the approved monthly ceiling. The agent picks it up on its next scan, reads the whole thread including any clarifying replies, identifies which accounts and campaigns are meant, checks that the request sits inside the approved ceiling and the authorised accounts, makes the change, then reads the platform back to confirm the new budget actually took effect. It updates the task with what changed, and records the before and after state.

If the request had exceeded the ceiling, the agent would have stopped and escalated rather than executing. If the platform had accepted the change but not persisted it, that is reported as its own outcome — neither success nor rejection. That distinction is small to describe and genuinely difficult to build, which is why it belongs in the estimate.

Request intents, processes, and capabilities — what counts as what

Three levels, and mixing them up distorts an estimate badly in both directions.

A request intent is a kind of thing someone might ask for: change a budget, pause an ad, investigate tracking. Many different intents arriving through the same intake and travelling the same control flow are still one process. Counting eight intents as eight processes will roughly quadruple an estimate for no reason.

A process is bounded by its intake surface and its control flow. A second intake surface — the same kinds of request arriving from a messaging app instead of the project tool — is a genuinely separate process, because it has its own entry, its own validation, and its own reporting path. It is an additional process inside the same capability, not a second capability.

A capability is a different business job entirely. Reading and triaging client email is not a variant of paid media optimization; it is another capability, and it should be scoped, priced, and sold as one rather than folded in.

Why verification and recovery are not optional

A successful API response means the platform accepted a request. It does not mean the change took effect. Platforms accept changes that later fail validation, get reverted by a conflicting rule, or apply to a different object than intended. An agent that trusts the response reports success it cannot support.

So every capability that makes a change always includes: reading back from the platform after the write; three distinct outcomes rather than two — the change persisted, the change was rejected, or the change was accepted but did not persist; a bounded number of retry attempts, never re-running work already verified; recovery where a safe recovery path exists; return to the requester in every ending state; and a full audit record.

These are not a premium tier. They are priced inside the capability itself, and the calculator has no switch to remove them, because a version without them is a different and much less useful product.

When an action cannot be safely undone

Not every change has a way back. Each family of action is classified: some can be directly rolled back by restoring the previous value; some cannot be undone but can be corrected by a compensating action; some need a person to fix them; and some have no safe path at all.

That last category does not get an automatic rollback promise. It becomes a hard stop: the agent escalates rather than executing. Promising automatic recovery for an action that has none is the kind of claim that survives a sales conversation and fails in production.

FDE labor versus external waiting time

Implementation calendars are dominated by waiting, and implementation invoices should not be. Keeping them separate produces a more honest estimate and a much more credible timeline conversation with the client.

Implementation fee versus subscription versus running cost

Three different things that clients routinely merge into one number, and that a proposal should always separate.

The implementation fee is one-off work: setup, context, action design, verification, QA, training. The software subscription is the ongoing platform cost, which scales with workspaces and connected services rather than with activity. The running cost is what the capability consumes each month while it operates.

That last one is regularly underestimated, because people count only the requests that got handled. The agent scans on a cadence whether or not anything is waiting; each change costs a verification cycle on top of the execution; retries and recovery consume real calls; and any external tool the capability uses bills per use. A month with no requests at all still costs something. The calculator shows both the marginal cost per handled request and the total monthly figure including that standing baseline — and provider rates are always entered by you, because published rates change and a shipped rate table would go stale.

What happens during the first month

The first month after a capability goes live is when it either becomes part of how the team works or quietly stops being used. What makes the difference is reviewing what actually happened: which requests the agent handled well, which it misread, what context turned out to be missing, which assumptions were wrong, and which requests keep recurring in a form that suggests a repeatable improvement.

Not every recurring request should become a new skill. Most are a context gap, an update to something that already exists, or a training issue on the client side. Treating every repeated question as a reason to build something new is how a clean capability turns into an unmaintainable pile. The first-month work is priced as its own package so it stays visible rather than being absorbed into implementation and then skipped.

When discovery is required

Sometimes the honest answer is that the work cannot be priced yet. If a write path has not been verified on the platform in question, if recovery behaviour is unknown, if an existing automation already writes to the same objects and nobody has decided who owns them, or if the requirements are simply not clear enough — a number invented at that point is guesswork wearing a suit.

In those cases the calculator returns a discovery scope instead: what specifically has to be established, so that a real estimate can follow. Discovery is a normal, healthy outcome rather than a failure, and treating it as one is what keeps the estimates that do get produced worth trusting.

When an estimate is blocked entirely

Separately from discovery, some requests should not be quoted at all: work that requires exposing a raw credential, work that requires bypassing the access policy, a request aimed at the wrong client account, a scope that exceeds approved limits by design, or an action that is simply prohibited. The calculator names the specific condition and produces a readiness report rather than a price.

What a successful implementation proof includes

Success is not a demo. It is: the correct workspace is recognised; the correct client account is mapped; approved team members can use the capability; the agent performs the selected action families; every requested change is verified against the live platform afterwards; rejected and accepted-but-not-persisted outcomes are reported honestly rather than smoothed over; nobody is ever asked to paste a credential into a chat; no raw secret appears anywhere; the team knows how to ask and what requires escalation; and the ownership of future context and skill updates is clear.