Table of Contents

What makes an AI agent autonomous? Not the model, and not how many agent tasks you coded. What makes an AI agent autonomous is the set of capabilities it can compose at run time. That is the short answer to which capability is focused on autonomous AI agents: general-purpose capabilities — search, query, traversal, delegation — rather than hard-coded tasks.

The difference between an “AI agent” that feels fake and one that feels autonomous is not the model. It is what you build ahead of time. Scripted agents require you to code each task in advance. Autonomous agents require you to install general capabilities and let the agent compose the task at run time. That single shift — from coding tasks to installing capabilities — is the threshold of autonomy. If you want to understand AI agent capabilities in one sentence: agent capabilities are what the agent can do; agent tasks are what someone already told it to do. Autonomy lives in the gap between them.

The old shape: intelligence on top, human labor underneath

For a long time, building an enterprise “AI agent” meant writing a deterministic program underneath and letting the model call it. Every outcome you wanted — generate a trip plan, summarize a case, draft a report — had to exist first as a hand-built task: a flow, a script, a template. The model classified the request and routed it to one of those pre-built actions.

In that design, the intelligence lives only in the matching step. The capability is authored, in full, by a human at build time. Anyone who has built one of these has had the same deflating thought: this isn’t really AI — a human is doing all the work underneath, and the model just picks which pre-written thing to run.

The consequence is a hard ceiling. A scripted agent can only do what its builder already imagined and coded. Ask for something the builder didn’t anticipate, and it structurally cannot respond, no matter how capable the underlying model is.

The new shape: install capabilities, compose at run time

An autonomous agent inverts the preparation. You do not pre-build the tasks. You install a set of general, first-order capabilities, and the agent plans, calls, observes, and re-plans against them at run time.

Concretely, a user might type “make me a trip plan for the account I’m visiting,” and — with no task-specific code written for “trip plan” — the agent searches records, pulls the relevant opportunities, open issues, and account context, and assembles the document itself. Nothing about “how to build a trip plan” was coded ahead of time. The agent composed it.

This is the source of the “wow” reaction. It is not that the model got smarter. It is that the location of capability moved from build time to run time — from a human’s pre-coded task list to the agent’s live composition of primitives.

Which capabilities have to be installed

If the agent isn’t given tasks, what is it given? The answer is a set of capability categories broad enough that most requests can be served by composing them. In practice these cluster into a few families:

• Broad search — the ability to search across the full record estate and across collaboration history, not just a single pre-wired object.
• Direct structured query — the ability to run queries itself, rather than depend on a developer to have written the exact query in advance.
• Metadata and schema traversal — the ability to discover what objects and fields exist and how they relate, so the agent can figure out how to fetch something it was never explicitly told about.
• People and org context — the ability to resolve who someone is, their reporting line, their peers.
• Delegation — the ability to hand a sub-task to another specialized agent.

The important design point is that none of these is a task. Each is a capability. “Generate a trip plan” is a task; “search the record estate” and “run a query” are capabilities. When the installed capabilities are broad enough, the set of achievable tasks stops being an enumerated list and becomes whatever the agent can compose — which is why builders describe it as doing things they never explicitly built.

The consistency problem this creates — and how it’s handled

Composition has a price. Because the agent reasons its way to each answer, the same request can produce slightly different output each time: different formatting, different fields, different structure. The old fix — pin the path with code — throws away the flexibility you just bought.

The better fix is to pin invariants, not paths. You put the format, the required data sources, and the must-follow rules into a reusable prompt specification — often surfaced as a “skill” or “playbook” record — and tell the agent to answer against that specification. Give it a format spec and it produces to that format; give it none and it free-styles (which is often acceptable). What you pin becomes the invariant; what you leave open stays the agent’s to compose. The configuration layer moves from code into prompt.

The boundary that remains after you cross the threshold

Installing capabilities does not make everything possible. There are lines an autonomous agent still does not cross on its own, and it’s worth naming them as design boundaries rather than product complaints — they recur across implementations.

The most consistent one is the read-versus-write boundary. A mature autonomous agent will happily search, query, and read across the estate, but writing — updating a record, changing state — is typically not in its default scope. It requires an additional, explicitly granted tool or action. This is a sensible default, not a limitation to be annoyed by: the cost of a wrong read is a bad answer you can discard, while the cost of a wrong write is a corrupted record and an audit trail to unwind. The asymmetry in reversibility is why read is the default and write is opt-in.

Other boundaries follow the same logic — what the agent can accept as input, what it can persist, what it can parse. The useful question is not “what can’t this product do this quarter” (that changes constantly) but “where do boundaries appear once the capabilities are installed, and why do they sit where they sit.” The answer, almost always, is reversibility and auditability.

Frequently asked questions about AI agent capabilities

Which capability is focused on autonomous AI agents? The capabilities that make an agent autonomous are the general-purpose, first-order ones it composes at run time — broad search, direct query, metadata and schema traversal, people/org context, and delegation to other agents. None of these is a task. Each is a capability. Autonomy comes from installing capabilities like these and letting the agent assemble tasks from them, instead of pre-coding the tasks themselves.

What is the difference between agent tasks and agent capabilities? An agent task is a specific outcome someone coded in advance — “generate a trip plan,” “summarize this case.” An agent capability is a general power the agent can apply to many situations — “search records,” “run a query.” Scripted agents are built from tasks and can only do what was pre-coded. Autonomous agents are built from capabilities and can handle requests nobody explicitly built.

How do you understand AI agent capabilities in practice? Look at what the agent was given before any request arrived. If it was given a list of finished tasks, it is a scripted agent. If it was given a toolbox of capabilities and decides at run time how to combine them, it is autonomous. The location of the capability — build time versus run time — is the whole distinction.

Does a more capable model make an agent autonomous? No. A better model improves reasoning, but autonomy is a design property, not a model property. An agent is autonomous when capability lives at run time in the agent’s composition, not at build time in a human’s task list. You can put a state-of-the-art model behind a fully scripted agent and it will still only do what it was pre-coded to do.

Takeaway

Building an autonomous agent is not coding tasks — it is installing capabilities. The moment the location of capability moves from build time to run time, the agent starts handling things its builder never explicitly imagined. That is the threshold. Everything after it — consistency, the read/write boundary — is about managing the freedom you just granted, not about scripting it away.

Related: for the distinction between a scripted “agent” and a real one, see the companion piece on what separates natural-language automation from a true agent.