Ask ten technology leaders what an AI agent is, and you will get ten answers. Ask the same ten in six months, and the answers will have changed. The word has become the most contested term in the AI infrastructure conversation, and the lack of definitional clarity is compounding. Vendors sell against it. Standards bodies write specs around it. Boards approve budgets for it. Compliance teams write policies governing it. All of this is happening before the industry has settled on what the thing actually is.

The reason the question matters is that the definition is about to be baked into infrastructure that will run for a decade. The IETF is publishing drafts. The IAM industry is shipping products. The Kubernetes community is writing CRDs. Each of these encodes a definition. If the definitions are wrong, the systems built on top of them inherit the wrongness, and unwinding takes years.

There is a precise structural distinction that cuts through the noise. Workloads handle the known. Agents handle the unknown. The known set of tasks, fixed at deployment, executable by a process bounded in scope and time, is a workload. The unknown set of tasks, emerging at runtime, dynamically shaped by reasoning and negotiation, is the territory of an agent. Everything else in the definitional fight (the protocol primitives, the identity model, the governance envelope, the orchestration shape) follows from that single distinction.

This piece walks three lenses through that distinction. The past, where most things called agents are workloads in disguise. The present, where the real architecture for handling the unknown is starting to emerge. And the future, where the unknown expands, and the agent substrate must grow with it. The known/unknown line runs through all three.

Definition: An AI agent is a governed substrate with persistent identity, independent of any particular task, that compiles unknown work into structured task fabrics, orchestrates those fabrics across resources and counterparties, and executes them under continuous governance.

The past, and still today: macros wearing a costume

A macro is a workload. It executes a fixed sequence of steps, possibly with conditional branches, possibly with parameters. The task set is known when the macro is written. The execution is deterministic in the relevant sense: given the same input, the macro does the same thing. This is the textbook case of a workload, and the workload-identity primitives the industry has spent ten years refining (SVIDs, mTLS, deployment-bound credentials) handle it correctly.

A macro that gets called an “agent” is still a macro. Adding a model call in the middle of the sequence, sprinkling natural language descriptions across the steps, or putting a chat interface on the front changes the marketing but leaves the underlying artifact intact. The task set is still known at the time of deployment. The execution is still bounded by what the developer wrote. The branching is still hand-coded. Everything that made the artifact a workload before the agent label was applied remains true after.

This is what gets called agent washing, and it deserves to be named honestly. By my reading of the market, more than half (maybe 75%) of what is sold as an “AI agent” today is scripted automation with a model in the prompt loop. The seller has a strong incentive to use the agent label because it commands a premium. The buyer has little incentive to push back because they rarely see the implementation. The result is a product category that calls itself one thing while structurally being another.

A recent conversation with a leadership team at a major professional services firm illustrated the pattern. The firm had launched an “AI agent practice.” Several engagements were underway. The pitch decks were ambitious. When we drilled into what the agents actually did, the answer kept coming back the same way: they followed a fixed sequence of steps, branching on a handful of conditions, and calling out to a model for text generation at specific points. The task set was known.

The honest assessment is that yes, these are workloads. They handle the known. The IETF’s WIMSE working group, looking at this market and concluding that “agents are workloads,” is accurately describing this segment. The mistake is generalizing from here to all agents. The known case is real, and the workload-identity tools handle it. The unknown case is what the rest of the conversation is about, and the tools that handle the known break the moment the task set stops being knowable in advance.

The present: when the workload definition breaks

Strip away the agent washing market and look at what real agent systems are starting to do, and the known/unknown line becomes the structural boundary that nothing else explains.

A real agent receives a goal at runtime that the deployment never anticipated. It reasons about what tasks accomplish that goal. The task set was unknown a moment ago and now has to be discovered, structured, and committed to. Halfway through executing the discovered plan, the agent encounters conditions that change which tasks are needed. A counterparty becomes unavailable. A delegation opens up. A user changes their mind. The task set at minute thirty differs from the task set at minute zero, and the entity making decisions about what to add or remove is the agent itself.

This is the precise moment when the workload definition breaks down. A workload, by definition, has a bounded set of tasks knowable at deployment time. The agent’s task set is unknowable at deployment time because it depends on goals that arrive at runtime, reasoning that occurs at runtime, and conditions that evolve at runtime. The dimension that workload identity has never had to represent (the dynamic, adaptable, runtime-shaped task set) is the dimension that defines an agent.

The Compiler takes an unknown workload (a goal, a partial specification, a request that has yet to be decomposed) and turns it into a structured, addressable representation. It canonicalizes intent. It decomposes goals into atomic tasks. It surfaces ambiguity explicitly. It produces governance metadata about which constraints apply. The output is a Task Fabric: a verifiable, portable artifact that captures the currently best understanding of the unknown and is ready to be revised when new information arrives.

The Orchestrator takes the Task Fabric and turns it into an executable plan against currently available resources. It resolves dependencies. It delegates across agents through protocol primitives. It negotiates capabilities at runtime when available resources do not match the requested work. It inserts governance checkpoints. It can rewrite the fabric when execution returns signals about what is actually happening on the ground.

The Executor walks the plan and causes state change. It invokes tools and connectors. It manages local state and rollback. It emits attribution. It respects intervention hooks from the governance layer. It feeds results back into the Compiler and Orchestrator so the loop can adapt when the unknown reveals more of itself.

These three phases are inseparable from each other. None of them is the agent by itself. The agent is the substrate that runs the loop, with identity that exists independently of any particular workload the loop happens to be processing.

This is the framing that distinguishes a real agent from a glorified macro. A macro has the task set written into its code: the known case. A real agent has a task set that emerges from the loop: the unknown case. A macro’s identity is its deployment context, because the deployment is the entity. A real agent’s identity is its origin record, because the agent persists across whatever workloads it ends up processing. A macro produces audit logs as a side effect of running. A real agent produces signed attribution as a structural output, because attribution is the only way to make sense of an unknown task set after the fact.

The known/unknown line is what determines which set of primitives applies. Known task sets: workload identity, deployment-bound credentials, application-layer audit. Unknown task sets: persistent canonical identity, wire-level authority enforcement, cryptographic attribution. The two architectures are different, and trying to handle the unknown case with known-case tooling is the source of most failure modes that show up when real agents are deployed at scale.

The trajectory: more unknown, more substrate

The third lens is where the known/unknown line bends sharply away from the workload definition and stays there.

Agents are becoming more independent. They are running longer. They are taking on broader task surfaces. They are delegating to each other without continuous human supervision of each delegation. They operate across organizational boundaries, regulatory regimes, and model generations. The trajectory is unmistakable, and every step along it expands the unknown the agent must handle.

This is where the language has to be careful, because “independent” is often used as a synonym for “autonomous,” and the two differ in ways that matter.

An agent with independence of execution can handle more unknown without escalating to a human at every step. It can decompose new goals. It can negotiate with counterparties. It can adapt to drift. It can compose plans from emergent sub-goals. The value of an agent grows with how much unknown it can handle correctly, which is why the trajectory is toward more independence.

Agents are NOT autonomous. But by marketing definition, “An autonomous agent,” in the strong sense the word sometimes implies, would handle the unknown without any governance envelope at all. No accountable owner. No declared scope. No audit trail. No counterparty verification. This is the version of agent autonomy that doomer discourse worries about, and that careful infrastructure work should make structurally impossible.

These are different things. The trajectory points toward more independence, never toward autonomy from accountability. The protocol primitives have to make the distinction precise.

What this means for the substrate is counterintuitive at first and structurally obvious on reflection: as the agent handles more unknowns, the underlying governance has to become more rigorous, never looser. The Genesis record becomes more important, because it is the accountability anchor that survives the agent’s increasing operational latitude. The Owner-ID becomes more important, because someone has to remain accountable as the scope of unknown work expands. The Authority-Scope on every request becomes more important, because the scope is what keeps independence from sliding into unconstrained behavior. The Attribution-Record becomes more important because the audit trail is what lets a regulator, three years from now, reconstruct what an agent did with the unknown it was handed.

The known/unknown distinction is what makes all of this load-bearing. Workload primitives can govern the known case because the bounds are stated up front. They cannot govern the unknown case, because there is nothing to bound at deployment time. The agent substrate has to perform bounding at runtime, on every request, against an unknown that may have just appeared. The governance envelope has to be carried by the protocol, because there is no application-layer place to put it that survives the dynamism.

There is one more property of the trajectory worth naming. Agents are becoming ephemeral in execution while remaining persistent as entities. An agent might spawn thousands of ephemeral execution instances over its lifetime, each one short-lived, each one carrying a slice of the agent’s identity and scope. The persistent entity in the registry stays the same across all of those instances. The instances come and go. The entity remains. This is what makes the Genesis-derived canonical identity necessary: only a content-derived, infrastructure-independent identifier can keep the persistent entity stable across an arbitrary number of ephemeral instances handling an arbitrarily large, unknown number.

The future agent is independent enough to handle more unknown than today’s agent, ephemeral in execution against a persistent entity, and more deeply governed at the protocol layer than any application can deliver. None of those properties survive the workload definition. All of them follow directly from taking the unknown seriously.

The definition, in one sentence

An AI agent is a governed substrate with persistent identity, independent of any particular task, that compiles unknown work into structured task fabrics, orchestrates those fabrics across resources and counterparties, and executes them under continuous governance.

A workload is one part of that definition (the work the substrate happens to be doing right now, captured as a Task Fabric, in any given moment of the loop). The substrate that compiles, orchestrates, executes, and persists is the agent. The work it handles is unknown at deployment and known by the time it executes. The known/unknown line is exactly where the workload definition ends, and the agent definition begins.

Treating an agent as a workload throws away everything that makes it agentic. The dynamic task set. The runtime reasoning. The cross-organizational delegation. The emergent goal decomposition. The continuous governance envelope. The ephemeral execution against a persistent entity. Each of these exists because the agent is built to handle the unknown. None of them exist in the workload case because it has nothing unknown to handle.

The agent-washing market keeps producing macros called agents (workloads that handle the known) and asking the standards community to treat them as the canonical case. The real agent infrastructure is being built for something else (substrates handling the unknown), and the choice the next two years of standards work has to make is which case to design around.

AGTP is built for the unknown case. The compile-orchestrate-execute substrate runs inside it. The Genesis carries the persistent identity. The Authority-Scope constrains independence at the wire. The Attribution-Record produces the audit trail. The federation lets agents cross organizational boundaries. The trust tier carries credentialing depth that survives time.

This is what an AI agent is. A substrate built for the unknown, with everything that follows from that commitment. The macros wearing the costume are something else. The workloads being labeled as agents are something else again. The category that deserves the word is the one being built now, on the substrates the agent ecosystem will depend on for a decade.

Known versus unknown. Workload versus agent. The line is structural, and once you see it, everything else about the infrastructure conversation falls into place.

---

If you find this content valuable, please share it with your network.

Follow me for daily insights.

Book me to speak at your next event.

Start managing your agents for free.

Chris Hood is an AI strategist and author of the #1 Amazon Best Seller Infailible and Customer Transformation, and has been recognized as one of the Top 30 Global Gurus for Customer Experience. His latest book, Unmapping Customer Journeys, is available now!