How Does Work Divide in Hybrid Teams?

How Does Work Divide in Hybrid Teams?

When a department has both humans and agents, workflows do not organize themselves automatically. In How Do Agents Delegate Tasks to Each Other? we examined A2A delegation rules. In Policy and Agent State we defined each agent’s boundaries, status, and capabilities. Today we arrive at the point where these two worlds meet in the same environment: hybrid teams.

A hybrid team is not just “humans with agents beside them.” Both sides must share the same goals, have clearly defined responsibilities, and have working approval mechanisms. Otherwise, the result is chaos that differs little from shadow AI, where everyone uses their own ChatGPT for their own tasks.

Humans and Agents: Different Members of the Same Team

Picture a hybrid team: an engineer uses an agent for software design while another agent tests that design. A human engineer approves the result, and an agent automatically updates the documentation. Here is how work divides:

As we emphasized in What Is an Agent: From AI Tool to AI Agent, the difference between a tool (a chatbot in a browser tab) and an agent (an entity with defined responsibility, model, capabilities, and policy) becomes critical here. An agent does not perform a task “however it likes”; it operates within a predefined role and policy framework.

Approval Chain: Who Decides What?

The most common mistake in hybrid teams is either leaving all tasks to agents or having every agent output individually approved by humans. Neither scales.

A healthy model works like this:

  1. Agent produces preliminary assessment: Collects data, produces initial output, flags risky points.
  2. Human approves or corrects: Intervenes only at critical decision points.
  3. Agent implements and tracks: Applies approved decisions, logs the process.

All three steps must be recorded. As we stated in Why the Org Chart Must Include Agents, an agent must have an assigned role and an accountable owner. The approval chain must be visible in the organizational chart.

For example, when a quality control agent flags a test result as “failed,” will the human quality manager approve it, or will it automatically return to the production agent? This rule must be defined in the policy file (policy.md).

Config-as-Code: Managing Organizational Structure via Git

In software, managing infrastructure configuration as code (config-as-code) is a standard practice. The same concept applies to organizational structure. Departments, roles, agents, approval chains, and policy rules can all be defined in a Markdown or YAML file.

What do you gain?

Today, many companies still manage human organizations through spreadsheets and the memory of authorized people. Agents make this equation even more complex. Config-as-code brings both human and agent resources into the same system, improving predictability.

Why Slack or Standalone ChatGPT Is Not Enough

Daily communication tools may be suitable for running a single agent. But they are insufficient for positioning agents within an organization at scale. When everyone has their own bot in Slack, accountability, traceability, and approval mechanisms disappear.

In How Do Agents Delegate Tasks to Each Other? we discussed the requirements for A2A delegation to be more than an advanced form of shadow AI. Now we must add: these requirements cannot be practically implemented without a file-based, versioned infrastructure.

Config-as-code makes it possible to manage the organization itself like a code repository. Markdown files, Git PRs, and automated checks provide a working model not just for engineering teams, but for everyone managing corporate structure.

Next Step

In the seventh and final article of this week’s series, we will bring all these concepts together: why the transition from shadow AI to structured agent organizations cannot rely solely on Markdown and Git, yet why this approach delivers security and controllability.