Agents Don't Need Personas. They Need an Organization.

Over the past few months, I have seen every kind of agent harness appear. Most of them target a familiar set of problems: provide context, break work apart, run agents in parallel, and preserve some form of memory.

Then, after building all that infrastructure, we often organize the agents by calling them researcher, planner, coder, and reviewer.

Those names are not wrong. They describe things an agent can do. But they also feel derived from tool capabilities: one searches, another plans, another writes code, and the last one reviews it.

That made me wonder whether we were designing organizations for agents from scratch even though we have spent decades — or centuries, depending on how far we want to stretch the analogy — learning how to coordinate human organizations.

Software teams already know what a Product Owner does, which decisions belong to an architect, where a domain specialist's authority ends, and why the person who implemented a change should not be the only one declaring it correct. These roles are more than names. They carry boundaries, responsibilities, communication patterns, and governance mechanisms refined through years of practice, documentation, and some very expensive failures.

Models are also likely to know far more about those professions than about the “level-three planning agent” we just invented in a Markdown file.

That question became an internal set of Codex tools and configuration I am building for a modular project much larger than a single session.

“Collection of configuration” stopped being an accurate description rather quickly.

Better prompts were not the real problem

The project behind this experiment is meant to become a large modular system. Even before its full implementation exists, it already has product decisions, architectural boundaries, shared contracts, packages with different responsibilities, and work that can move in parallel.

One agent session can reconstruct much of that context and complete a task. The problem begins with the second session, then the third, then the tenth.

Each starts without durable memory of the others. It can read the repository and GitHub, but it still needs to know which information is normative, which decision remains open, whether someone else already claimed the work, what changed, and who is authorized to accept the result. If all of that lives in conversation history, the organization disappears when the session ends.

My first instinct was to write better instructions. Then I added specialized profiles. Then skills for repeatable procedures. The further I went, the clearer it became that context was only part of the problem.

The other part was organization.

A project contract, not another global prompt

The first artifact can be a small versioned file connecting knowledge sources, profiles, and policy:

{
  "knowledge": {
    "layers": [
      {
        "id": "product",
        "paths": ["docs/product/north-star.md"],
        "required": true
      },
      {
        "id": "runtime",
        "paths": ["docs/architecture/runtime.md"],
        "profiles": ["runtime-engineer"]
      }
    ]
  },
  "profiles": {
    "runtime-engineer": {
      "authority": ["Implement within the accepted contract"],
      "exclusions": ["Change product scope", "Break shared contracts"],
      "knowledge": ["runtime"],
      "acceptance": ["unit", "integration"]
    }
  },
  "policy": {
    "requireIndependentAcceptance": true
  }
}

The file does not contain the entire architecture or try to compress the product into JSON. It points to authoritative information and declares who may act on it.

The executable profile can stay short because it does not need to repeat all that knowledge:

name = "runtime-engineer"
description = "Implements bounded runtime responsibilities."

developer_instructions = """
Reconstruct area contracts and invariants before editing.
Work only within the claimed responsibility.
Record changes, checks, decisions, and discovered work.
Hand shared-contract changes to the architect.
"""

Specialization comes from combining those instructions with project-owned sources and authority, not from writing a three-page personality.

A role is not a personality

The system currently defines profiles for a Product Owner, architect, compiler engineer, runtime engineer, projection engineer, knowledge curator, and quality engineer.

I did not choose those names to stage a corporate role-play inside Codex. Each profile exists because the project already contains those responsibilities.

The Product Owner can own outcomes, scope, priority, and acceptance criteria, but should not unilaterally choose implementation architecture or end up writing the product. The architect can review boundaries, contracts, and invariants, but cannot expand product scope for technical convenience. Specialists implement within their areas. The quality engineer reconstructs the criteria and verifies evidence independently.

The important part is not the profile name. It is everything the name brings with it:

• explicit authority;
• positive responsibilities;
• exclusions;
• the knowledge it must load;
• the decisions it may make;
• the conditions that require a handoff;
• the evidence it must produce.

Telling an agent “you are an architect” provides a point of view. Declaring which contracts it may change, which decisions require an ADR, and which changes need coordination introduces governance.

That difference keeps roles from becoming interchangeable costumes worn by the same all-powerful agent.

Tools should belong to the project too

Another common pattern is to build a generic harness with generic tools and expect its agents to adapt to every repository. That works up to a point: reading files, running commands, querying GitHub, and opening a pull request are universal capabilities.

The important work, however, usually depends on project-specific operations.

In this system, context does not mean “read a lot of files.” It reconstructs a traceable context bundle for one profile and one responsibility: intended outcome, criteria, dependencies, affected areas, contracts, invariants, and required evidence.

next does not mean “pick something that looks useful.” It finds work eligible for the declared authority.

Before editing, a session requests a lease. Adding a label, assigning an Issue, and hoping no other agent did the same thing a few milliseconds earlier is not enough. Lease grants are serialized, expire explicitly, and carry a fencing generation so an old session cannot continue writing after losing its turn.

Its skills do not store product knowledge either. They expose procedures for claiming work, delegating, leaving a handoff, and verifying acceptance. Product facts remain in the repository that consumes the coordination layer.

That distinction changes the design. The harness stops trying to know everything and becomes a safe interface to the project's organization.

A session cannot be institutional memory

This decision brought the rest of the model into focus.

The model separates four layers:

A conversation may contain a useful discovery. A subagent may find a conflict. The architect may notice that a task requires changing a shared contract. None of it becomes memory until it reaches a persistent destination.

A normative decision belongs in an ADR or another versioned artifact. A blocker must record its evidence and the action required. Out-of-scope work becomes a separate responsibility. A handoff identifies who is sending, who must receive it, the impact, and the condition required to continue.

An agent's final summary helps the person watching that session. It is not organizational infrastructure for another agent starting tomorrow without access to it.

That is why GitHub acts as the control plane for work, not as the source of architectural truth. Issues, pull requests, checks, and workflow state connect independent sessions; versioned documents preserve decisions that should not be compressed into a label.

Governance without scheduling a robot meeting

Using organizational roles can sound like an attempt to recreate all of corporate bureaucracy with agents. That would be an impressively efficient way to automate the part nobody enjoys.

The goal is the opposite: preserve only the constraints that prevent expensive mistakes.

An agent cannot expand its own authority when delegating to a subagent. Parallel workers should not write to overlapping file sets. A task does not start until its lease is granted. A discovery does not silently become additional scope. When policy requires independent acceptance, a review subagent inside the implementer's session does not qualify: the parent retains responsibility and shares the same context and incentives.

This is not about reproducing human hierarchy out of nostalgia. It is about reusing separations of responsibility that already provide useful controls.

Human escalation is bounded too. The system should not ask me about facts it can reconstruct from the repository. It should stop when product direction is missing, a decision is irreversible or costly, invariants conflict, material risk exists, or the required information is owner-only.

Useful governance does not add ceremony. It removes ambiguity.

An organization outside its members

The part of this experiment that interests me most is not getting seven agents to run at once. Parallelism is relatively easy. Durable coordination is not.

A human organization does not stop existing when one person goes to sleep. Agreements, responsibilities, processes, and pending work remain in systems outside any individual. Independent agent sessions need the same property if they are going to collaborate rather than merely take turns.

That means an agent should be replaceable. A fresh session using the same profile must be able to reconstruct context, find eligible work, understand existing evidence, and continue without private memory. The profile contributes authority and method; the repository and GitHub provide continuity.

In that sense, the system is not trying to build a smarter agent. It is trying to let several partially informed agents work inside a system that limits what each one needs to know and keeps coordination from depending on remembering a conversation.

How I would design this for another project

The practical consequence is that The system should not install a “universal agent organization.” It can provide a coordination kernel, schemas, and safe operations, but profiles, knowledge, and many tools must come from the project consuming it.

I would not begin by asking how many agents I want. I would begin by mapping the work that already exists.

1. Find sources of truth before creating roles

First, locate where each kind of decision lives: product vision, accepted architecture, contracts, delivery state, quality criteria, and operational knowledge. If two documents contradict each other, adding agents only lets you produce inconsistencies in parallel.

The output should not be one enormous prompt. It should be a map of authoritative sources and their scope. A profile loads only the layers required for its responsibility. A compiler specialist does not need the entire commercial roadmap to fix the type system; a Product Owner does not need to traverse every runtime file to define an outcome.

2. Derive roles from real decisions

Ask:

• Which distinct outcomes does this project produce?
• Which decisions require specialized knowledge?
• Which contracts cross multiple areas?
• Which work needs independent verification?
• Where do handoffs already happen, even if one person currently performs both sides?

If you cannot state a role's authority and exclusions, it is probably still only a label. “Backend agent” says where it works. “Owner of the identity contract, without authority to change product policy” says what it may decide.

3. Design tools from domain verbs

Next, list the operations each role repeatedly uses to retrieve information or change project state. Include organizational verbs, not only technical commands.

A Product Owner may need create capability, split into tasks, and register discovered scope. An architect needs resolve contract consumers, create ADR, and request coordination. A specialist needs claim work, load area context, run domain checks, and hand off blocker. Quality needs reconstruct criteria, verify evidence, and accept or reject.

A useful tool turns an ambiguous decision into a verifiable operation. It validates authority, returns a structured result, and leaves a trace. If it merely wraps Git or a GitHub call without project semantics, it is still generic infrastructure.

A simple test helps: if the tool can be installed unchanged in any repository, it probably belongs in the base harness. If it must understand this product's contracts, states, invariants, or evidence, it belongs in the project's configuration.

A project-specific tool can expose one safe operation instead of letting every session improvise a sequence of mutations:

const result = await work.claim({
  workItem: issue.number,
  profile: "runtime-engineer",
  sessionId,
  idempotencyKey,
});

if (!result.granted) {
  throw new Error(`Work unavailable: ${result.reason}`);
}

return {
  lease: result.lease,
  context: await context.resolve({
    profile: "runtime-engineer",
    responsibility: issue.number,
  }),
  requiredEvidence: ["tests", "integration", "decision-links"],
};

The interesting part is not the TypeScript wrapper. The operation verifies profile eligibility, grants work atomically, and returns exactly the context and evidence that responsibility needs. A generic “assign Issue” call provides none of those guarantees.

4. Define a minimum contract for every profile

Personality instructions are optional. This contract is not.

5. Design one task's full path first

Before launching seven sessions in parallel, make one responsibility complete its entire lifecycle: intent, decomposition, claim, context, implementation, evidence, handoff, and acceptance. At every transition, ask what a fresh session would need if it had seen none of the previous conversations.

That exercise exposes real gaps. If the second session needs a person to explain what happened, something has not been persisted. If two profiles believe they can make the same decision, governance is missing. If nobody can demonstrate why the work is complete, the evidence contract is missing.

Only then add parallelism, leases, and reconciliation. More agents do not repair an incomplete workflow; they merely let it fail with greater enthusiasm.

6. Keep a human where direction exists, not by default

The system should autonomously resolve what it can reconstruct and verify. Human intervention remains necessary for product direction, irreversible or costly decisions, invariant conflicts, material risk, and information that has never been documented.

The goal is not to remove the human from every decision. It is to stop using the human as a USB drive between sessions.

It is still an experiment

The system is still under development and grew from the concrete needs of a private project. It currently includes seven profiles, skills for work, delegation, handoffs, and acceptance, plus a CLI that installs the project contract and reconstructs context. The lease and reconciliation protocol remains especially delicate: coordinating concurrent writes through GitHub takes more than chaining several calls that “usually” happen in order.

I also do not believe that copying a company org chart is automatically correct. A bad human organization does not improve when it runs faster, and some processes exist because of human constraints that may not apply to agents. The separation between authority, execution, and acceptance seems to survive the change in participants; many ceremonies probably do not.

For now, the hypothesis I want to test is more modest:

Agents do not need us to invent an entirely new organization just because they are new.

We can begin with professions, boundaries, and coordination mechanisms we already understand; turn them into verifiable contracts; give agents project-specific tools; and move memory out of their sessions.

The next step in agent systems may not come from building more convincing personas.

It may come from building small institutions that can outlive them.