The AI agent landscape: what is taking shape and what to check

From an answer to a piece of work

An AI assistant can explain how to prepare a customer briefing. An agent can attempt the briefing itself: collect the permitted material, identify gaps, create a document, check it and revise it when the facts change. The practical difference is the work that happens between the request and the final answer.

As of 16 October 2026, that idea appears in several forms. OpenAI describes dots as persistent assistants with their own cloud computers. Anthropic documents Claude Cowork sessions that continue in the cloud. OpenClaw puts a configurable agent system under the operator’s control. These products do not offer identical access, execution environments or permissions. They illustrate different approaches to carrying a task beyond a single conversation. OpenAI’s introduction, Claude’s current documentation and OpenClaw’s introduction describe those approaches.

The useful question is becoming more specific than whether a product “has agents.” What can it work on, which systems can it reach, how does it retain context, and what evidence shows that the job is finished? Our reading of the current landscape is that these operational differences deserve as much attention as model capability. That is an editorial assessment, not a measurement of adoption or a ranking of products.

What we mean by an agent

For this article, an agent is a system in which a model can choose and execute steps toward a goal, use tools and inspect the results before deciding what to do next. A persistent agent can retain relevant state and resume authorized work later. These are working definitions; product names use the term more loosely.

Consider a weekly research brief. A useful system needs the task definition, sources it may read, somewhere to write the draft and a way to determine whether its citations support the text. Continuing next week also needs a trigger and a record of what has already been covered. Sending the brief introduces a separate permission. Each is a distinct part of the job, even when one chat box hides the machinery.

The layers behind the chat box

Models and applications

The model interprets context, produces text and helps choose actions. The agent application supplies the user experience and decides how that model participates in work. It may add file access, account connections, remembered preferences, schedules and an approval interface. A stronger model can help, but it cannot compensate for an application that cannot reach the required file or distinguish a draft from a sent message.

This also explains why two applications using the same model need not behave alike. One may expose a small collection of supported actions. Another may provide a browser and shell. Their instructions, context selection and recovery behavior can differ. A useful comparison therefore names the application, model and configuration together, rather than treating the model name as a complete description of the system.

Frameworks and managed infrastructure

Frameworks help developers construct the workflow. LangGraph’s documentation, for example, separates model steps, data retrieval, actions and human input, with state carried between them. That is a way to build an agent-backed application, rather than a ready-made personal assistant. The developer still has to define what each step means and what happens when it fails. Thinking in LangGraph.

Infrastructure addresses another set of responsibilities. Amazon Bedrock AgentCore Runtime documents hosting, identity integration and tracing for agent activity. Those facilities help a team run and inspect its software. They do not determine whether a customer should receive a refund or whether a research claim is true. Those decisions still require application policy and evidence. AgentCore Runtime documentation.

Connectors and protocols

Connectors give an application a usable route into another system. A protocol can make that connection more consistent. The MCP draft specification describes prompts, resources and executable tools exposed by servers. A2A addresses communication between agents across system boundaries. These are related pieces of plumbing with different jobs. MCP server primitives, draft specification and A2A overview.

For a reader choosing a product, compatibility is only the first question. The next is what a connected tool can actually read or change. A shared interface does not make an inaccurate database accurate, grant permission to send a message or prove that a task succeeded. In the same way, connecting several agents does not settle who owns the final decision.

Different jobs produce different agents

Personal work and continuing context

Personal agents aim to work across tasks that previously lived in separate conversations. OpenAI’s September 29 dots announcement describes ongoing goals, feedback-based personalization and a dedicated cloud computer. It also describes a rollout to selected plans in eligible markets and previews specialist organizational dots. That is a useful example of the direction, with access and preview qualifications intact. Introducing dots.

Claude’s current Cowork documentation describes cloud sessions that follow the account across surfaces, with cloud sessions in beta on Team and Enterprise plans. It also describes a gradual move toward a unified Chat and Cowork experience. Local files or computer actions still depend on an available desktop connection. A cloud task continuing while a laptop sleeps is therefore a different claim from continued access to that sleeping laptop. Get started with Claude Cowork.

For personal work, memory needs more scrutiny than its name suggests. Conversation history, saved preferences, a task’s current state and reusable procedures solve different problems. A system may remember your preferred writing style while losing the exact version of a draft. Another may preserve every file but continue to use an outdated assumption. A practical review asks what can be inspected, corrected, superseded and deleted.

Hermes Agent makes this distinction explicit in its documentation, separating factual memory from reusable procedural skills. Grok Bot documents named agents with persistent context and a cloud computer. They are useful follow-up subjects because they offer different ways to organize continuing work, not because the descriptions establish a performance ranking. Hermes skills and Grok Bot overview.

Coding, business processes and specialist work

Coding gives agent workflows a comparatively concrete set of artifacts to inspect: a patch, a test result and a reviewable change. These artifacts help define completion, although a passing test only establishes what that test covers. A proposed code change, a merged change and a running deployment remain separate states. An agent’s final message should make those distinctions visible.

Representative documented products include Codex Cloud, which runs coding tasks in isolated workspaces on OpenAI-managed computers, and Claude Code, which can read code, edit files and run commands through development interfaces. Codex Cloud documentation and Claude Code overview.

Business workflows add identity and organizational context. Salesforce positions Agentforce around Customer 360 applications and shared data across sales, service, marketing and commerce. The important distinction for a prospective user is access to the relevant business records and actions, not merely the presence of a chat interface. Salesforce’s platform description establishes its product positioning; it does not independently establish accuracy on a company’s own processes. Agentforce platform.

Specialist products can narrow the job further: reviewing a contract, preparing a support response or organizing a household schedule. The value of specialization should be assessed in the structure it supplies. Does it preserve the right entities, dates, exceptions and review steps? A general assistant can write convincing prose about a task while a specialist application may represent its state more precisely. Which is useful depends on the actual work; this is a comparison criterion, not a claim that one category is inherently better.

Where the work actually runs

Hosted convenience and self-hosted responsibility

A hosted product packages the runtime and interface, while a self-hosted system gives its operator more responsibility for configuration and availability. OpenClaw is an example of the latter approach: its Gateway connects interfaces and agent activity, with model access configured separately. Running the Gateway yourself does not establish that inference happens on your machine. OpenClaw architecture.

“Local” needs an object. The interface can be local while the model is remote. Files can stay in a local workspace while selected content is sent to an inference provider. Tool execution can take place on a different machine again. Map those paths before relying on a privacy assumption. Similarly, open-source software can still involve model usage, hosting and maintenance costs; licensing and operating economics answer different questions.

Persistence also needs a concrete explanation. What process stays alive? What wakes it? What happens when the device sleeps, credentials expire or a tool becomes unavailable? A recurring task with a visible last-run result is easier to assess than an “always-on” label. A successful setup today does not demonstrate that next week’s run will complete without attention.

APIs and computer use

An API tool exposes structured operations: retrieve a record, create a document or update a specified field. Computer use works through the interface a person sees, which can extend reach to tasks without a suitable integration. The practical distinction is how an action is expressed and checked. Both routes need the correct account, enough context and permission for the intended change.

For example, a tool returning a document identifier gives the agent something concrete to retrieve and inspect. Clicking a Save button requires another observation to establish what was saved. Neither a successful function response nor a reassuring screen should be treated as proof of every part of the user’s goal. A document might exist while its dates are wrong. Completion requires checking both the artifact and its meaning.

Read availability claims carefully

The current landscape mixes usable products, limited access, previews and announcements. Microsoft’s September 25 post renamed Scout to Autopilot and said its private preview would expand at the end of that month. That statement is evidence of the announced plan. The fact that the date has passed does not establish that every intended user received access. Microsoft’s announcement.

The same discipline applies to feature lists. A demonstration shows a particular task under particular conditions. Documentation describes supported behavior and limitations. An independent test can establish an observed result for its configuration. None of these should silently stand in for the others. Keep the observation date alongside the evidence, because an accurate description of last month’s desktop workflow may be wrong about today’s cloud session.

A useful first evaluation

Choose a task with a small input and an output you can inspect without trusting the agent’s explanation. A source-based brief works well: supply several dated notices, including one that replaces an earlier plan, and ask for the current state with citations. Require uncertainty to remain explicit. Keep publication outside the task so that reviewing a mistake is inexpensive.

Then introduce a correction after preserving the first output. Ask the agent to revise the same artifact and explain what changed. This checks more than the first answer: it makes continuity, attribution and correction visible. A later exercise can test interruption and resumption, but only after the simple version has a clear expected result. These are proposed evaluation steps, not results from tests performed for this article.

There is an established research reason to look at outcomes and repetition. The 2024 tau-bench paper evaluates the resulting database state and consistency across repeated trials. Its historical measurements are not a leaderboard for today’s products. The useful lesson here is methodological: inspect the resulting state, and do not let one successful demonstration establish general reliability. tau-bench paper.

Record the exact product, model, configuration, supplied material and interventions. Count corrections you actually made. Keep unobserved cost or timing fields empty. If a run fails, distinguish an incorrect decision from missing access or an unavailable service; they require different remedies. A test becomes informative when another reader can understand both the outcome and the conditions that produced it.

This is the context for starting with OpenClaw. Its configurable Gateway, workspace and model connection make several of these responsibilities visible. The next step is a bounded setup and a small local exercise, followed by inspection of the result. Connecting more accounts can wait until the basic task, permission boundaries and correction behavior are understood.