Role, Policy, Delegation and Version Control: The Whole Agent Organization

Over six posts we approached a single problem from different angles. Companies have AI tools doing real work through employees’ personal accounts, invisible to everyone. We described that shadow AI situation with concrete scenarios in the first post. Then we separated agents from tools, added agent nodes to the org chart, defined policy and agent state, examined agent-to-agent task delegation and the hybrid team setup. In this final post we bring the pieces together.

What emerges when the pieces combine

Each piece alone is half a solution. Define an agent without policy and it has no boundaries. Write a policy but leave the agent off the org chart and it has no owner. Give it an owner but no delegation rules and you shuttle tasks by hand. Define all of it but skip version control and nobody knows who changed what, when.

Working together, they produce this structure:

1. Every agent is a defined entity. Its name, responsible person, model, capabilities, and the policy it must obey are on record.
2. Every agent is a node in the organization tree. It belongs to a department and has a responsible_id. Behind every agent stands an accountable human.
3. The policy file draws boundaries. Which capabilities it may call, which data it can access, when human approval is required. Draft, active and inactive states make production rollout of an agent a deliberate decision.
4. Delegation follows rules. An agent can hand work it cannot finish to another agent, approval flows trigger at critical points, and results are checked before acceptance.
5. All these definitions live in files and in Git. The organization itself is versioned. Changes are proposed through pull requests, reviewed, and stored with their history.

We call this config-as-code, but the deeper point is this: how your company uses AI stops being tribal knowledge in people’s heads and becomes an auditable structure.

Why Slack or ChatGPT alone is not enough

Most teams try to solve this need with the tools they already have. Open a Slack channel, add a bot, or buy everyone a ChatGPT Enterprise license. In the short term that looks like progress.

The problem is that these are conversation surfaces. They do not know who the agent is, who is responsible for it, what it is allowed to do, or whom it may delegate to. Bury that information inside chats and after a while nobody remembers which agent runs under which rules. When the responsible person changes, nothing gets updated, because there is no single place to update. When an agent’s behavior changes, finding out what changed means digging through message history.

File-based Markdown definitions and Git history reverse this. The agent’s definition is a file, its policy is a file, a change is a commit, and the discussion lives on a pull request. A new hire can look at the repository and learn within ten minutes which agents exist and who has authority over what. When an auditor asks, you show them the Git log.

Being self-hosted matters too: your agent definitions, policies, and organizational structure stay on your own infrastructure. Which model gets used and where data flows is a company decision, not something dictated by a vendor’s roadmap.

A small worked example

Return once more to the scenario from this series: an agent preparing quotes at a manufacturing company. Under the structure described here, its definition would roughly be:

• Name: quote-agent. Department: sales. Responsible_id: the sales manager’s user identity.
• Capabilities: pulling prices from the product catalog, reading customer history, drafting quotes. It has no cost-calculation capability; it delegates that work to cost-agent.
• Policy: quotes above a certain amount cannot be sent without human approval. Customer contract data is read-only.
• State: active. Its definition and policy live in Git; the last change was made two weeks ago through a PR approved by the sales manager.

Those four lines are every concept from the six posts meeting in one example. Getting here does not require a new technology; it requires thinking of agents not as tools but as members of the organization.

Where to start

None of this gets built in one go. Our ordering matched the order of this series, and in practice it works the same way:

1. First map the current state. Who uses which tool, with which account, for which work?
2. Define everything that actually does work as an agent and assign a responsible person to each one.
3. Write the boundaries into a policy file. The first draft can be incomplete; what matters is that it exists in writing.
4. Identify the points requiring human approval and build delegation rules around them.
5. Put all of it in Git. From then on, every change goes through a PR.

If you are considering organizing the agents in your company this way, or want to move an existing setup onto this framework, feel free to reach out; we are glad to share what we have learned working on this.