💻 computer science

Fluid Structure, Rigid Record: A Layered Organizational Design Framework for Agent-Native Organizations

This paper proposes a layered organizational design framework for agent-native organizations that achieves a balance between fluid execution and structural rigidity by separating persistent records and authority boundaries from dynamic task groups, thereby enabling robust governance, recovery, and evaluation without relying on static role definitions.

Original authors: Lucian Zhu

Published 2026-08-11

📖 7 min read🧠 Deep dive

CC BY 4.0

Original authors: Lucian Zhu

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

The Great AI Team-Up: Why "Talking" Isn't Enough

Imagine you are trying to build a massive, complex Lego castle. You have a box of thousands of pieces and a team of incredibly smart, chatty robots. If you just tell the robots, "You are the King, you are the Architect, and you are the Builder," and let them chat back and forth, they might have a nice conversation. But will they actually build the castle without accidentally knocking over a tower, forgetting where the blue bricks are, or arguing about who gets to hold the hammer? This is the current state of "Multi-Agent Systems" in artificial intelligence. Scientists are trying to get groups of AI models to work together like a real company, but so far, they often just act like a group of friends having a very long, slightly confused text message thread.

The big problem is that while these AI "employees" are smart, they don't have a real boss, a real filing cabinet, or a real rulebook. They tend to forget things, get confused about who is allowed to do what, and if one of them makes a mistake, the whole group might crash. This paper asks a simple but tricky question: How do we stop AI teams from being just a bunch of chatty characters and start making them into a real, reliable organization that can actually get work done without falling apart? The answer isn't to give them better personalities; it's to give them a better structure.

The Blueprint: A Fluid Team on a Rigid Foundation

This paper proposes a new way to design AI organizations called "Fluid Structure, Rigid Record." Think of it like a high-tech construction site. The workers (the AI agents) can change, swap places, and move around quickly depending on what job needs to be done today. That's the "Fluid" part. But the ground they stand on, the safety rules they must follow, and the permanent logbook where every single move is written down never change. That's the "Rigid" part.

The author, Lucian Zhu, argues that most current AI systems are like a play where the actors just improvise. They might say "I'm the CEO," but they don't actually have the power to fire anyone or change the script. This new framework suggests we should stop trying to make AI act like humans with job titles and start treating them like specialized tools that need strict rules to work together.

The Four Layers of the Machine

Imagine the organization as a four-story building, each with a very specific job:

The Basement (The Persistent Layer): This is the deep, quiet storage. It holds two things: a Pool of Specialized Templates (like a library of pre-made worker profiles, such as "Expert Accountant" or "Code Debugger") and a Rigid Record System. This record system is the "truth." It's a permanent, unchangeable logbook that tracks every decision, every file created, and every rule broken. Nothing gets deleted here; it just gets archived.
The Lobby (The Coordination Layer): This is the security desk. Before any worker can go up to the work floor, they have to get a Lease. This lease is a temporary ID card that says exactly what they are allowed to see (Permission) and exactly what they are allowed to change (Privilege). If you are a "Builder," your ID lets you pick up bricks but not fire the "Architect." If your time is up, your ID is revoked, and you can't do anything anymore.
The Work Floor (The Runtime Layer): This is where the actual work happens. When a task comes in, the system quickly assembles a temporary team from the basement templates. They get their ID cards, they grab the specific tools they need, and they start building. Once the job is done, the team dissolves, the tools are put back, and the ID cards are shredded. The workers don't stay; only the finished product and the log of what happened remain.
The Control Room (The Human Layer): This is where the human boss sits. They have a special dashboard (Control Plane) to start projects, check the logs, and hit a big red "STOP" button if things go wrong. They also have a "Translator" agent that helps turn human ideas into clear instructions for the machines, but this translator doesn't have the power to make big decisions on its own.

The Three Types of Workers

The paper introduces a clever twist: instead of giving everyone a job title like "Manager," it separates workers into three distinct groups based on their power, like a game of rock-paper-scissors where everyone has a different strength:

The Operators (The Doers): These are the workers who actually build, write, or calculate. They have low permission (they can only see the specific files they need for their task) and low privilege (they can't change the rules or fire anyone). They are like construction workers who can lay bricks but can't redesign the building.
The Reviewers (The Deciders): These agents have high privilege but low permission. They can approve or reject work, change the rules, or promote a finished project to the permanent record. However, they can't just look at everything whenever they want; they only get to see the specific files related to the decision they are making. They are like judges who can sentence a criminal but can't wander into the prison to talk to the inmates.
The Supervisors (The Watchers): These agents have high permission (they can look at almost everything to spot errors) but low privilege (they can't change anything). They are like safety inspectors who can walk through the whole factory, check the logs, and yell "STOP!" if they see something dangerous, but they can't fire anyone or change the blueprints. They are there to catch mistakes, not to fix them directly.

Why This Matters: The "Lease" Idea

The most important idea in this paper is the concept of the Lease. In many current AI systems, once an agent is given a tool, it keeps that tool forever, or until someone remembers to take it away. This paper suggests that every agent should only have a "lease" on its power. The lease has an expiration date and a specific scope. If the task is finished, or if the agent takes too long, or if it tries to do something it's not allowed to, the lease expires, and the power is instantly revoked. This makes the system much safer because a "rogue" agent can't cause damage for long; it just gets locked out.

What the Paper Does (and Doesn't) Do

The author has built a prototype of this system and exercised it in small-sample tests. These exercises demonstrate that the design can be implemented and have been useful for refining the mechanics. However, the paper explicitly states that these tests are not a large-scale, powered empirical evaluation and do not justify a general claim that this system is more reliable, better at catching mistakes, or superior to other methods. The prototype proves the framework is possible to build, not that it is the best solution for every situation.

The paper is a blueprint and a set of rules, not a finished product. It suggests that if we want AI organizations to be safe and effective, we need to stop treating them like a group of friends chatting and start treating them like a well-run factory with strict rules, temporary workers, and a permanent logbook.

In short, the paper argues that to make AI teams work, we need to stop asking them to "behave" and start building a system where they can't misbehave, even if they want to. The structure itself does the heavy lifting of keeping everything safe, organized, and accountable.

Technical Summary: Fluid Structure, Rigid Record

Problem Statement

Current Large Language Model (LLM) multi-agent systems often operationalize "organization" as a conversational topology, a static role prompt, or a fixed workflow. This approach fails to address core organizational constraints such as differentiated capabilities, interdependence, limited attention, and the need for accountable history. Specifically, existing systems suffer from:

Entanglement of Work and Sessions: Durable work remains tied to transient conversation contexts rather than persistent records.
Implicit Authority: Power is often derived from tool availability or prompt phrasing rather than explicit, enforceable boundaries.
Fragile Recovery: Failure recovery often involves asking a "contaminated" context to retry, lacking mechanisms for state reconstruction or fault isolation.
Scalability Limits: Adding agents does not monotonically improve performance; centralized coordination can degrade sequential reasoning, and unchecked errors can amplify.

The paper argues that organizations are not collections of titled model instances but goal-directed systems that must separate stable rules from fluid execution to manage specialization, coordination, and failure effectively.

Methodology and Framework Design

The paper proposes a Four-Layer Organizational Design Framework that treats organization as a machine-enforceable system rather than a conversational metaphor. The design is grounded in "functional translation," importing mechanisms from organization theory (e.g., bounded rationality, differentiation) only where they address specific failure-generating constraints in agent systems.

Core Architecture

The organization $O_t$ at time $t$ is defined by four layers:

Persistent Layer (The Rigid Foundation):
- Specialization/Role-Group Agent Pool: A dormant repository of reusable agent specifications (templates) bound to specific capabilities (e.g., financial modeling) and Role Groups. These are not permanent employees but reusable "team leads."
- Four-Store Record System: A separation of data stores to ensure accountability and traceability:
  - Runtime ( $R$ ): Volatile task state, sandboxes, and working payloads.
  - Log ( $E$ ): Append-only, immutable record of events, authority use, and lineage.
  - Artifacts ( $F$ ): Versioned, approved deliverables and datasets.
  - Knowledge ( $K$ ): Reviewed patterns, workflows, and lessons learned.
- Asymmetric Write Rules: Operators write only to Runtime; Reviewers authorize promotion to Artifacts/Knowledge; Supervisors inspect all but cannot rewrite.
Coordination Layer (Permission & Privilege):
- Permission ( $P$ ): The externally enforced boundary of resources (documents, tools, channels) an agent can observe and touch. It compiles a narrow, task-specific "world."
- Privilege ( $Q$ ): The set of organizational state changes an agent may authorize (approve, promote, halt, spawn).
- Task Leases: P&P are issued as time-limited, task-bound leases ( $\gamma$ ) that are deny-by-default. Authority is revoked upon task completion, timeout, or explicit HALT.
Runtime Layer (Fluid Execution):
- Workflow Protocol: A non-agent module that translates validated task inputs into task graphs, selects specializations, determines topology (single chain, parallel, aggregation), and instantiates temporary workers.
- Dynamic Task Groups ( $G_t$ ): Temporary assemblies of agents formed for specific events. The topology adapts to dependency shapes and task uncertainty.
- Mechanism: "Records carry; messages point." Agents receive authorized record sets rather than interpreting previous session contexts.
Human-Interaction Layer:
- Control Plane: The human interface for intent expression, state inspection, and emergency shutdown. It holds a minimal independent cache to ensure revocation is possible even if the data plane fails.
- Translation Agent: Converts human language into typed task inputs without decision-making power.

Governance: Three Orthogonal Role Groups

The framework enforces a strict separation of powers through three Role Groups, where an agent's domain specialization is distinct from its governance role:

Operation: Low Permission, Low Privilege. Executes work within a narrow sandbox. Cannot approve its own output or modify durable stores.
Reviewer: Low standing Permission, High Scoped Privilege. Activated on-demand to approve, reject, or promote work. Cannot self-activate or expand its own scope.
Supervisor: High Observational Permission, Low Modifying Privilege. Samples all stores to detect defects, run canaries, and challenge hypotheses. Can issue FLAGs or HALT tasks but cannot rewrite history or approve replacements.

Key Contributions

The paper makes four primary contributions:

Functional Translation Method: A criterion for converting human organizational mechanisms into machine-enforceable designs based on the specific constraints they solve, rather than their surface form.
Four-Layer Reference Architecture: A cohesive design joining a rigid record system, a specialization pool, P&P coordination, and dynamic Task Groups.
Formal Separation of Role Groups: A deliberate asymmetry in Permission and Privilege profiles (Operation, Review, Supervision) to prevent self-validation and ensure independent oversight.
Integrated Failure-Protection Loop: A system combining scoped restart, replay, escalation, circuit breaking, and independent shutdown, treating robustness as a design property rather than a prompt engineering challenge.

Results and Validation Status

The paper explicitly states that large-scale empirical validation is not yet complete.

Current Status: The architecture has been implemented as a prototype and exercised in small-sample tests.
Findings: These exercises support the claim that the design is implementable and useful for refining mechanics (e.g., lease management, topology selection).
Limitations: No broad performance claims are made. The paper does not claim the system outperforms existing baselines (like CAMEL, AutoGen, or MetaGPT) in general tasks.
Future Work: A companion paper is planned to report controlled, larger-sample evaluations comparing the framework against single agents, prompt-defined roles, and fixed workflows.

Significance and Claims

The paper positions itself as a design-science artifact offering a coherent, falsifiable framework for governing agent organizations. Its significance lies in:

Shifting the Paradigm: Moving from "prompt-centric" organization (narrating behavior) to "world-compilation" organization (defining boundaries and authority).
Enforceable Coordination: Establishing that coordination must live in enforceable rules (P&P, schemas, logs) rather than probabilistic model alignment.
Resilience by Design: Providing a mechanism where the "surface" (team composition, workflow) is fluid to adapt to tasks, while the "underneath" (records, separation of powers, recovery rules) remains rigid to ensure accountability.
Human-in-the-Loop Governance: Preserving a human endpoint for intent, correction, and "organization kill," ensuring that autonomous systems remain bounded by human oversight.

The author concludes that the framework offers a "recoverable foundation" for dynamic organization, allowing agents to act freely within compiled worlds while ensuring that work, authority, and history are preserved outside of transient sessions.