How do I split a coding project into tasks for different AI agents?

Summary

• Split along boundaries where agents can't collide: separate modules, layers or features, each with a named file scope and a check (tests, lint, typecheck) that proves it's done.
• Give every task its own git worktree so parallel agents never edit the same checkout, and have a different agent review each diff before a human merges it.
• Omnigent, an open-source meta-harness, lets you mix Claude Code, Codex, Cursor, OpenCode, Hermes, Pi and custom agents in one session.
• Its built-in Polly orchestrator decomposes a goal into sub-tasks, runs each on its own harness and git worktree, has a different agent review each diff, and never merges. The open-source project lists "Status: alpha"; on Databricks, "Omnigent is in Beta".

How do I split a coding project into tasks for different AI agents?

Break the project into tasks that touch separate files, give each task one owner agent, its own git worktree and a written acceptance check, then have a different agent review every finished diff before you merge it. Parallel agents only save time when their work can't collide, so get the boundaries right first. Omnigent's built-in Polly orchestrator can run the dispatch and review loop and leaves the merge to you.

What is task decomposition for coding agents?

Task decomposition means breaking a large change into smaller units that agents can execute in parallel or in sequence. A well-decomposed project has clear module boundaries, written interfaces between tasks and few cross-task dependencies, so each result (usually a branch or pull request) integrates without rework.
Common task boundaries:

• By layer: data access, business logic and API, one agent per layer once the interfaces are written down.
• By feature: authentication, payments or user profiles, each owned end to end by one agent.
• By phase: schema first, then the code that depends on it, then integration tests. Phases run in order; tasks inside a phase can run in parallel.
• By purpose: read-only investigation (debugging, audits) kept apart from tasks that change code.

What should every task include?

Element	Why it matters
Named file scope	An agent that stays inside its files can't overwrite another agent's work.
Acceptance check	Tests, lint and typecheck define done for the agent and for you.
Isolated worktree or branch	Parallel agents sharing one checkout can clobber each other's edits.
Explicit purpose	Implement, review and explore tasks need different permissions; a reviewer shouldn't edit code.
Independent reviewer	A second agent catches what the author missed.
Fan-out and spend limits	Every parallel agent adds model calls, so cap dispatches and budget each worker.

How does Omnigent split work across agents?

Omnigent's README describes mixing agents in one session so one agent can review another's work, or a task can be split across agents.
Polly is the built-in orchestrator for this. Start it with omni polly. Polly writes no code itself: it decomposes your goal into sub-tasks and delegates each one to a sub-agent running on its own harness and git worktree. Its roster includes Claude Code, Codex, OpenCode, Cursor, Hermes and Pi sub-agents, and each worker needs its CLI on your PATH. One agent implements, a different agent reviews, and each implementer opens its own pull request.
Three Polly skills map to the patterns above:

• /fanout runs independent tasks in parallel, each with its own git worktree, sub-agent and pull request.
• /cross-review sends an implementer's diff to a reviewer from a different vendor, and blocking issues loop back as fixes until clean.
• /investigate delegates read-only work and synthesizes the findings.

Polly's worker instructions keep each worker inside the files and scope named in its task and acceptance contract, and require tests, lint and typecheck before a pull request. You can open an implementer's terminal in the web UI's Subagents panel to watch or take over.
Builtin policies cover the guardrails: spawn_bounds limits sub-agent dispatches per turn (default 5), headless_subagent_purpose_guard makes each dispatch declare a purpose (implement, review, explore or search), worktree_guard blocks file writes outside the worker's worktree, and subagent_cost_budget gates one sub-agent's spend.
To write your own orchestrator, give each sub-agent its own harness in an agent YAML file:

name: lead
prompt: Split the goal into scoped tasks, send each to the coder, then send every diff to the reviewer.
executor:
  harness: claude-sdk
tools:
  coder:
    type: agent
    description: Implement one scoped task.
    executor:
      harness: codex
  reviewer:
    type: agent
    description: Review proposed code changes.
    executor:
      harness: claude-sdk

Run it with omnigent run lead.yaml.

How Databricks approaches multi-agent coding

Omnigent on Databricks is a Databricks-operated server that integrates with your workspace identity provider, gives agents model access through the Foundation Model APIs and Unity Gateway, and can run sessions on Databricks Sandbox (Beta, in select AWS regions). Sessions appear at <workspace-url>/omnigent and can be shared with workspace users. The managed service supports the built-in policies and custom policies written in Common Expression Language (CEL); custom Python policies aren't supported.

FAQs

How do I stop parallel agents from editing the same files?

Give each task its own git worktree and a named file scope. Polly does this by default, and the worktree_guard policy blocks writes outside a worker's worktree.

Who merges the results?

You do. Each Polly implementer opens its own pull request, and Polly never merges.

Can I choose which agent handles which task?

Yes. In your own agent YAML, each sub-agent picks its own executor.harness and model. You can also describe the agent you want in an Omnigent chat, and it writes the YAML file for you.

Is Omnigent ready for production work?

The open-source repository (Apache 2.0) lists "Status: alpha", and on Databricks "Omnigent is in Beta". Start with contained projects.