Agent Management Cycle: Role, Policy, Delegation and Git

Agent Management Cycle: Role, Policy, Delegation and Git

Over six days, we examined step by step where agents fit in the organization, their roles, workflows, and responsibilities. Now all the pieces fit together: how do role definition, policy, delegation, and version control work in a single cycle?

The Pieces We Found

Day 1 showed us shadow AI: nobody can count how many AIs are working, nobody knows how many they are, who decided. Everyone has their own tab, their own system, nobody knows about anyone else.

Day 2 clarified the difference between tool and agent: ChatGPT is a tool, agent is a regular entity. Something with a model, a role, an owner, a policy.

Day 3 showed how organization charts change when they include agents. Human and agent nodes, each with their owner (responsible_id), and these owner chains.

Day 4 defined these owner boundaries with policy.md. Which agent can do which job? When? Under which conditions? Draft, Active, Passive, Archive states; builtin, mcp, http, function skills.

Day 5 discussed agent-to-agent delegation. Agent A gives work to B, B sends results back to A. Approval check, capacity control, veto rights can be added. Workflow is not just human→agent, it can be agent→agent→human.

Day 6 tried to explain how mixed human+agent teams work. Marketing manager and social media agent under the same owner, work division clear, approval order transparent.

But why all this? One reason: auditable, responsible, transparent, versioned organization. And why Git, not Slack?

Auditability: Slack vs. Git

A marketing team. In Slack, a channel:

#agents
- social-media-agent: post every day at 14:00  [updated 2 days ago]
- content-writer-agent: Monday 09:00 blog  [updated 1 week ago]
- seo-report-agent: first day of month 08:00  [updated yesterday]

How many agents do you have? Check Slack, the list in channel metadata. Did it change? Scroll Slack history. Who manages it? There’s a “channel owner”, but who added, who changed, why changed?

Slack is one moment in time. “Why was this agent updated 2 days ago? Who did it?” Pull Slack API, export, analyze. Nobody does this routinely.

Now Git:

organization/
  policy.md
  agents/
    social-media-agent.md
    content-writer-agent.md
    seo-report-agent.md

Every file in Git. You write git log -- agents/social-media-agent.md, all changes come out: date, who, which lines changed, commit message. “Manager X changed it 2 days ago, policy power level raised from 2 to 3” is in the commit.

Code review (PR) is your rule. Policy changes via pull request. Another manager approves. Chain clear, auditable, reversible.

Responsibility: Who is at the End of the Line?

Day 3 mentioned responsible_id. Every agent, every role, every policy change has an owner. With Git, this owner is written in commit history.

There was an error in the marketing agent. Wrong date for publishing. Who is responsible? In policy.md, the marketing agent owner is the marketing manager. The manager had an error in their own agent and it passed approval. The manager’s manager is the marketing director. Responsibility chain is clear.

Slack? “Owner” is in channel metadata, but who added them 6 months ago, why, what state it’s in—nobody knows.

Version Control: Going Back

The marketing agent has been running on the wrong policy since the start of last month. Reports are incorrect. When did it start? Write git blame, the exact line, date, who brought it.

Do you want to go back to that date? git revert or create a branch, go back to the old policy, test, approve, merge.

Slack? “What was there at the start of last month?” Slack history is about 90 days. Old messages are gone. If you saved it (export), find 6 months ago and compare. How to go back? Maybe copy from export, rewrite. Human error is high.

Scale and Team Coordination

Small company: one marketing manager, one social media agent, one accounting manager, one reporting agent. Slack, maybe two channels. Livable.

Large company: 20 departments, each with 5-10 agents, each agent has a policy, each policy has 3-4 versions (draft/active/archive). 200 agents. 500+ policy files.

Slack? Channel count becomes unmanageable. History search is hard. PR, approval, code review don’t exist.

Git? git log --all src/policy/ all policy changes by date. git grep "policy_level: 3" find all high-level agents. git show branch:agents/ see Monday version, compare to Friday version. Open PR dashboard, 12 policy changes waiting for approval.

Approval and Boundaries

In Day 4, every line in policy.md had meaning. policy_level, accessible_skills, veto_rules. These limits written in Slack, but the system (API, CLI, agent runner) must apply them. That is, the agent framework, without relying on Slack, reads the policy.md file and applies it.

So who writes policy.md? The manager. In Slack, they write “I updated these notes.” Does the framework need to see this? Does it test the draft? Is version control happening?

In Git: manager makes a change in policy.md, tests it locally (framework reads from its own file), opens PR, another manager approves, merges, the framework’s CI/CD hook tests policy files and deploys to production, if successful publishes. Human error drops.

Synthesis: Why Self-Hosted Git?

  1. Auditability: Every change, who, when, why. Git log is the unquestioned answer.
  2. Responsibility Chain: responsible_id with commit author. Responsibility is traceable.
  3. Version Control: Reverting, branching, merge strategies. Policy can be tried and rolled back.
  4. Scale: PR workflow, code review, CI/CD automation. 200 agents, 10 managers can be managed.
  5. Integration: Policy.md files are read directly by agent framework. Not dependent on Slack. If Slack goes down, organization is not affected.
  6. Audit and Compliance: Manager, auditor, IT security; can trace every step six months back, who approved, what changed.

What’s Next?

In seven days we explained: how is an agent-powered organization, minimal human, minimal written correspondence, maximum auditability and responsibility designed? With Git and Markdown files.

Slack, Internet, cloud services are nice. But your organization’s structure, decisions about agents, policies, responsibility chains: these must be in a self-hosted, controllable, versioned system. Otherwise, you can’t even answer “who is responsible?”

Your AI is working. But does your organization control the city? Time to get there.