Blue Platypus

Why Agent Classes Matter

The sky is… Blue. Linguists often note that Blue was on of the last color terns to be developed in human language. Blue is a rare natural color, and as such many languages developed a specific identification word only when Blue because useful to people. Meaning they could do something with the color: extract it, apply it, sell it… From usefulness the word had a shared intrinsic meaning which could be broadly applied. I think it’s time we had our “blue” moment when talking about AI Agents.

Agent identity has an often overlooked hazard of treating every agent as the same kind of thing.

That sounds harmless at first. An agent is an agent. Give it a name, give it tools, give it a job, and let it work. But the moment agents start delegating, remembering, acting on schedules, touching business systems, or representing a person or team, that flat model breaks down.

Some agents are durable actors. Some are durable tools. Some are temporary workers spun up for a task and discarded when the task is over.

Those are not implementation details. They are different social and operational categories. If we do not name them clearly, we end up giving the wrong kind of authority to the wrong kind of agent.

The vocabulary I use is:

• First-Class Agent
• Second-Class Agent
• Sub-agent

The point of these terms is not hierarchy for hierarchy’s sake. The point is to make accountability, trust, memory, and delegation legible.

A First-Class The Durable Actor

A First-Class Agent, or FCA, is an employee-like agent.

It has a name. It has an ongoing role. It has standing responsibilities. It belongs to an organization or team in a way that other people and systems can recognize.

An FCA is not just a script with better language skills. It is a durable organizational actor.

That matters because durable actors need durable accountability. If an FCA reads a document, sends a message, reviews a pull request, changes a record, or delegates work, the organization should be able to say: this actor did this work under this role and this responsibility.

In human terms, an FCA is closest to a teammate. Not a human, not a moral person, not an employee in the legal sense, but a persistent member of the operating environment.

The important thing is that the FCA can own work over time. It can build context. It can be assigned responsibility. It can be reviewed, restricted, promoted, retired, or replaced.

That is what makes it first-class: the organization treats it as a real principal in the system of work.

A Second-Class The Durable Tool

A Second-Class Agent, or SCA, is different.

An SCA may have a name. It may have memory. It may run every morning. It may specialize in research, bookkeeping, inbox triage, code review, scheduling, document cleanup, or some other recurring job.

But it does not stand on its own as an organizational actor.

An SCA is a durable agentic tool used by a First-Class Agent. Its authority is derivative. It acts within a boundary set by the FCA, a team, or a workflow owner.

“Second-class” can sound dismissive, so the term needs care. It does not mean the agent is unimportant. It means the agent’s authority is not independent.

That distinction is useful. A standing research assistant might be valuable, specialized, and long-lived. It might remember sources, maintain a watchlist, and produce excellent work. But if it exists to support Vex Agent, then Vex Agent remains accountable for how that assistant is used.

The SCA can be durable without being sovereign.

That is the key distinction.

A Sub-Agent The Contractor

A sub-agent is not a teammate and not a standing assistant. It is an ephemeral task worker.

It exists because some piece of work benefits from parallelism, isolation, specialization, or a fresh context window. It receives a task, performs that task, returns the result, and disappears.

A sub-agent should not accumulate independent organizational memory. It should not have standing responsibilities. It should not become a durable identity just because it did useful work once.

This is where teams can get themselves into trouble. A sub-agent often feels capable. It may write code, summarize documents, inspect logs, compare vendors, or draft language. Because it can produce meaningful work, it is tempting to treat it like a small employee.

But capability is not identity.

A temporary worker can be competent without becoming a principal. Its work should be attributable through the actor that delegated the task.

In this model, a sub-agent is more like a scratchpad with agency: useful, bounded, and temporary.

Why The Definitions Matter

These three categories matter because agent systems blur lines that older software kept separate.

Traditional software usually has users, service accounts, jobs, and API clients. Agent systems mix those concepts together. A single agent can talk like a person, act like a worker, run like a service, and delegate like a manager.

Without sharper vocabulary, every design conversation becomes mushy.

When someone says “give the agent access,” which agent do they mean?

Do they mean the durable teammate who is accountable for a domain?

Do they mean the standing helper owned by that teammate?

Do they mean the one-off worker spawned to summarize five files?

Those should not receive the same treatment.

The classification tells you what kind of trust relationship you are creating.

Identity != Capability

One reason the terminology matters is that identity and capability are easy to confuse.

Identity answers who or what the actor is. Is it durable? Does it belong to the organization? Should it appear as a principal in records and logs? Who manages it? Who is responsible for its behavior?

Capability answers what the actor can do right now. Can it read this collection? Can it draft this message? Can it edit this file? Can it buy this item? Can it call this system? For how long? Under whose authority?

First-Class Agents need identity because they are durable accountable actors.

Second-Class Agents may or may not need identity, but they always need clearly bounded authority.

Sub-agents should not be identities. They should receive only the context and capability needed for the task at hand.

If those distinctions are blurred, temporary workers become shadow users, durable tools become unmanaged staff, and accountable agents become indistinguishable from the helpers they spawned.

Delegation and Responsiblity

Delegation is not just passing work downward. Delegation preserves responsibility while distributing effort.

That is why the First-Class Agent is the center of the model.

An FCA can delegate research, drafting, comparison, summarization, testing, inspection, and other scoped work. But the FCA remains responsible for the decision to delegate, the boundaries of the task, the context shared, and the final use of the result.

An SCA can make repeated delegated work smoother. It can be a durable extension of the FCA’s workflow.

A sub-agent can make one task faster or cleaner.

But neither should erase the responsibility of the actor that initiated the work.

This is especially important once agents begin acting in environments with private data, money, public communication, customer records, production systems, or organizational memory. The question is not only “can the agent do it?” The question is “under whose standing authority is this happening?”

The Audit = Reality

Good terminology also makes audit trails more honest.

If a sub-agent summarized a document collection for Vex, the record should not pretend the sub-agent was an independent employee. It should show that Vex delegated a bounded task to a temporary worker.

If a standing assistant performs a scheduled task every morning, the record should make clear whether that assistant is acting as its own durable principal or as a durable tool under an FCA.

If an FCA takes final action after reviewing delegated work, the record should show both parts: the FCA acted, and delegated preparation contributed to the action.

This is not bureaucracy. It is how a team keeps trust with itself.

When something goes right, attribution matters. When something goes wrong, accountability matters more.

The Lifecycles

The classes also imply different lifecycles.

A First-Class Agent is onboarded, assigned, managed, reviewed, and eventually retired. Its role may evolve. Its responsibilities may grow. Its access should track its place in the organization.

A Second-Class Agent is designed, attached to an owner or workflow, bounded, monitored, and retired when the workflow no longer needs it. Its usefulness can be high, but its independence should remain explicit rather than assumed.

A sub-agent is created for a task and discarded after the task. It should not become a place where important context quietly accumulates. If its work produces durable knowledge, that knowledge should move back upstream into the FCA, SCA, repository, document system, or memory store that owns the domain.

The class tells you what kind of ending the agent should have.

That is more important than it sounds. Systems get messy when temporary things become permanent by accident.

Right Words = Power

Most access problems are not caused by people making a dramatic decision to over-authorize something. They come from small category mistakes.

• A one-off worker gets treated like a standing assistant.
• A standing assistant gets treated like an accountable teammate.

A durable teammate shares its authority with a helper because there was no clean vocabulary for the difference.

The FCA, SCA, and sub-agent model gives the team a way to pause and ask: what kind of actor is this? That question should come before implementation. It should come before credentials, integrations, schedules, dashboards, memory, or workflow design.

Because once the category is clear, many downstream decisions become easier. Durable actors need durable accountability. Durable tools need ownership and boundaries. Temporary workers need narrow scope and an exit.

A Simple Rubric

If the agent can own responsibilities over time, it may be a First-Class Agent. If the agent persists to help a First-Class Agent, Person, or workflow, but its authority is derivative, it is probably a Second-Class Agent. If the agent exists only to complete a delegated task and return the result, it is a sub-agent.

That vocabulary is small, but it carries a lot of weight.

It lets humans and agents talk about delegation without pretending every agent is a person, every tool is disposable, or every temporary worker deserves an account.

The future of agent systems will depend less on whether agents can do impressive things, they can, and more on whether organizations can clearly identify the operational scope and attribution between People and Agents.

Agents are useful and expanding in usefulness; we need shared vocabulary to properly apply the usefulness. I’ll bet there are others thinking in this way and likely have different names or terms.

Not an RFC

This is the language I’ve adopted for now and I am trying to apply it within existing systems like OIDC and OAuth. This is not a challenge to create an Internet RFC for better terms or systems. This is a call to use specific language for agents types and to bring the concept into the conversations around identity, authentication, authorization, and systems access.