Who Decides When Humans and Agents Work in the Same Team?

Imagine a three-person engineering team at a software company. A senior developer, a recent graduate, and a code review agent. The senior developer defines the architecture, the graduate writes the code, and the agent reviews the code, finds bugs, and suggests fixes.

This team seems to work fine. But one day, the agent finds a bug, suggests a fix, and the developer ignores it. A customer complains later. Who is responsible?

This question seems simple, but the answer depends on the organization’s structure, where rules are defined, and how decisions are recorded.

Work Division: Who Does What?

In mixed teams, work division is the first and most critical step. Humans and agents bring different strengths. Humans define creative strategy, build emotional connections, and navigate ambiguity. Agents run repetitive analysis fast, ensure consistency, and scan large datasets.

In an engineering team, the division might look like this:

Senior developer: Makes architectural decisions, writes critical code sections, approves submissions. Responsibility: technical accuracy and project tracking.

Junior developer: Writes code, runs tests, updates documentation. Responsibility: task completion and reporting.

Code review agent: Reviews code, checks style consistency, scans for security gaps, evaluates test coverage. Responsibility: code quality report and recommendations.

If this division is unclear, everything gets tangled. For example, when the agent finds a bug, the developer can say, “I wrote it, I decide.” But if it isn’t the developer’s job to review the agent’s report, the bug slips through.

Approval Responsibility: Every Decision Needs an Owner

In this team, the approval flow works like this:

Code is written (by the junior developer). The agent reviews it and prepares a report. The developer reviews the report, accepts or rejects it. If rejected, the junior developer fixes it and the agent reviews again.

This seems straightforward, but there is a question: When the senior developer rejects the agent’s report, how do they explain why?

If this response happens in Slack, a meeting, or verbally, it disappears. That is why approval responsibility must record not only who approved, but when and why.

Git comes into play here. Every approval, every decision, every change should appear in commit messages:

commit 4a2b3c1 - 2026-09-23 14:30 - Code review agent report accepted, no security issues found
commit 3f8e2d1 - 2026-09-23 14:15 - Agent report: SQL injection risk detected
commit 2c7b1a9 - 2026-09-23 13:45 - Junior developer completed user input code

This record shows who made which decision and when, if a problem arises later. “Why was this code shipped?” doesn’t go unanswered.

Config-as-Code: Rules in Files, Not Human Memory

Where are the rules defined in this team? A separate file per team? Or one policy for the whole company?

In practice, each team has different needs. A marketing team, an engineering team, and a support team cannot follow the same rules. But rules must be accessible, readable, and versioned for everyone.

With a config-as-code approach, the team’s rules are defined in a YAML or JSON file:

team: backend-engineering
version: 2.1
members:
  - role: senior-developer
    responsible_id: dev-001
    approval_authority: architecture, security
  - role: junior-developer
    responsible_id: dev-002
    approval_authority: none
  - role: code-review-agent
    responsible_id: agent-cr-001
    approval_authority: code_quality_report

policies:
  code_review_required: true
  agent_report_must_be_addressed: true
  merge_requires: senior_developer_approval

This file is readable by both humans and agents. The agent checks these rules when preparing its report. The developer references this file when justifying a rejection.

And because this file lives in Git, changes to the rules are also recorded. “When did the rules change?” is answered with git log.

Versioning the Organization with Git and PR

In this team, every task runs through a pull request. A PR is not just a code change. It is the record of the entire decision chain.

When a PR is opened:

At the end of this process, the organization’s history is recorded. A year later, “Why was this decision made in this project?” can be answered. This is not just the history of code, but the organization’s learning process.

Real-Life Scenario: A Security Gap Slips Through

At one company, this process wasn’t fully applied. The junior developer writes code, the agent reviews it, but reports go unanswered. The senior developer says, “I don’t have time” and moves on without reading the reports. A security vulnerability reaches production, and customer data leaks.

The question that needs to be asked: “Who didn’t read the agent’s report?”

If Git and PR records exist, this question gets an answer. If there is no “agent report reviewed, approved” note in the PR, the process is broken. But to see this breakdown, you first need to build the system.

When humans and agents work in teams, and it is unclear who did what, who approved what, and where rules are defined, errors become inevitable. The solution is a system where everything is recorded, every decision has an owner, and rules live in files.