AI Agents Are Becoming Software’s New Operating Layer in 2026

The refund looked routine. A support agent found the order, confirmed the customer’s eligibility, and called the payments API. The request timed out, so it tried again. Both calls eventually succeeded. The customer received two refunds, and the company had to reconcile the duplicate manually.

Nothing about the language model’s answer looked obviously wrong. The failure was in the machinery around it: no idempotency key, weak retry rules, and no policy check between the agent’s recommendation and the financial action.

That is the practical challenge with AI agents. A chatbot produces an answer. An agent opens a ticket, inspects a repository, changes files, runs tests, retries after an error, and waits for approval before merging. It operates inside a system with tools, credentials, memory, sandboxes, policies, and logs.

The model is becoming one component of a larger execution environment. OpenAI’s September 2026 Agents API announcement reflects that direction with managed support for files, code execution, tools, subagents, and long-running sessions. The underlying pieces aren’t new; developers have assembled them for years. What’s changing is that agent infrastructure is starting to look like a standard software layer—closer to an application runtime than a prompt wrapped around an API call.

From generated answers to supervised execution

The old mental model was simple:

prompt → model inference → generated response

A production agent needs a longer chain:

request
  → plan
  → select tools
  → retrieve context
  → execute code or API calls
  → persist state
  → evaluate result
  → request approval or continue

Every arrow creates a failure mode. A tool can time out. A retrieved document can contain hostile instructions. A coherent plan can still be financially reckless. The model can call the correct API using the wrong account.

That makes an agent runtime a distributed system. It needs identity, quotas, retries, idempotency, network controls, observability, and a clear system of record.

A reliable operating rule is:

The model may propose an action. Deterministic software decides whether that action is allowed.

An agent might recommend issuing a refund. A policy service should verify the order, enforce the maximum amount, check the customer’s history, and decide whether a human must approve it.

{
  "agent": "support-refunds",
  "allowed_tools": ["orders.read", "refunds.create"],
  "limits": {
    "refund_amount_usd": 100,
    "requests_per_minute": 30
  },
  "approval_required": [
    "refunds.create.over_50",
    "account.close"
  ],
  "network": {
    "egress": ["api.orders.internal"]
  }
}

This policy isn’t administrative wrapping around the “real” AI system. It is part of the system.

Context, memory, and governance belong together

Long context windows have encouraged teams to pour entire conversations, documents, and tool outputs into one prompt. That can work in a demonstration. Under load, it becomes expensive and difficult to reason about.

A context window is working memory, not a database. It can contain stale instructions, contradictory records, injected text, and irrelevant history. If a workflow processes 200,000 tokens to answer a question that needed 8,000, a larger model won’t repair the economics.

Reliable agents separate state into a few distinct layers:

• Working context: information needed for the current decision.
• Structured state: durable facts, workflow status, and approval state.
• Retrieval systems: documents and records fetched for a specific task.
• Event logs: what actually happened, including tool calls and outcomes.
• Summaries: compressed history that links back to source data.

This separation is also a security boundary. Retrieved text should be treated as data, not as a new system instruction. A document can tell the agent what it contains; it cannot grant itself permission to send email, access production, or issue a refund.

The distinction matters during recovery. Suppose a five-step workflow fails at step four. The runtime should know which actions succeeded, which did not, whether a retry is safe, and which credentials were used. A transcript rarely answers those questions. A structured event log can.

Governance therefore belongs in the runtime itself. Production agents need least-privilege credentials, sandboxed code execution, secrets kept outside model-visible context, immutable tool-call logs, version pinning, evaluation suites, kill switches, and rollback procedures. Irreversible actions—financial transfers, production deployments, account closure—should require explicit approval or a deterministic policy decision.

Retry behavior deserves particular attention. If a payment or provisioning API has a 2% transient failure rate and the agent blindly retries once, the second call must be safely deduplicated. Otherwise, a small network problem becomes a duplicate side effect. Idempotency keys, bounded retries, and compensation workflows are more valuable here than another percentage point of benchmark performance.

Coding agents need better repositories

AI software engineering is moving beyond autocomplete toward bounded maintenance work. GitHub’s cloud agent and Apple’s Xcode coding intelligence features point toward workflows in which an agent investigates an issue, searches a repository, proposes a plan, modifies code, runs tests, diagnoses failures, and prepares a branch for review.

That’s useful, but its success depends heavily on the repository. Reproducible builds, meaningful tests, clear ownership, and current documentation give an agent something solid to reason about. Hidden dependencies and tribal knowledge give it room to invent explanations.

The limiting factor may soon be review capacity. If an agent creates 40 pull requests a week but engineers can deeply inspect only 15, the organization has increased code volume without increasing confidence. Smaller patches, risk-based routing, stronger tests, and provenance become essential. Teams should be able to identify the model, prompt, tool versions, and repository state behind every change.

A useful evaluation asks a practical question: given a real issue from our repository, can the agent produce a correct, reviewable patch without breaking unrelated behavior? Track successful completion, rework, review time, escaped defects, latency, and cost. Token counts are operational telemetry, not business outcomes.

For example, reducing average review time from 45 minutes to 25 minutes may be meaningful even if task completion rises only modestly. Conversely, an agent that finishes 10% more tasks but doubles review time may be a poor production investment.

Protocols and infrastructure matter

The Model Context Protocol is addressing integration problems that appear once agents move beyond prototypes. Its evolving work around Streamable HTTP, discovery, caching, routing metadata, and OAuth guidance can reduce the amount of bespoke connector code teams maintain.

That helps interoperability, but a standard interface doesn’t make a tool safe. Every connector still needs independent authorization, input validation, rate limits, audit records, version management, clear ownership, and predictable failure behavior.

Infrastructure has its own trade-offs. AI workloads are often constrained by memory bandwidth, context assembly, network latency, and tool response time—not just model FLOPS. NVIDIA’s Vera Rubin platform announcement is aimed at the economics of large-scale inference, interconnects, context handling, and confidential computing.

The useful measure is completed work, not tokens per second in isolation:

Cost per successful task = (model inference + tool usage + infrastructure + evaluation + human review) / completed tasks

A fast model that produces failed workflows can cost more than a slower model with reliable tool use. In many systems, a database query, cold container, or approval queue dominates end-to-end latency. A five-second model response is irrelevant if a human approval adds 20 minutes and the workflow sits in a queue.

Local inference offers another option. Apple’s Foundation Models framework and Private Cloud Compute support a hybrid direction: use a small local model for classification or redaction, a hosted model for difficult planning, and conventional services to execute approved actions.

That is an architectural option available today in parts of the stack, while broader autonomous workflows remain an area of active product development and interpretation. The same caution applies to robotics. Google DeepMind’s Gemini Robotics work combines vision-language-action reasoning with robot-specific adaptation and safety controls. A general model should not be the final authority over collision avoidance, force limits, emergency stops, or safe-state transitions.

Start with a narrow agent

The market favors systems that promise an autonomous employee. Production teams often get better results from one agent with one job: dependency upgrades, incident summaries, invoice reconciliation, support triage, localization checks, or internal documentation search.

Narrow agents have smaller action spaces, clearer tests, fewer permissions, and easier rollback. Their return on investment is also easier to calculate.

Teams adopting agents should improve the repository before automating it, separate planning from execution, keep durable state structured, instrument every tool call, and test failure paths such as timeouts, duplicate calls, stale data, revoked credentials, and partial completion. Permissions should expand only when evaluation and rollback keep pace.

The most useful early workflow has a defined input, a measurable output, and a reversible failure. Broad access may be technically easy to grant, but technical possibility is a poor authorization policy.

Frequently asked questions

Are AI agents just chatbots with tools?

No. A chatbot generally returns a response. An agent manages a workflow that may include planning, tool calls, code execution, persistent state, evaluation, and approval. The difference is operational: an agent can change systems and must therefore be governed like software.

What should engineers automate first?

Start with bounded maintenance—tests, dependency updates, issue triage, documentation, and migrations with strong validation. Delay broad architectural changes and irreversible production actions until observability, evaluation, approval, and rollback are reliable.