Can Your Agents Commit?

Governing Agent Transactions, Part 1 of a series on governing autonomous agents inside the systems that run the business.

I’ve been thinking a lot about that question — about “Agent Transactions.”

We are now well into the headless era. Agents are operating inside business workflows as transaction actors — not assistants that suggest, not copilots that draft, not chatbots that answer questions and wait. Actors that act.

The agents being built right now don’t wait for a human to click “approve.” They commit transactions — directly, autonomously — into the systems that run the business: the ERP, the CRM, the claims database, the credit system, the AP platform, the agreement platform. No dropdown. No person in the loop.

Agent transactions make “commits”. A change that alters your system of record. Transaction means governance.

Agentic AI will be decided by a question most enterprises haven’t answered yet:

How do we govern these autonomous agent commits?

I share several illustrative examples. Seven agents. Seven systems of record. All being built right now. These are the shapes of agent that teams are piloting today.

An invoice agent, wired into SAP or NetSuite, processes and posts invoices up to a defined dollar value — no human touches it.

A claims agent, running against a homegrown claims database, auto-adjudicates specific claim types up to a set payout — start to finish, no adjuster in the loop.

A credit assessment agent, querying a custom credit database, bumps a customer’s credit limit — capped, and limited to one bump every 12 months.

A sales agent inside Salesforce approves a discount on a live deal — not to exceed a defined percentage, and only above a minimum ARR threshold.

An expense agent auto-approves spend under $75, and flags anything with a restaurant line item over $150 per person.

A vendor payment agent, connected to Bill.com, Ramp, or Airbase, releases payment to an approved supplier — capped per bill, capped per supplier per month.

A contract agent counter-signs and executes standard NDAs that match the approved template exactly — no redline, no negotiation, no human involved. Anything that deviates from the template, even a single clause, escalates to legal instead of getting signed.

[VISUAL: Agent Transactions summary graphic]

Notice what they have in common. Every one names a system of record. Every one names an action with a real, binding consequence — money moves, a limit changes, a claim pays out, a signature binds the company. And every one comes with a boundary attached: up to a dollar value, not to exceed a percentage, once every 12 months, or an exact match to an approved template. This is the actual shape of the problem.

Notice, too, what the contract agent is not: it’s not reviewing, not redlining, not suggesting language for a human to consider. Drafting is assistance. Signing is a commit. The distinction matters, because it’s the difference between an agent that helps and an agent whose action has to be governed.

What’s common across every agent transaction

Every commit has a business context and a set of conditions attached to it. The invoice agent’s context is accounts payable; its condition is a dollar ceiling. The credit agent’s context is risk policy; its condition is a frequency cap. The contract agent’s context is standard paper; its condition is an exact template match. Different systems, different domains — same structure underneath.

Those conditions are what give the enterprise control. They’re what let an agent act deterministically — reliably, the same way every time, within a boundary someone actually defined — instead of the enterprise simply hoping the agent behaves.

This is not a new idea. It’s exactly how the human-approved world has worked for decades: authorized tools and APIs, role-based access on objects, dropdowns that only show valid actions, approval screens with prefilled dollar thresholds, fields that won’t let you type a number that’s too high, and overrides managed through exceptions. The business rule was baked into the interface. A human operator was constrained by the UI whether they thought about it or not. The human followed the exact same path, every time, because the interface only let them.

Agents don’t have a UI. There is no dropdown to constrain a headless process. Which means the boundary can’t live in the interface anymore — it has to live somewhere the agent is required to check, every single time, before it commits anything.

How these agents are actually getting built

Here’s where most of these pilots quietly go wrong.

Builders are building these agents using models, agent harnesses, and whatever tools, MCP servers, SQL access, and APIs they can get their hands on. It’s a genuinely fast way to get something working — and it should be, that’s the whole promise of the current tooling landscape.

But the business rules — the dollar limits, the percentages, the once-every-12-months, the exact-template-match — get hard-coded into agent logic. A number in a config file. A conditional buried inside a prompt or a function. Whatever the builder had time to wire up before the demo.

Here’s what makes this different from the human era, though: an agent doesn’t follow the exact same path. A model reasons over tools and data. It finds new and unexpected ways to solve the problem it’s given. Its actions are non-deterministic by nature. There is no guarantee an agent will follow the business rules even when they’re written down as skills or instructions, because instructions are guidance, not enforcement. A human constrained by a dropdown has no other path available. An agent given the same rule in a prompt has a thousand other paths available, and no wall in the way. In the human era, everything was fixed. In the agent era, everything is dynamic — and the thing doing the reasoning is fallible.

Agent builders cannot build this “commit layer” inside their own agent harnesses with skills, instructions and models that generate probabilistic outputs. Agents built without that layer will never see the light of day in production. They’re ungovernable — across models, tools, harnesses, actions, and commits. That’s an agent that cannot be trusted to commit to a real system of record, no matter how well it performed in a POC or a pilot.

Multiply that across several use cases, a dozen teams, and whatever framework each team happened to choose that quarter, and you get agent sprawl: real transactional power, scattered across the business, with no single place anyone could point to and ask, “what is every agent in this company currently authorized to do?”

The big gap

That’s the gap: between the layer where agents get built, and the layer that governs whether an agent’s commit can actually be trusted.

It’s the gap between a working demo and a production system. Between “the agent processed the invoice correctly this time” and “the agent will never post an invoice outside its authorized boundary, for any invoice, forever, with an audit trail that proves it.” Security review asks the second question. Most agent builds today can only answer the first.

Context Authorization

This is the gap LangGuard is solving with Context Authorization — the ability to govern every agent commit, deterministically, with business context and conditions tied to your systems of record.

Instead of a dollar limit hard-coded inside one agent’s logic, the boundary is defined once, centrally, as policy — and enforced the same way for every agent that touches that system, regardless of which model, harness, or MCP server built it.

Context Authorization starts one layer upstream of the commit itself: which model is even trusted to reason toward it.

Take the contract agent. A frontier model reasoning over your NDAs and MSAs is reading your pricing structure, your negotiated fallback positions, your liability posture across every counterparty you deal with — the substance of how your company actually negotiates. That’s enterprise alpha. Plenty of legal and procurement teams are, reasonably, uneasy about that enterprise alpha leaking to a frontier model. Some are outright unwilling to let that reasoning touch a model whose training and infrastructure sit outside a jurisdiction they trust — a Chinese-hosted model reasoning over payment or contract data, for instance, is a nonstarter for a lot of enterprises, independent of how capable the model is.

Tokenomics is a big consideration too. Now take the expense agent. Deciding whether a $42 lunch receipt clears a $75 threshold does not require a frontier model. It requires a small, fast, inexpensive model that can read a number and compare it to a policy.

A contract agent and an expense agent should never be held to the same model policy — not because one matters more than the other, but because the data sensitivity and the task complexity are entirely different. Which model is authorized to reason about a given class of transaction, given what it will see and what it costs to run, is a policy decision — and it belongs inside Context Authorization, not outside it.

From there, the same policy layer governs the commit itself. Three questions, checked at the moment an agent tries to act:

• Tool — can this agent even touch this system, and how much of it?
• Action — is this the specific kind of transaction this agent is allowed to take?
• Condition — does it fall within the boundary defined for it — the dollar value, the percentage, the frequency, the exact match?

Before your agents can commit, you have to put the Context Authorization layer in place — implemented as policy. Make that layer available to your developers, so they can easily integrate their commit logic with your enterprise systems of record. That’s how you go from a built agent to a governed agent — operating in 4 to 6 weeks.

What’s next

This is the first post in a series on Governing Agent Transactions. The next post takes the invoice agent — one use case, one system of record — and goes a level deeper: what Tool, Action, and Condition actually look like when applied to a real accounts payable workflow, including what happens the moment an agent hits its boundary.

Building a transactional agent? Let’s talk.