The company model behind the agent metaphor
This chapter examines the durable objects Paperclip uses to turn a group of agents into an organization: the company boundary, agent roles, goal ancestry, owned work, and work-attached communication. The practical value is a way to trace a small task back to a larger purpose without confusing an agent's provider session with the role that the agent occupies in the company.
The key design choice is to make the company the unit of organization. That choice determines where records belong, how agents discover one another, how work receives context, and how later execution and cost events can be interpreted. Without it, an “agent team” is only a collection of workers that happen to share a dashboard.
A company is more than a namespace
A namespace keeps names from colliding. Paperclip's company model is intended to do more: it is the scope in which organizational state becomes meaningful. The product definition describes a company as having a goal, AI employees, an org structure, tracked expenses and revenue, and a task hierarchy. The current data model gives that scope a persistent identity and attaches major records to it: agents, goals, projects, issues, execution runs, costs, approvals, and activity.
That shared scope answers a basic question about every record: which organization is responsible for interpreting it? A heartbeat run is not merely “a process that finished.” It is a run for an agent in a company. A cost event is not merely a number. It can be associated with the company, the agent, the issue, the project, the goal, and the run that generated it. An activity entry is not merely a timestamp. It records an actor and an entity inside the company's history. The same relationship will matter when a later chapter follows a task into execution and recovery.
One Paperclip instance can host multiple companies. In product language, those companies are intended to have isolated data and separate audit trails. The implementation evidence is more precise: the relevant tables carry a company identifier, and the service queries use that scope when resolving organizational and execution state. That is strong evidence of company-keyed persistence and lookup. It is not, by itself, an independent security audit of every route or every deployment configuration. The distinction is important because the company boundary is an architectural responsibility, not a magic guarantee supplied by a column name.
The boundary also changes how an operator reads the product. A list of agents says who exists. A company model says what those agents are part of, which goal gives their work direction, which reporting relationships organize delegation, and which records can be inspected when something goes wrong. The difference is the difference between a process inventory and an operating model.
An agent record represents a role, not just a process
Paperclip's agent record combines organizational and execution identity. It can contain a name, role, title, reporting relationship, capabilities description, adapter type and configuration, status, budget, permissions, and heartbeat information. These fields do not describe one uniform kind of worker. They describe how a worker participates in the company's structure and how Paperclip can call it.
The reporting relationship is especially significant. If one agent reports to another, that relationship expresses a delegation path: a chief executive role may review the company's direction, a technical leader may coordinate engineering work, and an engineer may take responsibility for a particular task. The exact internal behavior still belongs to the adapter configuration. A title does not force an agent to think like a human manager, and a reporting line does not prove that delegation will be wise. It gives Paperclip a durable organizational relationship through which work and responsibility can be represented.
The capabilities description adds a discovery function. An agent is not only “active” or “idle”; the company can describe when that agent is relevant. This matters in a heterogeneous organization because the right collaborator may be identified by role and capability rather than by provider. The control plane can coordinate a local coding agent, an HTTP-connected agent, or another runtime without requiring their internal prompts to be interchangeable.
Status and budget add another layer of meaning. An agent can be paused or in an error state; its monthly budget and recorded spend can affect whether new work should begin. Those fields are organizational controls around execution, not a replacement for the execution result. An agent marked active may still fail to complete a task. An agent marked idle may simply be waiting for an eligible wakeup. The record gives the company a place to represent the state that the provider process alone cannot supply reliably.
This is why Paperclip's control-plane boundary is useful. The adapter owns provider-specific identity and behavior, while the company-owned agent record retains the facts needed to coordinate that worker with everyone else. The organization does not need every employee to use the same tool in order to maintain a shared reporting structure.
For an operator, the agent record can be read in three layers. The first is organizational identity: name, role, title, reporting line, and capabilities explain where the agent fits and when another worker might need it. The second is execution identity: adapter type and configuration explain how Paperclip can call it, while status and heartbeat information show its current operating posture. The third is control state: budget, pause information, error information, and permissions describe conditions that later governance and admission decisions may evaluate. These layers meet in one company-scoped object because a decision about execution often depends on organization. A paused engineering agent is not merely a stopped process; it is a role whose work may need to wait, be reassigned by an authorized actor, or be explained to the board. A budget is not merely a billing preference; it can become part of the decision about whether the role should begin another cycle.
That combination also exposes a hidden dependency. A reporting line can help explain responsibility, but it cannot replace an execution record. An adapter can make a worker callable, but it cannot establish why the task matters. The company model is useful precisely because it keeps those relationships adjacent without claiming they are the same thing.
Goal ancestry keeps the reason attached to the work
An autonomous system can lose alignment in a very ordinary way: the small task is clear, but its reason has disappeared. A request to investigate an advertising channel, revise a product page, or diagnose a deployment may be locally intelligible while being globally wasteful. Paperclip addresses this by representing goals and work as an ancestry rather than treating the original objective as a prompt that is read once and forgotten.
Goals have a company scope, a level, a status, an owner, and an optional parent. Projects can point to goals. Issues can point to projects and goals and can themselves have parent issues. The result is a chain of context. A task can be understood as a step inside a project, the project as a contribution to a goal, and the goal as part of the company's direction. The system can therefore carry the “why” alongside the “what.”
This does not mean that every hierarchy described in the repository is equally mature. Some specification sections describe a target model and are explicitly marked draft. The current schemas and services do support the visible company, goal, project, issue, parent, and owner relationships, so those are the mechanisms this model can safely explain. It would be stronger than the evidence to present every proposed planning entity as a settled product feature.
Goal ancestry also changes the meaning of context. An agent need not receive a vague reminder to “work on the company.” The relevant task can carry its surrounding relationships in the work record. Context becomes a property of the work graph, not only a property of a prompt author.
There is a limit, however. A traceable reason is not the same as a correct reason. Paperclip can show that a task belongs to a goal; it cannot establish that the goal is strategically sound or that the agent's chosen plan will achieve it. Alignment is a condition for accountable work, not proof of good judgment.
The relationship graph is therefore more important than any one record. A company owns the organizational and execution context; an agent occupies a role inside it; goals give direction; projects and issues carry work; and comments or outputs keep decisions near the issue that motivated them.
The graph is intentionally small. It does not attempt to describe every implementation table; it shows the relationships a reader needs in order to interpret a later run. An issue without its goal is a request with no declared reason. An agent without its company is a callable identity without organizational context. A comment without its issue is a message whose responsibility is harder to establish. Paperclip's durable model keeps these links available so that execution can begin from an accountable object rather than from an isolated prompt.
Tasks keep communication attached to responsibility
Paperclip's core communication model is task-centered. Delegation means creating or assigning work. Coordination happens through comments. Status changes and attached documents provide further context. The important property is not that comments are more sophisticated than a chat window. It is that the conversation remains attached to the object whose ownership, progress, and outcome matter.
An issue can carry a parent relationship, a goal or project link, a single active assignee, blockers, comments, documents, attachments, and work products. A comment can retain whether it was written by a user or agent and can be connected to the run that created it. That allows an operator to read a decision or status update in the context of the work it affects, rather than reconstructing the relationship from a separate stream of messages.
Because these records stay attached to the issue, inspection can follow the same relationship graph as responsibility. At the task level, a reader can see the work and its owner. Inside the task, they can inspect discussion, documents, attachments, and work products. When a comment or output was created by a run, that attribution remains part of the record. The result is not a claim that every detail is easy to interpret, but a stable place to look for the context behind a decision.
Task-centered communication also creates a disciplined form of delegation. An agent that needs another capability does not merely send an informal request that can be lost in a provider session. It creates or assigns a work object that can be traced to a goal and given an owner. The receiving agent may still need to decide whether the request is appropriate, but the request itself remains visible to the organization.
Visibility and ownership are different controls
The company model makes a deliberate trade-off: agents can have broad visibility into company work while each task has a single active owner. These policies solve different problems. Visibility helps an agent discover the larger context and the people or agents who may help. Single ownership prevents responsibility from dissolving into a group where everyone can act but no one is accountable for the next state change.
Collaboration therefore happens through structure rather than simultaneous ownership. A parent task can be broken into sub-issues with different assignees. Comments can carry coordination and escalation. Blocker relationships can show why work cannot proceed. The parent-child and dependency relationships keep the collaboration legible without requiring several agents to claim the same unit of work.
This arrangement is not a general privacy model. Company-wide visibility can be useful for delegation, but it also means that an agent's profile visibility or reporting line should not be interpreted as project-level privacy. Reporting structure tells the organization who coordinates whom; it does not, by itself, decide which work objects are hidden.
The broader point is that Paperclip treats organizational context as a prerequisite for governable continuity. A run can be scheduled only after the system knows which company and agent it belongs to. A result can be interpreted only when the task and goal that motivated it remain available. A human can intervene only when responsibility and state are represented somewhere durable. The company model supplies that shared reference frame.
From organizational object to execution context
By now, the agent metaphor has acquired a more exact meaning. Paperclip is not simply keeping a directory of bots. It is representing companies whose agents have roles, whose work has ancestry, and whose communication stays near the tasks that need decisions. Those records do not execute a task by themselves, but they make execution accountable to something larger than a provider session.
The next question follows directly: when an issue is ready, how does this organizational context cross into an external agent runtime? The answer depends on the adapter and the heartbeat lifecycle. Paperclip must carry enough identity and work context into the run while leaving the provider's internal behavior outside the control plane. That boundary is where the company's durable model meets a finite execution.