YC's Org Code Idea: Designing Companies for Agents
A YC launch for Pentagon puts a useful name on an emerging practice: agent teams need explicit, testable organization design.
A recent Y Combinator launch for Pentagon uses the phrase "org code" for something agent builders are already discovering: the structure of an agent team can be defined, run, inspected, and changed like software.
Pentagon is building a coordination layer where agents communicate, delegate tasks, share context, and maintain memory. The product represents agents spatially so a human can see which ones are active, idle, or blocked.
The human is becoming the middleware
Most multi-agent workflows still rely on a person copying context between tools, deciding who works next, and reconciling conflicting output.
That may be acceptable for an experiment. It becomes the bottleneck when agent work is continuous.
An explicit organization layer can define:
- which agent owns a decision
- what context each role can access
- when work can be delegated
- which outputs require approval
- how disagreement is resolved
- what evidence closes the task
Those rules are more important than a visual org chart. They are the executable operating model.
Agent organizations can be reproduced
A human organization contains habits and relationships that are difficult to copy exactly. An agent workflow can preserve prompts, tools, permissions, routing rules, memory boundaries, and evaluations.
That makes the organization reproducible, but not automatically reliable. A copied workflow can reproduce the same design mistake at greater scale.
Versioning and evaluation matter. Teams should be able to answer which org configuration handled a task, which agents participated, what changed, and whether the new structure improved the result.
Dynamic structure is the real opportunity
The right team depends on the problem. A customer incident may need a researcher, an operator, and an approver. A product migration may need a planner, several implementers, and a verification agent.
Software-defined teams can assemble around the task and dissolve afterward. That is more interesting than permanently assigning a named bot to every human department.
What companies should do now
Start with one workflow and write the operating rules before adding more agents.
Define ownership, inputs, allowed tools, escalation, completion evidence, and a recovery path. Log every handoff. Then compare the multi-agent version with a simpler single-agent or human process.
If the organization layer does not improve quality, speed, or accountability, it is decoration.
The useful idea behind org code is not that agents should imitate a company. It is that coordination can become an explicit engineering surface.
Bhaulik Patel
Forward deployed AI engineer and creator of Deployed Engineer.