A few years ago, building an AI product often meant connecting an application to a model API, sending a prompt, receiving a response, and displaying that response to the user.

September 2026 shows how far that architecture has moved. Modern ai software development increasingly involves agents that can remain active for hours or days, use external tools, work with files, execute code, delegate subtasks, save intermediate results, and recover from changing conditions.

OpenAI’s new Agents API, released on September 10, reflects this direction. The service is designed for cloud agents that can run for extended periods while managing context, tools, environments, files, and subagents.

The engineering problem has therefore expanded.

A model response is no longer the complete application

Consider a research agent asked to analyze a company before an acquisition.

A useful system may need to:

• search several information sources
• inspect uploaded documents
• run calculations
• compare financial records
• delegate research areas to separate agents
• preserve findings across many steps
• flag missing evidence
• produce a final report with traceable sources

No single prompt completes that workflow reliably.

The application needs runtime infrastructure around the model.

That infrastructure decides which tools are available, how context is preserved, when another agent should be assigned work, what happens after a failure, and which intermediate results should be stored.

Long running agents create new failure modes

Traditional API applications often fail in familiar ways.

A request times out.

A database query fails.

An external service returns an error.

Long running agents introduce additional questions:

• What happens when step 17 fails after 16 successful actions?
• Should the complete task restart?
• Can the agent resume from saved state?
• Which actions can safely be repeated?
• How are duplicate transactions prevented?
• How much context should survive across sessions?
• When should a person review progress?

These are software architecture questions.

An agent that can reason well still needs reliable state management and recovery behavior.

Evaluation needs to examine behavior

Google published new guidance on September 9 focused specifically on evaluating AI coding agents. One of its main observations is that broad end to end benchmarks can show whether overall performance moved up or down while revealing very little about why. Google recommends behavioral evaluations that test whether specific expected actions actually occur.

That principle applies beyond coding agents.

A production agent should be evaluated on behaviors such as:

• selecting the correct tool
• requesting approval before sensitive actions
• refusing unsupported operations
• preserving required context
• recovering from tool failures
• using trusted evidence
• producing valid structured outputs
• stopping when task completion criteria are met

This creates a more useful quality signal than simply asking whether the final answer looked good.

Tool permissions are part of application design

As agents gain more autonomy, tool access becomes one of the most important engineering controls.

An agent connected to CRM may need permission to read a customer record.

That does not automatically mean the same agent should be able to delete that customer.

A finance agent may need invoice data without permission to change bank details.

A coding agent may need repository access without unrestricted production credentials.

Production systems therefore need explicit controls around:

• identity
• tool permissions
• data access
• transaction limits
• approval rules
• logging
• revocation

These controls should live in software infrastructure rather than depending entirely on instructions written inside a prompt.

Agent coordination is becoming another software discipline

Anthropic’s 2026 agentic coding research describes software engineering as increasingly shifting from writing every line manually toward coordinating agents that perform development work. The report also highlights multi agent coordination, human judgment, quality, and security as major concerns when scaling agent based development.

That creates a new architecture problem.

Several agents may work on one objective:

Research agent → planning agent → implementation agent → test agent → review agent

Each agent needs:

• a defined responsibility
• controlled inputs
• expected outputs
• clear completion criteria
• permission boundaries

Without those boundaries, multiple agents can duplicate work or make conflicting changes.

Observability becomes mandatory

Long running AI systems also need detailed operational visibility.

Useful telemetry may include:

• original task
• tools called
• files accessed
• agent transfers
• model selected
• validation results
• retries
• execution time
• failures
• final actions

Without this information, debugging becomes guesswork.

A customer saying “the agent changed the wrong record” should lead to a trace showing exactly which decision and tool call caused that outcome.

The software around the model is becoming more valuable

Model capability will continue improving.

Recent releases show increasingly capable coding and agent systems, while OpenAI reports that coding agents are already changing how internal researchers write code and run experiments.

The bigger engineering opportunity now sits around those models.

Reliable agent applications need:

• context management
• tool architecture
• state persistence
• evaluation
• permissions
• recovery logic
• observability
• human approval paths

The model supplies reasoning.

The surrounding software determines whether that reasoning can perform useful work reliably.

That distinction is becoming one of the defining ideas in AI software development in 2026.