The Agents API Is Not Your Operating Model

Buying agent infrastructure is getting easier. Designing how agents should work inside your business is not.

OpenAI’s new Agents API makes that distinction clearer. The company says developers can now use the managed Codex harness behind its own agent products, choose where the agent runs, keep long sessions moving through context management, load tools when needed, make programmatic tool calls, and delegate independent work to subagents.[1]

That is useful infrastructure. It removes work that every team should not have to rebuild.

But it does not decide how your company operates.

A harness can coordinate model calls, tools, context, and compute. It cannot decide which customer record is safe to change, what evidence makes a task complete, who owns an exception, or when a human must approve an action. Those are operating-model decisions.

For SME leaders, this is the next adoption trap. A capable platform can make the agent look ready before the business is ready.

What the managed layer now covers

OpenAI describes the Agents API as a public-beta service for building and running cloud agents with the Codex harness. Developers specify the task, model, tools, and environment. The agent can run in an OpenAI-hosted sandbox, on the customer’s own infrastructure, or with a sandbox provider.[1]

The service also manages parts of long-running execution that are tedious but important. OpenAI says it can compact earlier context as sessions approach their limits, preserve relevant information across multiple context windows, search for tools instead of loading every definition at once, and run or combine tool calls programmatically.[1]

Multi-agent support adds another layer. A coordinating agent can divide suitable work into independent parts, send those parts to subagents running in parallel, and combine their results.[1]

This is the shift from AI as a chat box to AI as execution infrastructure.

It is also where leadership responsibility increases. Once an agent can keep working, call tools, write files, and coordinate other agents, a good answer is no longer enough. The system needs to produce an acceptable business outcome under clear constraints.

Infrastructure does not define authority

Consider a sales-operations agent connected to your CRM.

Its job is to review new enquiries, enrich each company record, identify the likely buying need, and prepare the next action for a sales manager.

The platform can give the agent a sandbox. It can preserve context during a long research task. It can let one subagent research the company while another checks the CRM history. It can expose tools for reading and updating records.

None of that answers the important business questions:

• May the agent overwrite an existing phone number, or only propose a correction?
• Can it change a lead’s lifecycle stage?
• What happens when two sources disagree about the company’s size or location?
• May it create a follow-up task without approval?
• Who decides whether the prospect fits the target market?
• What evidence must appear before the record is marked complete?
• How do you reverse a bad batch update?

If those decisions remain implicit, the agent will operate inside technical permissions without a real definition of authority.

That is how fast execution creates faster confusion.

A stronger design separates capability from permission. The agent may have a tool that can update a CRM record, but the workflow narrows when and how it may use that tool. Low-risk enrichment can enter a review queue. A lifecycle-stage change may require a named approver. Conflicting evidence should produce an exception, not a confident guess. Bulk changes should create a recoverable transaction record before anything is written.

The API enables execution. Your operating model defines acceptable execution.

The seven decisions the business still owns

1. Business context

Agents need more than documents. They need current definitions: what counts as a qualified lead, which customer segment matters, which fields are authoritative, and which policies override convenience.

Context also needs an owner. If nobody maintains it, the agent will faithfully execute yesterday’s rules.

2. Scoped permissions

Do not grant broad access because it is easier to configure. Give each workflow the minimum capability it needs for the current task.

Reading a pipeline does not require exporting every contact. Preparing an invoice does not require releasing payment. Drafting a support resolution does not require closing the ticket.

3. Acceptance criteria

“Review the CRM” is not a task specification.

A useful acceptance test might require every processed record to include a verified company name, source link, confidence label, proposed next action, and a reason for any exception. The work is complete when those checks pass, not when the agent stops calling tools.

4. Evidence

Every material output should carry its workpapers: sources consulted, records read, tool actions attempted, validations passed, and unresolved gaps.

Evidence turns agent output from a claim into something an operator can inspect.

5. Human approval

Place approval at the point of consequence.

A person should not have to approve every harmless lookup. They should review actions that affect customers, money, commitments, production systems, regulated data, or the company’s public position.

This keeps people in the loop without turning them into manual routers for every step.

6. Exception ownership

Agents will meet missing data, contradictory instructions, unavailable systems, and edge cases.

Define where those cases go. An exception needs a queue, an owner, a priority, and enough context for a person to decide. “Ask a human” is not an operating process if no human is accountable for answering.

7. Rollback

Before an agent changes business records, decide how to reverse the change.

For a CRM workflow, that could mean recording old and new values with a batch identifier. For an ERP workflow, it may mean preparing a transaction for approval rather than posting it directly. For a website workflow, it means a checksum backup and a verified restore path.

Rollback is not just a technical feature. It is the business’s ability to recover from delegated execution.

Start with one bounded digital coworker

Do not begin with “build an autonomous workforce.” Begin with one workflow that has a clear owner and a measurable finish line.

Use this pilot checklist:

1. Choose one recurring queue. Pick work that already arrives in a recognisable form, such as new CRM enquiries, overdue service tickets, or supplier-invoice checks.
2. Name the outcome. Define what the agent must produce and what it must not change.
3. Limit tools and data. Grant only the systems, fields, and actions required for that queue.
4. Write acceptance tests. Make completion mechanically checkable where possible.
5. Attach evidence. Require sources, action logs, validation results, and explicit gaps.
6. Set the approval boundary. Identify the exact action where human judgment is required.
7. Route exceptions. Give failed or ambiguous cases a named owner and response target.
8. Test rollback. Prove that one bad action and one bad batch can be reversed.
9. Measure the outcome. Track cycle time, accepted outputs, corrections, exceptions, and avoided rework.
10. Expand only after the evidence is stable. Add authority gradually instead of assuming that more autonomy creates more value.

The Agents API signals that the technical foundation for long-running, tool-using, multi-agent work is becoming easier to consume.[1]

That does not reduce the need for operators. It changes their job.

The advantage will not come from having access to the same managed harness as everyone else. It will come from knowing what good work looks like, encoding that standard into the workflow, and retaining human judgment where the outcome carries real consequence.

Orchestrate the work. Do not confuse the infrastructure with the organisation.

Sources

[1] https://openai.com/index/introducing-the-agents-api — Introducing the Agents API