The most important change in artificial intelligence is increasingly taking place outside the model itself.
Frontier models continue to improve at reasoning, coding, research, computer use, and professional work. At the same time, the systems built around those models are becoming more persistent. They can retain context, connect to applications, operate browsers, use computers, execute code, coordinate across tools, and continue working after the person who initiated the task has moved on.
This changes the nature of the problem. A model that produces an answer can be evaluated primarily through the quality of that answer. A system that carries out work has to be evaluated across the entire path from intention to action.
The question is no longer only whether an AI system can produce a useful result. The system also has to understand the context in which that result matters, operate within the authority it has been given, recover when conditions change, and provide enough visibility for a person to remain accountable for the outcome.
Intelligence becomes operational when it can carry context into action.
From Models to Systems
The latest generation of models makes the distinction increasingly difficult to ignore. Claude Sonnet 5.5 and Opus 5.5 occupy different points in the capability and cost spectrum. GPT-6 Astra is positioned for demanding computer use, scientific work, software engineering, and complex professional tasks, while GPT-6.1 Sol is designed to provide near-Astra performance for complex work at substantially lower cost.
These developments make model selection more contextual. A well-defined task with a clear way to verify the result can be handled differently from a long-running assignment in which the system has to interpret incomplete information and make decisions along the way. The distinction is therefore less about identifying a universally superior model and more about matching capability, cost, context, and task structure.
This is an important change in how intelligence is engineered. A production system may use several models for different classes of work. It may use a lower-cost model for repeated operations, a stronger model when ambiguity increases, and a separate escalation path when the consequences of an error justify additional computation or human review.
GPT-6.1 Sol makes this economics particularly visible. Its published pricing includes substantially lower input and output costs than Astra, while cached input is priced at a small fraction of uncached input. That matters for systems that repeatedly reuse large bodies of context, such as project information, codebases, organizational instructions, or persistent task state.
The model is therefore becoming one component within a larger operating design. Intelligence is distributed across the model, the context supplied to it, the tools available to it, the environment in which it operates, and the mechanisms used to evaluate its work.
When Intelligence Gets a Place to Work
Agents require more than a model and a prompt. They need an environment in which work can actually happen.
OpenAI's recent introduction of Dots illustrates this shift. Dots are designed as persistent agents with access to a cloud computer, browser, connected applications, and user context. They can work on tasks across software, documents, communication systems, and other connected services rather than simply describing the steps a person should take.
The same architectural direction appears in Codex. OpenAI has introduced reusable cloud development environments that allow coding work to continue across devices and locations instead of treating every remote task as an isolated execution session.
Meta's Muse follows a similar principle from a consumer perspective. Muse runs through a dedicated Secure VM that provides the agent with an execution environment containing the user's data and the resources required to perform tasks. Meta describes the system as a personal agent that can work across applications and continue carrying out delegated work.
The significance is architectural. The computer is becoming part of the agent.
For years, software treated the computer as the place where instructions were executed after a human had already decided what to do. Agentic systems reverse part of that relationship. The system can interpret an objective, determine a sequence of operations, interact with software, inspect intermediate results, and continue until the task reaches an acceptable state or requires intervention.
This creates a new layer in the intelligence stack. The environment is no longer external to intelligence. It determines what the system can observe, what it can change, what it can access, and how safely it can operate.
Context Is Becoming Infrastructure
An operational agent cannot work from the model alone. It needs knowledge about the task, the user, the organization, the tools it can access, and the state of the work already completed.
This makes context a persistent architectural resource rather than a block of text attached to an individual prompt.
The recent model developments reinforce this direction. Lower-cost cached input makes it more practical to reuse substantial context across repeated agentic tasks. Persistent agents such as Dots and Muse are designed to retain information about ongoing work and user preferences. Connected applications provide access to information that would otherwise remain outside the model's immediate view.
The quality of that context becomes part of system reliability. Incorrect memory can produce a confident action based on outdated information. Missing context can cause an agent to interpret a legitimate instruction incorrectly. Context that is too broad can introduce unrelated information into a decision. Context that is too narrow can prevent the system from seeing an important dependency.
These are architecture problems. They cannot be solved simply by increasing model capability.
A mature intelligence system therefore needs mechanisms for deciding what information should persist, what information should be retrieved, what information should expire, and which parts of the available context are relevant to the current task.
Context is becoming part of the infrastructure through which intelligence operates.
Action Changes the Meaning of Reliability
The consequences of an incorrect answer and an incorrect action are different.
An inaccurate summary may require a correction. An agent that sends the wrong message, changes the wrong record, modifies production software, purchases something unnecessarily, or exposes information can create consequences outside the conversation in which the mistake occurred.
This changes what reliability needs to mean.
An operational system needs to understand the authority attached to each task. It needs to distinguish between actions that are reversible and those that are difficult to undo. It needs to recognize when the scope of a task has changed and when a previous instruction no longer provides sufficient authorization.
OpenAI's published evaluation of Dots illustrates why this matters. The company tested whether persistent agents could adapt when task scope or permissions changed during execution. The evaluation reported strong performance on explicit permission changes, while also identifying moderate scope violations in some longer sequences of chained tasks. The reported flag rate increased as the number of intervening tasks increased.
The result is significant because persistence creates a new class of failure. An agent may have been authorized to perform one task correctly and still become misaligned with the user's current intention several steps later.
Operational intelligence therefore requires more than the ability to follow instructions. It requires the ability to maintain the boundaries attached to those instructions as the environment changes.
The Agent Needs an Operating Environment
The architecture around an agent determines much of what makes its intelligence useful.
Tools provide access to external capabilities. Connectors provide access to applications and information. Browsers provide a way to operate interfaces. Computers provide an execution environment. Memory provides continuity. Evaluation provides a way to measure behaviour. Permissions establish authority. Human intervention provides a mechanism for resolving situations that fall outside the system's reliable operating range.
Meta's Muse provides a clear example of this architecture. Its Secure VM gives the agent a dedicated environment, while connectors extend its ability to interact with external services. Meta has also described work on computer use, persistent tasks, tool selection, action chaining, and mechanisms for checking back with the user when approval is required.
OpenAI's Dots demonstrate the same broader pattern through a different product architecture. The agent can use a cloud computer and browser, interact with connected applications, receive ongoing context, and continue work across communication and development environments. OpenAI has also introduced specialist Dots intended for roles such as accounting, marketing, and legal work.
These systems show why the model alone is an incomplete description of an agent. The model supplies reasoning and generation capabilities. The surrounding system determines where those capabilities can be applied and under what conditions.
The distinction becomes especially important when the agent operates continuously. A system that works for several minutes under direct supervision can be evaluated differently from one that continues operating in the background while the user is away. Persistence increases the value of successful work, but it also increases the number of opportunities for context, permissions, or environmental conditions to change.
Capability Still Has to Become Operational
The gap between an impressive demonstration and a dependable production system becomes wider as agents acquire more capabilities.
A conversational agent can be useful with relatively little integration. A business agent that needs to answer questions from company information, use structured knowledge, access external systems, retrieve files, call tools, and hand work back to people requires considerably more infrastructure.
The Meta Business Agent illustrates this difference. Business information, frequently asked questions, behavioural instructions, files, websites, connectors, and tools each represent a different part of the system. The process of connecting external capabilities can itself become a technical task, particularly when the integration requires APIs and developer configuration.
This is where the distinction between capability and operational readiness becomes important. A model may be capable of reasoning about a business process without the system having the permissions, integrations, data access, or escalation mechanisms required to execute that process reliably.
The same principle applies to enterprise agents. The more systems an agent can access, the more carefully those access paths have to be designed. A connected application is not simply another feature. It is another source of data, another action surface, and another potential boundary condition.
Reliable agent systems therefore need to be designed around the complete workflow rather than around the model's most impressive capability.
What Earned Intelligence Requires Now
The first phase of the Earned Intelligence argument examined how intelligence can remain useful and trustworthy as systems scale. The emergence of persistent agents extends that question into a more consequential domain: systems that can act within the world on behalf of people.
Once an AI system can operate software, manage ongoing tasks, access private information, coordinate tools, and execute actions, capability alone is no longer a sufficient measure of intelligence. The system also needs a clearly defined operating boundary that governs what it knows, what it can access, and what it is permitted to do.
Context forms the foundation of that boundary. An agent must have access to the information necessary to understand the task without being overwhelmed by irrelevant or outdated material.
Memory extends that context across time. Relevant state must remain available when needed, while assumptions that no longer apply should not silently influence future decisions.
Tools and execution environments then connect reasoning to actual work. Their design determines which systems an agent can interact with, what information it can retrieve, and which actions it can perform.
Permissions define the limits of that access. A system may be technically capable of performing an action without having the authority to perform it. Those two conditions have to remain distinct throughout the task.
Evaluation provides another layer of control by making behaviour observable. Instead of assessing only the final output, an operational system can be examined for how it handled context, permissions, intermediate decisions, and actions along the way.
Feedback closes the loop. Human corrections, changing conditions, failed actions, and new information all provide signals that can improve how the system operates over time.
Escalation completes the boundary. When a task becomes ambiguous, consequential, or falls outside the system's reliable operating range, there must be a clear path back to human judgment.
Together, these layers change the meaning of intelligence in production. A model may possess substantial reasoning capability and still be unsuitable for independent operation within a complex environment. Operational intelligence depends on whether that capability can be carried through the surrounding system without losing context, authority, or accountability.
Earned intelligence emerges when capability is supported by context, constraints, feedback, and evidence.
The frontier is consequently moving beyond the question of how much freedom a model should have. The more important engineering challenge is designing systems that can apply capability within clearly defined boundaries while remaining observable, correctable, and accountable.
That is where intelligence becomes operational, and where it begins to earn trust.
AI Developments Database
Track ongoing model releases, agent architectures, framework updates, and deployment developments through the DataGuy AI Developments Hub.
Sources List
- OpenAI, Dots: Introducing Dots
- OpenAI, GPT-6.1 Sol: GPT-6.1 Sol Model
- OpenAI Deployment Safety Hub, GPT-6 Astra: Evaluating Dots and persistent agent behaviour
- OpenAI DevDay 2026: OpenAI DevDay
- Meta, Muse: Introducing Muse