Mixed Human + Agent Teams: Work Division and Responsibility

By now, we understand what an agent is, where it fits in the org chart, what its policy.md says, and how agents delegate to each other. But in reality, no team consists of agents only or humans only. A human manager has both humans and agents under them. How do they work together?

Work Division in Traditional Human Teams

Imagine a marketing team:

• Manager: Strategic decisions, budget, approvals
• Consultant A: Content planning
• Consultant B: Social media management
• Project Manager: Timeline tracking, deadline oversight

Each person has a defined area of responsibility. The manager supervises and approves their work. They have autonomy within their domain.

Now add an agent to this team. What changes?

Human + Agent Team Structure

Let’s say we add a “Social Media Agent” to the marketing team:

• Manager: Strategy, budget, approval, oversight
• Consultant A: Content planning (human)
• Consultant B: Social media management (human)
• Social Media Agent: Post scheduling per fixed rules, analytics reporting (agent)
• Project Manager: Time and quality tracking (human)

Now things get complicated:

1. Who does what? Does Consultant B stay as the sole handler, or does the agent share the work?

The answer: The work split is the manager’s decision. The manager must write explicit rules:

Social Media Agent Job Description:
- Publishes content approved by Marketing Consultant B 
  every day at 14:00 UTC.
- Generates analytics report 1 hour after publishing,
  sends to Consultant B.
- If engagement drops below threshold (50 views),
  alerts Consultant B.
- If post goes viral (500+ views), escalates to Manager.

2. Who approves what? If Consultant B makes a strategic call (e.g., “This month, video-only”), who approves it?

Answer: The manager. But here’s the nuance: Consultant B’s routine decisions (which post to publish when) don’t need manager approval. The agent’s decisions (e.g., the agent choosing not to post something) must always follow the manager’s policy.

3. If the agent makes a mistake? If Social Media Agent publishes a post that Consultant B never approved, who is responsible?

Answer: Ultimately, the manager. Consultant B is also responsible (didn’t catch it), and so is the agent (broke its rules). But top responsibility rests with the manager.

Config-as-Code: Rules Must Be Written Down

These rules shouldn’t live in the manager’s head. They should be documented. Ideally in a machine-readable format:

team:
  name: "Marketing"
  manager: "Human: Manager Ali"
  members:
    - name: "Consultant Zeynep"
      type: human
      skills:
        - content_planning
        - strategy_approval
    - name: "Consultant Emre"
      type: human
      skills:
        - social_media_management
    - name: "Social Media Agent"
      type: agent
      owner: "Manager Ali"
      policy: "policy-social-media.md"
      skills:
        - post_scheduling
        - analytics_reporting
      delegation:
        can_receive_from: ["Consultant Emre", "Manager Ali"]
        must_approve_to: ["Consultant Emre"]
      capacity:
        max_posts_per_day: 10
        max_parallel_tasks: 2

approval_rules:
  strategic_decision: "Manager Ali"
  daily_scheduling: "Consultant Emre"
  policy_change: "Manager Ali + CTO"
  budget_over_5k: "CEO"

This must be written in YAML or similar. Why?

1. Eliminates ambiguity: Everyone knows the rules.
2. Agents can read it: The agent parses this config to decide what to do in each situation.
3. Version control: When config changes, you see who changed it and when.
4. Transparency: A new manager or auditor can read the config and understand the structure immediately.

Git and PR for Organizational Versioning

Here’s where software engineering’s most powerful tool comes in: Git.

Organizational configs should live in a Git repository. For example:

org-config/
├── teams/
│   ├── marketing.yaml
│   ├── engineering.yaml
│   └── finance.yaml
├── policies/
│   ├── policy-social-media.md
│   ├── policy-data-handling.md
│   └── policy-financial-approval.md
├── agents/
│   ├── agent-social-scheduler.yaml
│   ├── agent-data-processor.yaml
│   └── agent-report-generator.yaml
└── README.md

Manager Ali decides to add a new agent to marketing. Here’s the workflow:

1. Creates a branch: feature/add-social-agent
2. Updates config: Adds agent to teams/marketing.yaml
3. Opens a PR: “Adding Social Media Agent to marketing team”
4. Requests review: CTO or policy owner reviews
5. Discussion: “Can this agent really have this much authority?” they ask
6. Approval: PR is approved
7. Merge: Change goes to main branch, takes effect
8. Deployment: System automatically reads this config, trains the agent, rules are live

The entire history is preserved. If an auditor asks three months later, “Who gave this agent authority and when?” the answer is in Git:

$ git log --oneline | grep "social-agent"
a3f4e5c feature/add-social-agent (merged 2026-09-03, reviewed by CTO, approved)

$ git show a3f4e5c
# All changes and rationale are there

Practical Example: Manager Ali’s Decision

Manager Ali decides to expand marketing:

• Consultant Zeynep is overloaded (content planning takes all month)
• New agent: “Content Planning Agent”

Steps:

1. Define the agent: Write policy-content-planner.md

   Agent: Content Planner
   Owner: Manager Ali
   Skills: Content ideation, calendar planning
   Limits: Cannot modify customer contracts
   Oversight: Consultant Zeynep reviews plan weekly

2. Update config: Add agent to teams/marketing.yaml

3. Open PR: Reviewed and approved by Consultant Zeynep and CTO

4. Merge: Config enters main branch

5. System updates: Every human and agent now knows the new structure

6. Audit trail: Every step is logged in Git

Summary

In mixed teams:

1. Work division rule: Manager’s decision, written in config
2. Approval responsibility: Clear hierarchy, defined
3. Config-as-Code: Rules are machine-readable
4. Git + PR: Change history, review, approval process
5. Auditability: Every decision and change is recorded

If you try to manage these rules via Slack or a spreadsheet, chaos will follow in a week. Config-as-Code + Git = dedicated, versioned, auditable organization.

Tomorrow: What happens when all the pieces (roles, policies, delegation, version control) come together?