> ## Documentation Index > Fetch the complete documentation index at: https://lib.findy.co.jp/llms.txt > Use this file to discover all available pages before exploring further. # Agentic Workflow > A delegation model where AI agents plan, implement, and verify on their own while humans set goals and judge the result, with context management at the core. ## Overview An agentic workflow is a development model that delegates implementation to AI agents: the human states the goal and judges the result, while the agent plans, implements, and verifies on its own. It differs from [vibe coding](/ai/vibe-coding), where a human works with an agent interactively — the working style shifts from collaboration to delegation, and the human moves from writing code to directing the work. In vibe coding, a human and an AI face each other one to one: the human does the work and the AI supports it. Agentic Workflow reverses that relationship. The AI does the actual work, and the human becomes an orchestrator who sets the direction and makes the judgments. Instead of conversing with a single AI, the human delegates many tasks to multiple agents at the same time — a 1:N way of working. | | Vibe coding | Agentic Workflow | | ------------------------ | ------------------- | ---------------------------------------------- | | Human-to-AI relationship | 1:1 | 1:N | | Who does the work | Human (AI supports) | AI (agents implement) | | Human's role | Worker | Orchestrator — sets direction, makes judgments | This page covers what makes delegation work: the autonomy of the agent, the foundation the repository must provide, the techniques — managing context, dividing roles along context boundaries, and implementing in parallel — and the division of responsibility between AI and humans. ## The four elements of agent autonomy Delegation relies on the agent driving work forward without step-by-step instructions. Four capabilities make that possible. The human specifies *what* to achieve; the agent assembles *how* — the concrete plan and the code. The agent splits a large task into subtasks and executes them in order. The agent operates files, commands, and skills, and reaches external systems through MCP as the work requires. The agent runs tests, reads the failures, fixes the code, and re-runs — repeating autonomously until the change passes. ## Prerequisites ### Guardrails An agent follows the signals the repository gives it, so those signals must exist in a machine-readable form before implementation is delegated. Four kinds of guardrails matter: Project documentation and agent instruction files (README, rules) that state the architecture, coding conventions, naming rules, and test policy. Unified type definitions and design patterns the agent can read and imitate. Test code sufficient for the agent's self-verification loop — run, fail, fix, re-run — to be meaningful. Appropriate pull request granularity and review culture. A weak foundation is amplified, not compensated. If conventions are inconsistent or tests are thin, agents amplify those weaknesses. Put the foundation in place before delegating. ### git worktree A git worktree creates multiple working directories for a single repository. Switching branches in place (`git switch`) allows only one branch at a time, so moving to another task means stashing or committing half-done work first. A worktree separates branches by directory instead: ```text theme={null} # Main working directory (feature/auth branch) ~/project/MyApp/ # Another working directory created as a worktree (fix/login-bug branch) ~/project/MyApp/.claude/worktrees/fix-login-bug/ ``` Each directory holds its own branch. This is what lets parallel agents work without interfering with each other: each agent gets its own directory, so one agent's changes never touch another's, and a build or test run in one worktree never blocks the others. Operated by hand, a worktree takes many commands from creation to cleanup: ```bash theme={null} # Create: add a worktree with a new branch git worktree add .claude/worktrees/fix-login-bug -b fix/login-bug cd .claude/worktrees/fix-login-bug # Set up: copy the files git does not track, install dependencies cp ../../../.env . cp ../../../localhost.pem . npm install # Clean up: return to the main directory, remove the worktree and branch cd ~/project/MyApp git worktree remove .claude/worktrees/fix-login-bug git branch -d fix/login-bug ``` Repeating this routine for every task is a burden, the cleanup is easy to forget — finished worktrees keep piling up — and the number of steps itself becomes a barrier when introducing worktrees to a team. Encapsulating the routine in a [skill](/ai/skill) reduces it to a single command such as `/git-worktree feature/add-auth`. Behind it, the worktree is created, the session's working directory switches over, and the configuration files are copied automatically. The design point is separating what never changes from what does: the worktree-creation logic is identical in every project and lives in a shared skill, while the project-specific setup — which environment files to copy, how to install dependencies — is overridable by a script placed in each repository. Because the worktree operation stands alone as a skill, an implementation agent does not need to know how worktrees are made. It calls the skill as one part of its flow — fetch the issue, create the worktree, implement, open a pull request, clean up — and when the procedure changes, only the skill needs updating. ## Techniques to make Agentic Workflow work ### Manage context An AI's accuracy degrades as its context — the information it holds while working — grows. The longer an agent runs on its own, the more this matters, so whether delegation works comes down to how the context is designed. Every technique in this section follows from that single point. Within a single agent, three practices keep the context lean: * **Offload heavy exploration to subagents.** Information-heavy work such as codebase exploration and research is handled by separate agents, which return only a summarized result to the main agent. * **Move procedures and guidelines into skills.** Rather than loading them into the context permanently, the agent references them as a [skill](/ai/skill) when needed. * **Keep only what decisions need in the main context.** By not carrying intermediate output and raw data, the agent finishes long tasks without losing accuracy. What the three have in common: bulky information lives outside the main context, and only what is needed moves in and out. ```mermaid theme={null} flowchart LR SUB[Subagent
bulky raw data] -->|summary only| MAIN[Main agent
only what decisions need] SKILL[Skill
procedures and guidelines] -.->|only when needed| MAIN ``` Extending this idea of offloading — from the inside of one agent to a whole team of agents — gives the next two techniques: role division and parallel implementation. ### Divide roles along context boundaries The basic shape for using multiple agents is an orchestrator that forms the strategy, delegates tasks to specialized agents, and integrates what comes back. What matters is the criterion used to cut the roles. **Divide roles along context boundaries, not by type of work.** Splitting by stage — a gatherer, an analyst, an implementer — forces a context handoff at every stage boundary, and the coordination cost piles up. Draw the boundary between pieces of work that do not need each other's context instead, and each handoff shrinks to a summary. **✕ Divided by type of work** — every handoff transfers the whole context. ```mermaid theme={null} flowchart LR A[Gatherer] ==>|hand over everything| B[Analyst] ==>|hand over everything| C[Implementer] ``` **○ Divided along context boundaries** — each handoff is only a summary or a self-contained instruction. ```mermaid theme={null} flowchart LR S[Research agent] -->|summary only| ORCH[Orchestrator
analysis and judgment] ORCH -->|self-contained instructions| W1[Implementation agent A
feature and tests] ORCH -->|self-contained instructions| W2[Implementation agent B
feature and tests] ``` Applying that criterion gives the following division: * **Offload information gathering.** The raw data exploration produces is useless to later stages — the cleanest boundary there is. Have the agent return only a summary. * **Keep analysis and judgment with the orchestrator.** Weighing the agents' results against each other and deciding the next move can only happen where all the results converge. * **Group work that needs the same context.** Splitting work that rests on the same understanding — a feature and its tests — across agents means building the same context twice. The same principle shows up in the delegation instructions. Hand each agent a self-contained package: the objective, the output format, the tools to use, and the task boundary. Delegate with fuzzy boundaries and agents duplicate each other's work or leave gaps nobody picks up. Keep the number of parallel agents to a handful. Every additional agent adds integration cost, and past a point that cost outweighs the gain from parallelism. ### Implement in parallel **Issue × Worktree** is context-boundary division applied to implementation work. A well-decomposed sub-issue is a unit of work complete within its own context: a parent issue holds dependency-linked sub-issues, and git worktrees isolate each agent by directory so one issue's changes never touch another's. Task granularity determines whether the agent succeeds. For the criteria — how small each task should be and how to validate a split with independence and revert checks — see [Task Breakdown](/development/task-breakdown); for how to structure a parent issue with sub-issues and set the dependencies between them, see [Turning tasks into issues](/development/task-breakdown#turning-tasks-into-issues). Responsibilities are sharply separated between two agent roles — an orchestrator that analyzes and judges, and Workers that implement: * **Team Lead (orchestrator).** Builds the dependency graph, decides execution layers, creates and assigns tasks, runs the merge gate between layers, and synchronizes Workers. It does **not** write code. * **Worker (implementer).** For its assigned issue, it creates a worktree, sets up the environment, implements, self-reviews, opens a pull request, reports back, and cleans up its worktree. Workers and worktrees map one to one. The Lead splits the sub-issues into **layers** based on their dependencies. Issues that do not depend on each other share a layer, giving a two-level structure: parallel within a layer, sequential between layers. ```mermaid theme={null} flowchart TB LEAD[Team Lead
splits issues into layers by dependency] LEAD -->|1. assigns Workers| L0 L0 ==>|2. every PR merged| LEAD LEAD -->|3. assigns Workers| L1 subgraph L0["Layer 0 (no dependencies)"] direction LR A[Worker A
implements Issue A] B[Worker B
implements Issue B] C[Worker C
implements Issue C] end subgraph L1["Layer 1 (depends on layer 0)"] direction LR D[Worker D
implements Issue D] E[Worker E
implements Issue E] end ``` Within a layer, one Worker per issue implements in its own worktree at the same time, each opening its own pull request. Synchronizing between layers is the Lead's job: it waits for the whole layer to merge, notifying a human about anything still pending, then refreshes the default branch before starting the next layer — so later work always builds on the latest code. A dependency cycle is an error: detect it, report it, and stop. ## Responsibility boundaries The premise of every technique on this page is that **responsibility for AI-generated code rests with the human**. Delegating to AI does not transfer that responsibility; what changes is where the human's attention goes. The dividing line is simple: **delegate what can be verified mechanically, and keep what requires judgment.** Checks whose correctness is decided by matching against rules are what AI does well, while judgments whose right answer depends on context can only be made by a human. Areas that can be verified mechanically against rules. * Compliance with coding conventions, naming, and type definitions * Presence and coverage of test code * Bug and security scanning (only high-confidence findings reported) Areas where the right answer depends on context and requires judgment. * Whether the change meets the business requirement * Soundness of architecture and design decisions * Security risk acceptance and the final merge judgment The effect of this split is a change in what human review time is spent on. With conventions and naming already checked by AI, humans spend their time on the judgment only they can make: whether the change actually meets the requirement. Agentic workflows delegate more than [vibe coding](/ai/vibe-coding) does, but they inherit its groundwork: if interactive collaboration does not work yet, put the foundation in place before delegating whole implementations.