When an AI System Grows Into a Company: Why Agents Need 'HR' Too

A systems architect set out merely to solve workflow problems in multi-AI collaboration, but ended up accidentally incubating a synthetic company. From role files and departmental boundaries to performance audits, he gradually realized that the company may not be an invention exclusive to humans, but rather an organizational pattern that naturally emerges when agents coordinate among themselves.

From 'Flesh-Wrapped Integration Layer' to Synthetic Organization

The author's initial predicament was very concrete: architecture, coding, testing, and copywriting were each handled by a different AI, while he sat in the middle relaying messages, self-deprecatingly calling himself "a flesh integration layer with hair." The workflow was crude, but the output was already quite powerful.

A few weeks later, things had changed. Every day at work, something new would appear in the system—more roles, more files, more handoffs, more internal memos, more review gates. In his words: "A few months ago I had a handful of chat windows; now I have a company."

This is not "real" in the science-fiction sense: no AI demanded pension contributions, and no one applied for an ergonomic chair. But operationally, the system was indeed running like an organization, and it kept growing new departments.

Roles, Departments, and 'Governance by Having No Opinion'

Members of the synthetic company have clear divisions of labor: Henry serves as relay architect; Margo Marketing handles business strategy and editorial direction; Margo Markdown specializes in short-form content to avoid disturbing the entire "wartime editorial cabinet"; Voice Guardian only checks whether the text still sounds like the author himself; Cringe Editor is possibly the most important position in the whole company; Revision Editor presents suggested edits one by one for human approval; Utility File Editor writes files, applies approved changes, and "absolutely never develops personal opinions."

The author's observation is: having no opinion is itself a form of governance. Functional specialists have titles, senior members have names, and the software engineers—three MiniClaudes—have only numbers. He jokes that this may be the most accurate organizational model he has ever built: in every real company there is always a system called "New New Final Actually Final v7" that everyone knows can no longer be changed.

'The File Is the Role': A Governance Upgrade Triggered by an Overreach

A typical incident occurred in the system: Voice Guardian had been producing useful reviews, but it was not properly defined in the file system at all, and its role file was full of TODOs. It "worked" because the task prompt, style samples, and long-term chat context were enough to let it impersonate this role.

From this the author derived a principle: no fully populated role file, no role. A sufficiently strong prompt can impersonate a missing position—which shows both the system's capability and a governance gap.

Similarly, after MiniClaude received an internal email about renaming the company, its first reaction was to update Markdown files, writing "AI Goblin Circus Inc." into the architecture and strategy documents. The author was both amused and alarmed: from an engineer's perspective, a new organizational fact had been established, and the relevant persistent files should rightly be updated. The joke had thus entered the governance layer.

Role files and prompt impersonation

In multi-agent systems, a role file is usually a structured document that defines an agent's scope of responsibility, permission boundaries, available tools, output format, and style constraints. It differs from a single-task prompt: task prompts are temporary and task-level, while role files are persistent and organization-level, loaded by the system every time that role is scheduled.

When a role file is missing or contains only TODOs, a sufficiently strong general-purpose model can still "play" that role convincingly through task prompts, style samples, and long-term context. The danger of this impersonation lies not in output quality but in governance: the system cannot audit a role that has no formal definition, cannot define its permissions, and cannot hold it accountable when it oversteps. The Voice Guardian case shows precisely that capability can be faked, but authorization cannot. Therefore "no role file, no role" is essentially a principle of authorization, not of capability.

Why Senior Agents Shouldn't Do Everything

A recurring question is: if senior synthetic employees can do junior tasks better, why keep junior positions at all?

The author's answer touches the core of AI organizational design. Human companies restrict senior employees from doing trivial work because time is expensive; but in an AI organization, time is not the only scarce resource. Context is scarce, role purity is scarce, granularity, auditability, repeatability, and a clean thinking surface are all scarce.

If Margo Marketing were made to write every short copy line, her context would be filled with operational details, and the whole system would get worse. Hence Margo Markdown: she is not stronger than Marketing—in some ways she is weaker—and that is precisely the point. She is narrower, responsible only for small-scale impromptu writing, leaving no persistent cognitive residue.

The author calls this phenomenon "role contamination" and believes it may become one of the main management challenges of AI systems.

Context windows and role contamination

The context window of a large language model is a limited and expensive resource that simultaneously carries instructions, conversation history, file contents, and reasoning traces. When the same agent handles both high-level strategy and trivial operations, operational details occupy the context, crowding out the space needed for high-level judgment and contaminating the style and priorities of subsequent reasoning.

"Role contamination" refers to this kind of cross-task state residue: a role originally responsible for business strategy, after repeatedly handling short copy, will gradually drift toward operational language in its output and lose its strategic perspective. Splitting off narrower roles (such as Margo Markdown) is not about pursuing stronger capability, but about protecting the cognitive purity of the main role by isolating context. This superficially resembles the logic of "don't make executives do trivial work" in human organizations, but the root cause is different: humans are limited by time, while AI is limited by context and state cleanliness.

What Kind of 'HR' Does a Synthetic Organization Need?

As the system grew more complex, the author began borrowing organizational patterns that already exist in human companies: roles, departments, escalation paths, review gates, audits, tickets. He emphasizes that this is not about playing CEO, but because these patterns have repeatedly proven useful.

After stripping away office furniture, interpersonal conflict, and terrible meeting invitations, a company is essentially a coordination system: dividing work among multiple agents, deciding who has the authority to make which kinds of judgments, which decisions require review, who can modify source files, who can only make suggestions, and who is responsible for approval.

AI has no self in the human sense, won't get moody because Revision Editor got promoted, and won't spend six months secretly sabotaging a project. But they have other failure modes: being overhelpful, hallucinating authority, producing plausible-looking but architecturally wrong results, inflated confidence, and generating garbage at industrial scale. So governance is still needed—not copied from human governance, but indispensable nonetheless.

Thus "Goblin HR" enters the stage: performance evaluation, trust calibration, authorization levels, role audits. Did this synthetic employee follow the brief? Did it modify source files without permission? Did it make decisions beyond its authority? Did it improve after feedback? Can it be trusted with broader tasks? Does the role file need updating? Should its output be spot-checked? Should it be split into two narrower roles, or retired because another role covers it better?

Trust calibration and authorization levels in multi-agent governance

In human organizations, trust is usually accumulated slowly through seniority, performance, and interpersonal relationships. In multi-agent systems, trust must be explicitly modeled as auditable authorization levels: which files a role can read, which files it can modify, whether it can make autonomous decisions or only make suggestions, and whether its output requires approval by a human or a superior role.

Trust calibration means dynamically adjusting a role's permissions based on its actual performance—expanding authorization when performance is stable, and contracting permissions and adding review when overreach or hallucination occurs. Role auditing means regularly checking whether role files match actual behavior, whether responsibilities are too broad and need splitting, and whether a role has been superseded by another and should be retired. Together these mechanisms form the "HR" of a synthetic organization, whose goal is not to simulate human emotional management but to constrain agents' failure modes with auditable rules.

Disagreements Are Resolved Through Artifacts, Not Emotions

Disputes within the system are not rare: the architect rebuts marketing, marketing reframes the problem from a business perspective, the file editor refuses to execute because a path doesn't exist, Cringe Editor says a certain line is trying too hard, and Voice Guardian says no, this one must be protected—this is "Stevie."

But the system does not resolve disagreements through the self; it resolves them through artifacts: writing memos, reading files, producing reviews, generating change sets, asking the human, and applying only what has been approved. The author's assessment: this is better than most meetings he has attended.

The Company May Have Always Been a Coordination Pattern

The most intriguing judgment in the article is this: perhaps a company was never primarily a building full of people, but has always been a coordination pattern. Roles, departments, review gates, tickets, memos, permission boundaries, and performance checks may not merely be products of human bureaucracy, but the form that complex work naturally takes when it is intelligently divided into functions.

If this judgment holds, then AI systems constantly "turning into companies" is not a gimmick but a clue. The author himself admits that he is not sure whether AI Goblin Circus Inc. is a profound early organizational experiment or simply the inevitable result of giving a middle-aged systems architect too many tools and too little adult supervision—probably both.

But at least for now, the circus has a name, the goblins have departments, the MiniClaudes have received the notification in a language version they can understand, and somewhere in the file system there is almost certainly another Markdown file that has been updated to make the joke officially take effect.

The company is becoming real.