How Do Mixed Human + Agent Teams Work? Versioning Responsibility with Git and Config-as-Code

Imagine a marketing manager’s team. There’s the manager, two marketing specialists, a graphic designer, a social media manager, and a content writing agent. All share the same goal: launch a new product campaign.

The marketing manager sets the strategic direction. Specialists help define the campaign framework. The graphic designer creates visuals. The social media manager (human) handles timing and public relations strategy. The content agent automatically writes campaign copy and adapts it for different social platforms.

Sounds straightforward. But in reality, the collision between human decision-making and agent execution can fail catastrophically.

Defining Responsibility: Boundaries Between Humans and Agents

What happens when a campaign text generated by a writing agent contradicts a customer contract?

• Manager: “I never approved that text; the agent wrote and published it on its own.”
• Agent: “I followed the instructions you gave me. Find where the rules were specified.”
• Developer: “There’s no bug in the agent code. If the input was wrong, so is the output.”

This scenario creates a situation where responsibility becomes murky, or disappears entirely.

The solution is to clearly define the responsibility of each role and agent in the team—not just verbally, but in files, in Git versions, and in audit trails.

Config-as-Code: Putting Rules Into Files

In traditional management, rules live in conversations or complex org charts. Agents require rules that are codified, measurable, and versioned.

For instance, a marketing team’s team-policy.md file might look like this:

# Marketing Team Policy (v2.3)

## Content Agent Responsibility
- Must adhere to style and topic guidelines provided in briefs
- Must not include product contract terms or legal text
- Must flag human manager if errors are detected

## Approval Process
- Text written by Content Agent goes to social media manager for review
- Social media manager must approve or provide feedback within 2 hours
- If no approval, posting is delayed by 2 hours
- Legal risk scenarios require manager approval

## Data Boundaries
- Content Agent cannot access customer contact lists
- May only pull price data from marketing database
- All generated text stored in Git history

This file is understandable to both humans and software engineers. Agent code operates based on these rules.

Git Versioning: Who Did What, and When?

A campaign text doesn’t comply with an agreement. Whose fault is it?

• Check the text history: git log src/campaigns/new-product-campaign.md
• Commit message: “2026-09-15 09:30 — Written by Content Agent, approved by social media manager”
• See changes: git show <commit-hash>
  • Original text (agent-written)
  • Approver’s note (“Legal check OK — Marketing Manager”)
  • Final publish time

This way, every change has a chain of responsibility and decision behind it.

If the text is edited later, that’s also visible in Git:

commit 2 - 2026-09-15 14:00 - Legal correction by Manager
commit 1 - 2026-09-15 09:30 - Written by Content Agent

Responsibility becomes much easier to track.

Approval Delegation: Whose Authority Is It?

In mixed teams, approval chains are also mixed. For example:

Throughout this workflow, who decided and when is logged. If a step is skipped, Git log shows it.

Real-Time Status Query: Who Controlled This?

Before publishing, the manager can ask:

git log --oneline -n 10 -- campaigns/new-product-campaign.md

Result:

5 - Marketing Manager - "Publish approved"
4 - Legal Counsel - "No legal issues in text"
3 - SM Manager - "Suitable for social media audience"
2 - Content Agent - "Text written"

The entire chain of responsibility and approval is visible. Any missing step stands out immediately.

Scaling: Multiple Agents, Multiple Teams

If there are five marketing agents, three engineering agents, and four software developers?

The org chart defines each agent’s and human’s responsible_id. Policy files specify rules per team or globally. Git history records who or which agent made each decision.

Audit and accountability are managed through four pillars:

1. Organization Chart: Who reports to whom?
2. Policy Files: What are the rules and approval mechanisms?
3. Git History: Who changed what, and when?
4. Config-as-Code: Agent permissions, data access, error handling defined as code.

This approach replaces the Slack question of “Who’s responsible?” with a fully logged and auditable system.

When an organization combines these four elements, AI agents shift from being a risk to becoming a value-delivering, auditable, and scalable part of the system.