AI Agent Management: Role, Policy, Delegation, and Version Control Synthesis

AI Agent Management: Role, Policy, Delegation, and Version Control Synthesis

On the first day of this series, we spoke with an IT manager. We asked, “How many AI agents work in your company?” The answer: “Everyone knows, but there is no count.” Developers write code on ChatGPT, the marketing team generates content, the data team runs a model in a Python script. None of them have an official record, none have an owner.

Over the following six days, we built the solution to this problem step by step. Today, we bring these steps together and explain why existing tools like Slack or ChatGPT are insufficient, and why you need to maintain your organization in a Git repository.

Series Summary: Six Days, Four Cornerstones

In this series, we defined four cornerstones:

Making shadow AI visible. On the first day, we discussed institutionalized shadow AI. AI tools used on everyone’s personal computers, with no official record. Making them visible is the first step toward accountability.

The distinction between tool and agent. On the second day, we clarified the difference between a tool and an agent. Using ChatGPT is using a tool; the human bears responsibility for decisions. But an organizationally defined “Deployment Agent” is an entity; it must have an owner, a policy, and accountability.

Agent nodes in the organization chart. On the third day, we saw that the organization chart must include agents. If an agent has no owner, the work it does has no owner either. Responsible_id is the foundation of accountability.

policy.md and operational states. On the fourth day, we learned that every agent needs a policy file. Draft, Active, and Passive states, capability types (builtin, mcp, http, function), and approval mechanisms.

A2A delegation and approval flows. On the fifth day, we saw that agents can hand off work to each other, but responsibility does not vanish. Veto points, result verification, and risk-based approval hierarchies.

Mixed human + agent teams. On the sixth day, we saw that in the real world, agents do not work alone. They produce alongside humans. Work division, approval responsibility, config-as-code, and versioning with Git.

Today, we bring these six pieces together.

Why Slack and ChatGPT Fall Short

If you try to manage these four cornerstones (organization chart, policy, delegation, mixed teams) on Slack or ChatGPT, you run into five structural problems.

First problem: History disappears. If a message from 30 days ago was deleted on Slack and you ask, “Under which policy did the Deployment Agent act?” there is no answer. Git is infinite history. Every change, every decision, every approval stays in commit messages.

Second problem: Accountability is not defined. You asked ChatGPT a question and got an answer. Later, an investigation begins: when did the error happen, who caused it? ChatGPT has no responsible_id. It is a personal tool, not a managed entity.

Third problem: Policy is not written down. If you write “Deployment Agent needs two approvals” on Slack, how does the Deployment Agent read it? If it is in policy.md in Git, both humans and code can verify it.

Fourth problem: No approval chain integrity. In a Slack conversation, a message says “I approved.” But who? Is it really that person? A Git commit signature is cryptographically guaranteed.

Fifth problem: No versioning. When a policy changes on Slack, the old policy disappears. In Git, every change is recorded with a commit message. “When did the rules change?” is answered with git log.

Self-Hosted, Git-Based Alternative

The solution is to address all five problems at once. Here is how:

1. Organization File (organization.md)

# Organization Structure

## Engineering Department
- Manager: Ali (ali@company.com)
  - Developer 1: AyĹźe
  - Developer 2: Mehmet
  - DevOps Manager: Can
    - responsible_id: deployment-agent-v2
    - responsible_id: infrastructure-agent-v1

## Agents
- deployment-agent-v2
  - owner: Can (DevOps Manager)
  - policy_file: policies/deployment-policy.md
  - status: Active
  
- infrastructure-agent-v1
  - owner: Can
  - policy_file: policies/infrastructure-policy.md
  - status: Active

This file is the coded version of the organization chart. Each agent’s owner, policy file, and status are written down. Because it lives in Git, every change is recorded in a commit message.

2. Policy Files

# policies/deployment-policy.md

## Deployment Agent Policy (v1.2)
- Cannot deploy if staging tests fail
- Maximum three deployments per day
- Five-minute veto window before any deployment
- On error, tags the DevOps Manager

This policy file is readable by both humans and agents. The agent checks this file before deploying. A human references this file when justifying a rejection.

3. Git-Based Approval and History

# Every deployment is a Git commit:
$ git log policies/deployment-policy.md
commit abc123 - DevOps Manager - "Policy v1.2 updated"
commit abc122 - CEO - "Policy v1.1 approved"

Git records who made which change, when, and why. This is the foundation of audit and accountability.

4. A2A Delegation Record

# delegations.md

## Security Check Delegation
- From: code-agent-v1
- To: security-agent-v2
- Task: "Review encryption logic"
- Requested: 2026-09-24 10:00
- Completed: 2026-09-24 11:30
- Result: "Approved"
- Approver: security-agent-v2

A2A delegation is work distribution among agents. Every delegation is recorded. When a problem arises, every step in the chain is traceable.

What This Looks Like in Daily Life

Setting up this system is an organizational decision, not a technical one. Here is how it works in daily life:

Morning: The manager checks the organization file in Git. Was a new agent added? Did an agent’s owner change? Was a policy updated? Everything is visible in commit messages.

During the day: Agents do their work. Every decision, every approval, every delegation is recorded. When an agent finds a bug, it adds its report as a PR comment. A human reviews the report, approves or rejects it. The rejection reason is noted in the comment.

Evening: The manager sees the day’s summary in the git log. “Today there were 3 deployments, 2 approved, 1 rejected. Rejection reason: staging test failed.” Everything is recorded.

A year later: The question “Why was this decision made in this project?” can be answered. The git log is the record of the organization’s learning process.

Why This Matters

This approach is not just an audit tool; it is an organizational investment. Here is why:

Accountability: Every decision has an owner. When an error occurs, who made which decision and when is visible.

Learning: The organization learns from past decisions. “Why did we make this mistake?” gets answered.

Transparency: Rules, roles, and responsibilities are visible to everyone. No hidden policies, no hidden decisions.

Sustainability: When an agent is removed, its owner, policy, and history remain recorded. Knowledge is not lost.

Next Step

We asked the same question on the first day of this series: “How many AI agents work in your company?”

If the answer is still “everyone knows, but there is no count,” use this series as a starting point. First step: make agents visible. Second step: define ownership and policy for each agent. Third step: move the organization chart to Git. Fourth step: keep approval and delegation records.

By taking these steps, you replace invisible agents with visible, managed, and auditable agents. This is not just a technical infrastructure; it is the foundation of institutional trust and transparency.

Shadow AI and institutionalized shadow AI, Tool vs Agent distinction, Agent nodes in the organization chart, policy.md and agent states, A2A delegation and approval flows, Mixed human + agent teams.