Cohere’s North 2 puts a budget around the AI agent. What happens when it runs out?

Imagine an AI assistant preparing a weekly supplier report. It has gathered the invoices, calculated the exceptions and begun updating a shared dashboard when its spending allowance is exhausted. Stopping is financially prudent. Stopping without recording what changed can be operationally expensive. This hypothetical is the problem behind a seemingly unglamorous part of Cohere’s North 2 launch: budget controls.

Announced on 5 October, North 2 combines reusable agents and workflows with model choice, private deployment options and administrator controls. Cohere lists user quotas, organisation-wide caps, rate limits and permissions. Its financial-data connectors are described as planned, not all available today. Those distinctions matter more to a buyer than treating every item on a launch page as an immediately usable feature.[1]

A platform is not the same purchase as a model

Cohere’s documentation separates its shared API platform, dedicated Model Vault inference and North’s ready-made application. North includes the user-facing environment for working over connected material; an inference deployment does not automatically provide that whole workflow. “We can call the model” and “our employees can use a governed business application” are different deliverables.[2]

The distinction continues into pricing. Model Vault’s standard documentation describes instance-based charges for dedicated inference. That is not a North subscription quotation. Without a scoped commercial offer, it would be misleading to multiply a published model rate by employee count and call the result the cost of deploying North.[3]

These controls can conflict in ways that are easy to miss in a demonstration. A shared organisation cap may protect the invoice but allow one team to consume an allowance another team needs. A strict individual quota may be fair in allocation yet prevent an authorised employee from completing an urgent job. Governance is the explicit resolution of those trade-offs, not simply the presence of toggles.

Measure the finished work, including the human return trip

Consider an original cost example with no connection to Cohere’s actual pricing. A system attempts 1,000 reports at an average machine cost of US$0.08 each. Eight hundred are accepted. The machine cost is $80 in total, or $0.10 per accepted report—not $0.08. Failed attempts still used resources.

Suppose the remaining 200 each require three minutes of human repair, valued at $30 an hour. That adds ten hours and $300. If all repairs succeed, the completed 1,000 reports have a combined cost of $380, or $0.38 each. This does not prove an AI workflow is good or bad. It shows why a low token bill can coexist with an expensive operating process.

The most informative pilot would therefore record outcomes and intervention, not just utilisation. Did the user accept the result? How often was it reopened? Did another employee have to reconcile a partial update? Those costs can reveal where a more capable model is justified and where the process itself needs redesigning.

A spending cap should have a stopping policy

Our proposed design treats stopping as a normal workflow outcome. Before a consequential write, the system should know what has already happened, what remains reversible and which steps are still authorised. A soft threshold could prevent starting another long job while allowing a small, bounded amount of work needed to record status. A hard threshold still needs a safe interruption path. These are design recommendations, not verified descriptions of North’s implementation.

A useful handover might say that the source documents were retrieved, the draft is saved, no payment or external message was sent, and a particular approval is still outstanding. That is materially better than an error saying the token budget was exceeded. It lets a person or later run continue from evidence rather than repeat the entire sequence.

Retry design is part of the same problem. Amazon’s engineering guidance explains why a request that times out may nevertheless have produced a side effect, and why explicit request identifiers can make retries safe within the supported contract. A workflow cannot infer “nothing happened” merely because its assistant never received a result.[4]

Ownership includes the ability to change your mind

A model-agnostic interface can reduce dependence on one model, but moving the surrounding workflow may still require work. Our suggested procurement exercise is practical: export one representative automation, identify its data dependencies, replace the model, and inspect which prompts, tool schemas and evaluation cases need changing. That reveals more about portability than a provider list.

The same exercise should cover who can revoke access and how ongoing jobs react. Taking away a connector tomorrow ought not to leave a previously started process with indefinite authority. The appropriate behaviour depends on the organisation’s policy and the application’s execution model; it should be tested rather than inferred from the word “private”.

The same stopping problem appears in speech interfaces: why a voice agent needs a transaction receipt before telling a user a booking is complete. A budget limit or interrupted conversation must not turn an uncertain action into a confident success message.

North 2’s significance is that cost and control are becoming visible product requirements, not background accounting. The stronger enterprise offer will be the one that can explain what an agent is allowed to do, how much it may spend, what it accomplished and how to recover when any of those limits is reached. That is a more demanding standard than producing a convincing answer in a chat window.

Report an error or suggest a correction