AI agents already have a concrete architectural form: a model operates inside software that maintains task state, executes tools and observes results. The unresolved question is when those systems become routine enterprise infrastructure. The clearest adoption milestone in the available evidence is 2028, and it concerns software engineering specifically.
What separates an AI agent from a chatbot?
A stateless chatbot responds to an input. An autonomous agent carries a task through successive decisions and actions, using the results to determine what happens next. Autonomy here means operating within an execution system and its permissions; it does not imply unrestricted authority.
NineTwoThree describes an AI harness as the software, configuration and execution logic surrounding a large language model. Its useful shorthand is Agent = Model + Harness. The model supplies language-based reasoning; the surrounding system makes that reasoning operational.
| Term | Meaning in this architecture | What to evaluate |
|---|---|---|
| AI model | The underlying language model used to reason about inputs and generate responses or proposed actions. | Its contribution to the task. |
| AI harness | The software, configuration and execution logic around the model. | State handling, tool execution, limits and traceability. |
| AI agent | The model and harness operating together to pursue a task. | Whether the complete system achieves an acceptable outcome. |
| AI framework | Reusable building blocks for implementing the surrounding software, rather than a complete deployed agent. | Which operational responsibilities the application still needs to implement. |
These are working architectural distinctions, not product certifications. When evaluating a system, ask what controls its actions and records its progress, rather than relying on the agent label.
What agents can do today, and what that establishes
Andrii Furmanets’ architecture guide describes production agents as control loops: read state, plan a next step, execute a tool, observe the result and update state. A tool response therefore becomes evidence for the next decision instead of merely text shown to a user.
The following is conceptual pseudocode for that sequence, with a tool registry and state reduction. The function names describe responsibilities; they are not vendor API calls or a runnable SDK example.
state := initial task state
while task is unfinished and runtime budget remains:
proposed_action := model plans next step from state
tool := tool registry looks up proposed_action.tool_name
validate proposed_action.arguments against tool contract
if execution policy denies proposed_action:
stop or escalate to a human
result := execute tool within remaining budget
state := reduce state using proposed_action and result
return recorded outcome and final state
The state-reduction step incorporates an observed result into the task record. An unsuccessful call must remain visible as a failure, rather than being treated as completed work. The budget and stop path also make clear that a loop needs an end condition beyond the model’s willingness to continue.
Physical AI offers a separate example of model capability. NVIDIA’s coverage of Skild AI’s S1 describes a robot foundation model learning previously unseen, long-horizon tasks from a single video demonstration through in-context learning, without updating its weights or undergoing task-specific post-training.
That reported capability does not establish a timetable for widespread robotics deployment. Nor does either example demonstrate reliable autonomy across arbitrary enterprise tasks. The evidence supports specific capabilities and architectures; it does not provide a general measure of agent reliability.
What belongs in an agent harness?
Memory and orchestration
Furmanets describes layered memory extending beyond a vector database: working memory, summaries, artifacts and long-term preferences. These serve different purposes. Working memory holds the immediate task context; summaries condense earlier progress; artifacts preserve work products; preferences carry relevant information across tasks.
The engineering question is which information the next decision requires and where that information should live. A retrieval store alone does not describe the current execution state or determine whether an action succeeded.
Orchestration connects these records to execution. It determines which tool can run, how the result enters state and when execution stops. Keeping those responsibilities explicit makes it possible to inspect the path from a proposed action to an observed outcome.
Tool contracts, results and side effects
The same architecture guide calls for typed tool contracts, such as JSON Schema or Zod, structured results, explicit idempotency keys for side effects and runtime budgets. A typed contract defines the accepted arguments and result shape. An idempotency key gives the execution layer a way to recognize a repeated request for the same intended side effect; it needs corresponding enforcement by the tool or backing service.
Below is an illustrative JSON Schema for a result envelope using the requested ok, data, error and metadata fields. It is an author-designed contract expressing those architectural requirements, not a documented product schema. It deliberately leaves the successful payload open for a tool-specific definition.
{
"type": "object",
"additionalProperties": false,
"required": ["ok", "data", "error", "metadata"],
"properties": {
"ok": { "type": "boolean" },
"data": {},
"error": {
"type": ["object", "null"],
"additionalProperties": false,
"required": ["code", "message"],
"properties": {
"code": { "type": "string" },
"message": { "type": "string" }
}
},
"metadata": {
"type": "object",
"additionalProperties": false,
"properties": {
"idempotency_key": { "type": "string" }
}
}
},
"oneOf": [
{
"properties": {
"ok": { "const": true },
"error": { "type": "null" }
}
},
{
"properties": {
"ok": { "const": false },
"data": { "type": "null" },
"error": { "type": "object" }
}
}
]
}
The two branches distinguish success from failure. A production contract should replace the open data definition with the particular tool’s output schema. For an operation with side effects, require an idempotency key on the invocation and enforce it during execution; returning the key in metadata only records it. This envelope also leaves authorization and budget enforcement to the surrounding harness.
When will enterprise adoption become mainstream?
GitHub’s account of Gartner’s enterprise AI coding-agent outlook reports a prediction that by 2028, over 70% of enterprise software engineers will rely on AI coding agents for synchronous and asynchronous development tasks.
That is a forecast about reliance on coding agents, not a claim that development will be fully autonomous. Its scope is enterprise software engineers, rather than all employees, businesses or industries. It offers a planning horizon for engineering leaders while leaving the degree of delegation open.
The available evidence does not supply quantitative adoption metrics across other sectors or proprietary timelines from OpenAI, Anthropic and Google DeepMind for general agent-autonomy milestones. Skild S1’s reported learning capability cannot fill those gaps: a model capability and a workforce-adoption forecast measure different things.
For an enterprise planning a deployment, 2028 is therefore a relevant software-engineering forecast. The readiness of a particular workflow still needs to be assessed through its execution requirements and observed outcomes.
Security controls must govern execution
Sweet Security describes agent guardrails as enforceable technical boundaries governing access, tool execution, blocking and human escalation. Their placement matters because an agent processes inputs and takes actions at different points in its run.
Input guardrails inspect prompts and retrieved data before processing, with the aim of blocking prompt injection and jailbreaks. Output guardrails inspect generated responses before delivery. These controls address different surfaces, and the evidence does not establish that either eliminates attacks.
Dynamic authorization applies at the action boundary. It evaluates each tool call at execution using identity, task context and live behavior to determine whether the action should proceed or be blocked. A permitted response does not itself authorize the operations proposed within it.
Runtime guardrails then observe live actions against established baselines. They can intervene, escalate to a human or initiate a fail-safe shutdown. Production design should make those interventions enforceable within the execution system, rather than leaving them as instructions the model is expected to obey.
How to decide whether a workflow is ready
NineTwoThree identifies repeatability, logging, tracing and evaluation loops as essential harness infrastructure. Those capabilities give engineering teams a basis for examining failures and governing changes to the system.
A practical deployment review should establish four things:
- A bounded task: Define the acceptable outcome, permitted tools and conditions requiring human intervention.
- Inspectable execution: Preserve task state, tool arguments, structured results and the reason a run stopped.
- Enforced limits: Apply typed contracts, side-effect controls, authorization and runtime budgets at execution.
- Evaluation before release: Use the recorded runs to assess outcomes and failure handling when the model or harness changes.
Integrating those evaluations into CI/CD is a recommended engineering practice, rather than a supplied industry adoption statistic. Treat an agent update as a change to the complete execution system: review what it can do, how it fails and whether its controls still hold. Broader adoption forecasts do not answer those questions for an individual deployment.
Explore more AI Agents coverage.
