DEV Community: Alook

What Actually Survives Between Coding-Agent Sessions?

Alook — Thu, 27 Aug 2026 02:41:31 +0000

A new coding-agent session can see your repository and still miss the decisions that shaped it. This guide maps what rules files, Git, runtime memory, and handoff notes preserve—and where each one stops.

Composite scenario for illustration — not a customer case study.

You spend an hour with a coding agent sorting out an API boundary. You settle on GraphQL over REST, agree on error handling, and decide which endpoints belong to which service. Then the session ends.

Tomorrow you open a new session in the same repo. The agent can read the files. It has no record of yesterday's thread. You re-explain the constraints. It suggests REST.

Context does not survive between sessions by default. It can still live in several places, each carrying a different slice of the work. This guide maps where continuity can persist, what each layer keeps alive, and where it still breaks. For why multi-agent work drifts in the first place, see When AI Agents Don't Share Context or Memory.

Coding agent sessions start with a cold context window

Claude Code and Cursor both treat a new session as a cold conversational start.

Claude Code's memory docs say it directly: each Claude Code session begins with a fresh context window. What loads next is not the full chat. It is instruction files you maintain, plus auto memory Claude writes for later sessions.

Cursor's rules docs draw the same line: large language models do not retain memory between completions. Project rules and AGENTS.md inject instructions into the prompt. They do not replay yesterday's thread.

"Remembering the project" is not the same as "remembering Tuesday's thread." The agent can see the codebase. It cannot see the reasoning that shaped it unless that reasoning lives somewhere durable.

Anthropic's context engineering guide pushes the same idea: give the model a compact set of high-signal information for the next action, not every prior message.

What survives a session boundary depends on which carriers you use.

Put durable agent rules in CLAUDE.md and AGENTS.md

Start with CLAUDE.md, AGENTS.md, and Cursor project rules under .cursor/rules. Cursor also documents AGENTS.md as a plain-markdown alternative to .cursor/rules.

What continues: coding standards, architecture constraints, build and test commands, naming conventions, "always do X" rules. These load at session start and spare the agent from rediscovering project basics.

Where it breaks: stable files do not carry this week's WIP, the decision you made Tuesday, or which PR is blocked on review. If the fact changes weekly, it does not belong in a file meant to stay useful for months.

Practice: keep instruction files lean. Claude's best practices say CLAUDE.md should hold persistent context the agent cannot infer from code alone, and advise keeping the file short so important rules are not lost. The memory docs target under about 200 lines per CLAUDE.md. Prefer pointers to canonical files over pasting a whole style guide into every session.

Carry decisions in commits and pull requests

Commits, PR descriptions, branch names, review threads.

What continues: what landed in the tree. Reasoning written into PR descriptions or commit bodies is readable to the next agent. Branch names like feat/graphql-gateway signal intent before anyone opens a file.

Where it breaks: Git records what you shipped. It does not record what you considered and rejected unless someone wrote that down. GraphQL over REST lives in a PR comment only if it was typed there. Otherwise the next session sees the implementation without the rationale.

Practice: when a decision will matter to a later session, put the why in the commit body or PR description. Treat Git as code truth. For decision truth, you usually need another carrier.

Resume one runtime without expecting cross-tool memory

Claude Code auto memory and claude --continue / claude --resume; multi-agent work inside Codex's own product surfaces.

What continues (same runtime): Claude Code can save notes (build commands, debugging patterns, preferences) under ~/.claude/projects/<project>/memory/. The first 200 lines of MEMORY.md, or the first 25KB, whichever comes first, load at session start (memory docs). Best practices document claude --continue for the most recent session and claude --resume to pick from a list. Codex ships a local CLI and a separate app experience; agent work there stays inside OpenAI's surfaces, not inside Claude Code.

Where it breaks: all of this is single-runtime. Claude's auto memory does not reach Codex. Codex sessions do not load into Claude Code. Resume restores one product's history, not another tool's. Switch runtimes, and there is no automatic path for those notes.

Practice: manage context aggressively inside one runtime. Claude's best practices recommend /clear between unrelated tasks and using subagents for investigation so exploration does not clutter the main thread. Do not mistake per-runtime memory for cross-tool continuity.

Keep nested agents inside one product ecosystem

Claude Code subagents and Agent Teams; multi-agent workflows inside Codex's own app/CLI ecosystem.

What continues: work that stays inside one ecosystem. Subagents run scoped tasks and return results to the parent. Product-native teams and in-product multi-agent flows can organize multi-step work without leaving that vendor's walls.

Where it breaks: the moment work must move Claude Code → Codex (or Cursor, or another machine), native orchestration does not bridge the gap. Ownership and task status stay inside each runtime. For the dual-runtime case, see bringing Claude Code and Codex into the same team. For nested helpers versus independent agents, see Claude Code subagents vs independent coding agents.

Write a handoff file before the next coding session

A HANDOFF.md, STATUS.md, or short notes file at a fixed path in the repo.

What continues: current goal, what was done, what changed, what to verify, what not to touch, and who owns the next step — if the outgoing session writes it before closing and the next session reads it before editing.

Where it breaks: a handoff nobody updates is worse than none. It needs a habit: write at task end, read at task start. It does not notify you. Do not ask one agent to summarize another agent's transcript as the primary bridge. Write the conclusions directly.

Practice: fix the path (docs/HANDOFF.md or similar). Use a short template: done / changed / verified / not done / next step / do not touch. Open-source tools such as context-bridge treat continuity as a local markdown handoff (and warn against relying on one AI to summarize another as the core bridge).

Where each layer stops

Carrier	Continues	Breaks at
Instruction files	Stable rules, architecture	Live WIP, weekly decisions
Git / PR	Code changes, written review	Unwritten decisions
Session resume / auto memory	Same tool, same project store	Other runtimes
Nested agents / in-product multi-agent	Inside one ecosystem	Cross-runtime ownership
Handoff markdown	Portable WIP story	Neglect, no template
Coordination layer	Roles, threads, task status across agents	(next section)

If work stays inside one runtime and you maintain project files, these layers cover most cases. The gap opens when you run multiple agents, switch runtimes, or need decisions to move between sessions without you carrying them by hand.

Connect sessions when files and git are not enough

The layers above still leave you as the sync point: read one session's output, paste into the next, or maintain a handoff no agent refreshes on its own.

When that bridging is daily, the missing piece is not "more memory files." It is a channel between sessions: persistent identity so work can address a specific agent, explicit task ownership, and threads that survive restarts on both sides.

We built Alook as that coordination layer for local coding agents. Agents keep their own runtimes and in-tool memory. Alook adds roles, persistent message threads, and handoffs that outlast a single chat window. See supported agents for the current runtime list, and how to build an AI agent team for roles and handoffs.

Context can persist in files, in Git, in runtime memory, in handoff notes. Each carries something. None carries everything. The more agents and sessions you run, the more useful it becomes to connect them rather than reconciling them yourself.

FAQ

Do CLAUDE.md or AGENTS.md restore my last chat?

No. They load instructions into a new session. They are not a transcript replay.

Is session resume enough when I switch from Claude Code to Cursor?

No. Resume and auto memory stay with the product that stored them.

What belongs in a handoff file?

Goal, done, changed paths, verified checks, not-done or blocked items, next step, and do-not-touch notes — rewritten each handoff.

When do you need more than files and git?

When work crosses runtimes or spans days and you need owned next steps plus a thread you can reopen without reconstructing the chat.

How to Make Claude Code and Codex Work as One Team

Alook — Thu, 27 Aug 2026 02:35:39 +0000

Claude Code and Codex can share a repository without sharing context, ownership, or a next step. This guide shows a practical builder-reviewer workflow with explicit handoffs and a human merge boundary.

What it is: Claude Code and Codex on the same repository as one team means stable roles, structured handoffs, shared status, and a human approval boundary for merge and release.

What it is not: One shared brain, one chat history, or “open two terminals and hope.” Each runtime keeps its own session. Without an explicit crossing, you become the hidden router between them.

Yes, you can use Claude Code and Codex together on the same repository. Pick who implements and who reviews (either direction works). Design the handoff so review findings and next owners do not depend on you pasting between terminals.

Why two coding-agent terminals are not one team

Opening Claude Code in one terminal and Codex in another is not coordination. It is parallel access to the same repository with two separate brains.

Each runtime keeps its own conversation history, tool permissions, and working context. When the Codex session does not see what the Claude Code session decided yesterday, you paste summaries. When the implementer does not see review comments until you forward them, you paste again.

That pattern is the subject of AI team vs AI tools: isolated assistants can be powerful, but the human often becomes the copy-paste layer between them.

A team, in the useful sense, means stable ownership, an explicit next step, and a record that survives when either session closes. Two runtimes running at once do not provide that by default.

How Claude Code and Codex organize work

This section describes public product models, not a ranking of which tool is "better" at implementation or review.

Claude Code

Claude Code reads and edits a codebase, runs commands, and operates from the terminal, IDE integrations, desktop, and browser surfaces Anthropic documents.

Inside a single Claude Code session, you can delegate to specialized subagents. Subagents run in separate context windows, work on scoped tasks, and return results to the main session. That is orchestration within one runtime. For how that nested model differs from independent agents, see Claude Code subagents vs independent agents.

Claude Code can also run dynamic workflows for large parallel jobs inside the same ecosystem. We covered how that differs from persistent cross-session coordination in our guide to Claude Code dynamic workflows vs async coordination. This article focuses on a different problem: coordinating Claude Code with an independent Codex runtime.

Codex

OpenAI ships Codex as a local CLI and as a broader Codex experience that includes an app for managing multiple agents, parallel threads, and longer-running tasks. In that model, different agents can work in separate threads while you inspect diffs, leave comments, and return to your editor.

That is orchestration inside Codex's own environment. It does not, by itself, define how a Codex agent hands work to a Claude Code agent with a durable identity on the other side.

Where the cross-runtime gap opens

Layer	What the runtime handles
Runtime-internal orchestration	Claude Code subagents and workflows; Codex agents and threads
Cross-runtime coordination	Identity, roles, handoffs, status, and history across Claude Code and Codex

Both tools can organize agentic work internally. The gap opens when work must move from one runtime into the other and stay owned by someone specific.

Four ways to use Claude Code and Codex together

1. Manual routing

You copy objectives, diffs, and review notes between terminals or threads.

When it works. Small tasks, early experiments, or cases where you want full control over every message.

Where it breaks. Every handoff depends on you remembering what changed, what was rejected, and what still needs a human decision. Context compounds faster than copy-paste can keep up.

2. Shared repository, Git, and pull requests

Both runtimes work against the same repo. Branches, commits, and PRs carry the code changes.

When it works. Teams already disciplined about branch ownership, small scopes, and review before merge.

Where it breaks. Git coordinates code well. It does not record who should act next, why a decision was made, or which agent owns an unresolved question. Problems appear when both sessions act on stale assumptions or lack visibility into the other session's decisions. See when agents don't share context for how that drift shows up.

3. Runtime-native agent orchestration

You use Claude Code subagents or Codex's multi-agent threads inside each product's own model.

When it works. The entire job stays inside one vendor stack. You do not need a Claude Code agent and a Codex agent on the same long-running workflow.

Where it breaks. The moment you want Claude Code to implement and Codex to review as peer runtimes with persistent roles, native orchestration on each side does not connect the two worlds.

4. Cross-runtime coordination layer

Agents on different runtimes get stable identities, roles, tasks, and communication paths outside either CLI.

When it works. You run multiple local coding agents regularly and want cross-runtime work to survive session restarts without rebuilding context.

Where it breaks. If the job is a one-off question, a coordination layer adds setup you may not need yet.

What a cross-runtime AI agent team needs

Before you pick tools, define what "same team" means in practice.

Stable roles. Someone implements. Someone reviews. Research or ops can sit on a separate seat when the workflow needs it. Labels can change, but ownership should not shuffle every message.

Explicit ownership. At any moment, one agent (or one human) should own the next action.

Structured handoff. The next participant needs the objective, the current branch or commit, decisions already made, checks already run, open questions, and the requested next step.

Shared status. You should not need to read two terminals to learn whether review is waiting on fixes or merge is blocked on a human call.

Human approval boundary. Merge, release, customer-facing changes, and permission changes stay with a person.

Example workflow: Claude Code implements, Codex reviews

The split below is illustrative. You can reverse the roles depending on your subscriptions, repository layout, and preference. Nothing here claims Claude Code is inherently the implementer or Codex the reviewer.

Human assigns a scoped feature
        ↓
Claude Code agent implements on a feature branch
        ↓
Handoff includes commit, changed files, assumptions, and open questions
        ↓
Codex agent reviews the diff and runs checks
        ↓
Review findings return to the implementer
        ↓
Human approves the final merge

A minimal handoff package:

Objective — what "done" means for this slice
Branch or commit — where to look
Files changed — scope of the edit
Decisions made — options chosen and rejected
Checks already run — tests, linters, or manual steps completed
Open questions — anything blocking a clean review
Requested next action — review, fix, or escalate to human

That list overlaps with the handoff minimum in shared context between agents. The difference here is the handoff crosses runtimes, including cases where each role lives outside a single chat. For what survives when a CLI session closes, see keeping context across coding agent sessions.

Running Claude Code and Codex through Alook

Alook is an open-source platform for rooms where people and local AI coding agents work together. Agents still run on your machine. You can register at alook.ai and connect a local runtime, or self-host from the GitHub repository. Public product surfaces list Claude Code, Codex, Cursor, OpenCode, and Pi as supported local runtimes today.

When Alook fits

Alook fits when you already run more than one local coding agent and want cross-runtime work to keep names, roles, and shared history instead of living only in your head and two terminals. In a room with people and agents, the handoff can stay visible after either CLI session closes.

It is a poor fit for a single quick question inside one runtime, or for work that never leaves Claude Code's own subagent model.

Publicly documented setup

Two paths:

Hosted: Register at alook.ai, pair your machine with the generated daemon command, and connect the local environments where Claude Code and Codex run.
Self-hosted: Run npx @alook/app onboard to start four Wrangler services plus the local daemon. Note: self-host disables OAuth login (email/password required) and email sending/receiving is unavailable.
Create agents with distinct roles so each runtime has a clear owner for implementation, review, or research.
Put people and agents in the same room (channels, threads, or DMs) so the next owner can see the handoff without you pasting between terminals.

Exact UI steps can change between releases. Treat the list above as the documented shape of the product, not a click-by-click manual.

Example team configuration

A minimal cross-runtime team could be configured like this:

Builder agent — connected to Claude Code — owns implementation tasks on feature branches
Reviewer agent — connected to Codex — owns diff review and check runs against the same repo
You — own scope, merge approval, and anything that changes production or customer expectations

Work flows: you assign a scoped task to Builder → Builder commits and sends a handoff with branch, files, and open questions → Reviewer receives the task → Reviewer returns findings → Builder addresses them → you merge when satisfied.

That pattern mirrors the example workflow earlier. Alook supplies the shared room, identities, and message history; each runtime still executes commands and edits files locally.

What Alook coordinates

Agent identity across rooms
Role ownership across runtimes
Durable threads that outlive a single CLI session
Ownership and status visible in messages and marks
Cross-runtime handoff routing

What Claude Code and Codex still control

Model behavior and reasoning quality
File reading, editing, and command execution
Context-window limits inside each session
Account, subscription, and CLI-specific constraints
Whether the generated code is correct for your repo

Alook does not replace either runtime. It sits between them so you stop being the only integration point.

Current limits

Alook is a coordination layer, not a merged IDE. You still maintain two runtimes, two sets of credentials, and your own review standards. Features and onboarding flows evolve; confirm runtime support and setup steps in the current docs before you plan a production workflow around them.

For broader team design, see AI agent orchestration, how to build an AI agent team, and how to delegate tasks to AI agents.

Claude Code and Codex FAQ

How do you use Claude and Codex together? Run both against the same repo, assign stable roles, move code through Git, and pass handoffs the next runtime can act on. When sessions close, add identities, threads, or marks so review findings and implementation updates do not depend on you pasting between terminals.

Codex vs Claude Code: which should you use? Neither wins every job. Pick by task, subscription, and habit. Many teams keep both and split implementation from review instead of forcing every slice into one runtime.

Can Claude Code delegate to Codex? Yes, when delegation means a structured handoff: objective, branch or commit, files changed, decisions, checks run, open questions, and the requested next action. Claude Code does not automatically push context into Codex's session; you or a coordination layer carries the package.

What is a Claude Code handoff to Codex? A handoff is the package the next runtime needs: objective, branch or commit, files changed, decisions made, checks already run, open questions, and the requested next action. Delegating inside one Claude Code session to Codex still needs that package if the work leaves the first runtime.

Can Claude Code and Codex work on the same repository? Yes. Branches, commits, and pull requests are the usual shared surface. The harder part is coordinating who acts next and how review findings return without you rebuilding context in each terminal.

Does Alook replace Claude Code or Codex? No. Alook coordinates roles, handoffs, and visibility across runtimes. Claude Code and Codex still execute commands and edit files on your machine.

When keeping them separate is simpler

You may not need a cross-runtime team yet.

The task fits comfortably in one runtime and one session
You are still learning Claude Code or Codex on its own
Manual copy-paste has not become a daily tax
There is no recurring split between implementation and review across vendors
Runtime-native subagents or Codex threads already cover the whole job

Start simple. Add coordination when the cost of routing work yourself shows up every week.

Claude Code and Codex can each manage agentic work inside their own ecosystems. The cross-runtime question is narrower and harder: who owns the next step when work leaves one runtime and lands in another?

Define roles, pack small handoffs, and use Git for code. When routing between sessions becomes the job, a coordination layer is the category answer. Connect your agents, assign the split that fits your repo, and keep merge authority where it belongs: with you.

What Breaks When Multiple AI Agents Edit One Repository?

Alook — Wed, 26 Aug 2026 09:27:14 +0000

Multiple coding agents can produce clean, useful diffs and still leave a repository harder to review safely. This guide separates what Git can detect from the path ownership, worktree, and review rules teams still need.

Two agents open the same repository. Agent A refactors src/auth/middleware.ts. Agent B fixes a type error in that file. Both open pull requests. One merges first. The second now conflicts, or it merges cleanly with assumptions that no longer hold.

Git can report overlapping lines. It cannot decide who should have owned the file. That decision has to happen before either agent starts editing.

This guide covers four failure patterns you can see in branches, working trees, and pull requests. How to Bring Claude Code and Codex Into the Same Team explains how separate runtimes can work as one team. This guide starts one level lower: what happens on disk when they both edit the repo.

Two agents edit the same file at the same time

The obvious result is a merge conflict. The harder case is a clean merge with broken behavior. Agent A tightens a validation helper to reject empty values. Agent B adds a new caller that passes an empty default. Neither diff touches the other’s lines, so Git merges both, the build stays green, and the bug shows up at runtime.

This happens when both task briefs say “fix auth” without naming file boundaries. Each agent treats the module as open for editing.

Put the allowed paths in the task brief. If Agent A owns src/auth/ for this cycle, Agent B leaves those files alone until ownership changes. An in-scope and out-of-scope list is enough. A CODEOWNERS-style path map can also help identify the usual reviewer, although it does not lock files or assign the current task for you.

You do not need a perfect org chart. You need one sentence that says which directories this task may change.

Both agents fix the same problem

Two PRs fix the same lint error. Two agents add the same missing type or write separate versions of one utility. One change lands, and the other becomes a diff nobody needs.

The cause is usually a broad brief such as “fix type errors in the project.” Coding agents often fix everything they notice, including work assigned elsewhere.

Scope work to named issues or paths. “Fix the three type errors in issue #412” is bounded. “Fix type errors in the codebase” invites overlap. If an agent notices useful cleanup outside its assignment, record it as a separate task instead of adding it to the current PR.

Agents share uncommitted state

Agent A starts editing a file but has not committed it. Agent B uses the same checkout and reads A’s half-finished version. B may build on temporary code, reformat it, or overwrite part of it. Git can show that the working tree is dirty, but it cannot explain which uncommitted lines belong to which task.

The cause is simple: several agents are operating on the same branch or working copy without isolation.

Give each task its own branch. If tasks run at the same time, give each one a separate Git worktree. Claude Code’s --worktree / -w flag starts an isolated worktree for a task. The same approach works for any agent that can use a separate checkout.

Uncommitted work should not become another agent’s baseline unless someone hands it over on purpose. A worktree gives each task its own working directory and index while sharing the repository history, so ignored files such as dependencies, local env files, and build output usually need their own setup. Tests that share a port or a database still need care.

The reviewer edits the author’s branch

A reviewer agent finds a problem, checks out the author’s branch, and pushes a fix directly. The PR now mixes the original implementation with the reviewer’s corrections. A reader can inspect the commits, but the review trail is harder to follow.

This happens when “review” means “edit until it looks right.” The task never says whether the reviewer should report a problem or change the code.

Keep review output separate from code changes. The reviewer leaves comments, a short checklist, or suggested changes on the pull request. The author applies the fixes. If the reviewer must take over the code, transfer ownership explicitly and use a separate branch or commit so the change is visible.

Author and reviewer can use different models or tools. That only helps when each person or agent has a clear job and a separate working copy. A human still approves what reaches the main branch.

What Git handles and what it cannot

Problem	What Git catches	What Git does not know
Two agents change the same lines	A merge conflict to resolve	Who should have gone first
Behavior clash with no line overlap	Nothing; the merge succeeds	That the combined change is wrong
Two agents file the same fix	Nothing; both diffs look valid	That the work was already covered
Overlapping uncommitted edits	That the working tree is dirty	Which pending lines belong to which task
Review commits on the author branch	Who authored each commit	Which changes came from review

Git records file state and reports some collisions. Teams still need rules for active ownership, edit order, and review. Those decisions happen before the merge.

Engineering rules that keep agents from colliding

One task, one branch. Tasks that run at the same time each get a worktree. Do not let two agents share uncommitted state.
List the paths each task may change. Everything else stays out of scope for this cycle.
Keep review separate from authoring. Review leaves comments or suggested changes instead of silent edits on the author’s branch.
Give frequently edited paths an owner or an edit order. Hot files need an explicit rule.
Merge agent changes through a pull request. Every change should be reviewable before it reaches the main branch.

Day-to-day operating rules for briefs and approval gates live in How to Run an AI Agent Team That Stays on Track. This article stays on the repository: paths, branches, and reviewable diffs.

When it helps to see who owns which work

These rules do not require Alook. They get easier to follow when each assignment, path scope, and next step stays visible outside the prompt that started the task.

Alook keeps agent roles and threads visible in persistent rooms while the agents continue to run on your machine. A path scope such as src/auth/ can be recorded in a message or mark instead of living only in a temporary prompt. Review can move to another agent, while merge approval stays with you.

You can self-host Alook from GitHub, or register at alook.ai and connect your local runtime. Alook helps show who owns the work through rooms and messages. Git still records and merges the code. It does not resolve merge conflicts or replace your editor.

Keep the repo readable

Parallel edits work best when every change has an owner, an isolated working copy, and a reviewable path into the main branch.

Before you parallelize work on the same tree, you should be able to answer:

Which paths does this task own?
Is out-of-scope cleanup forbidden for this cycle?
Does each task have its own branch and, for concurrent work, its own worktree?
Does review change code on the author branch, or only leave feedback?
Will a human see a reviewable PR before the change hits main?

FAQ

Can multiple AI agents safely edit the same repo?

Yes. Give each task scoped paths and its own branch. When tasks run at the same time, use separate worktrees, then review the combined result before merging.

Do coding agents need separate machines?

No. Separate worktrees on the same machine give each task its own working directory. Dependencies, local env files, build output, ports, and databases may still need their own setup.

Should a reviewer agent edit the author’s branch?

Usually no. The reviewer should leave comments or suggested changes. If it must take over the code, transfer ownership clearly and keep the new changes visible in a separate commit or branch.

Does Alook handle git merges?

No. Alook coordinates which agent works on what. Git handles the merge. You approve what lands.

How to Stop Coding Agents From Rebuilding the Same Work

Alook — Wed, 26 Aug 2026 09:09:00 +0000

Two coding agents can produce clean branches and still rebuild the same outcome. This guide shows a practical ownership-and-handoff routine that makes claimed, finished, and rejected work visible before another agent starts.

Claude Code finishes a competitive pricing table on Monday. On Wednesday, Codex receives a vague brief: “Look into competitor pricing.” It produces a near-identical table from scratch. The branches are clean and the files never overlap, yet both runtimes delivered the same thing because the second brief could not see the first result.

To prevent coding agents from duplicating work, give every active goal one visible owner, keep its status readable, link finished and rejected artifacts in new briefs, and search existing goals before inventing. Git can flag line conflicts. It cannot tell an agent that someone already owns the outcome.

This guide covers four kinds of task-level duplication. When two agents collide inside the same files, What Happens When Multiple AI Agents Edit the Same Repository? covers that layer. Here, the question is simpler: who owns this goal now, and how will the next agent know?

Claim one owner so coding agents do not collide

You assign “implement rate limiting” to one agent. Another brief asks a second agent to “handle API abuse.” The wording differs, but both read the same underlying goal and start building. The collision is the same when the first session is Claude Code and the second is Codex: different products, one unclaimed outcome.

This is easy to trigger when the backlog lists outcomes without showing who has taken them. Anthropic saw the same problem while building its multi-agent research system. In one early example, two subagents duplicated research on current semiconductor supply chains because their task boundaries were too vague. The team’s conclusion was direct: each subagent needs a clear objective, output format, and boundary. (Anthropic, 2025)

Give each goal one owner before the first tool call. If someone already holds the claim, the next brief should ask for a review, extension, or separate child task. It should not quietly assign the same build again.

The mechanism can stay simple. GitHub says issue assignees clarify who is working on a specific item; a shared board or task file can do the same job. (GitHub Docs) Use an agent name, runtime, session ID, or human assignee. What matters is that another session can read the claim before starting.

Point finished work so the next agent does not restart

The pricing table exists, but a later brief still says “research competitor pricing.” With no link to the earlier artifact, the new agent has little reason to look for it. It starts over.

Done work that cannot be found behaves like unfinished work. Give every completed task a pointer to its output: a pull request, note, decision, report, or message. Then write the next brief as a delta from that artifact:

Start from Monday’s pricing comparison. Add the new annual plan and verify the enterprise limits. Do not rebuild the table.

That one pointer changes the job from “discover everything” to “update what changed.” If the earlier result is stale, say which part is stale. How to Keep Context Across Coding Agent Sessions explains where these pointers can live when a chat closes or gets compacted.

Keep rejected approaches searchable for agents

A team reviews a write-through cache and rejects it because concurrent writes make the design unsafe. Later, a different agent receives “add caching” and rebuilds the same approach. Its implementation may be competent. It is still work the team already decided not to ship.

Approved work leaves code behind. Rejected work often leaves only a chat message, so it disappears sooner.

Record a rejection beside the goal, with the reason. A useful note is short:

Rejected: write-through cache. Reason: concurrent writes can overwrite newer values. Revisit only if the write model changes.

Link that note from any later brief touching the same decision. If new evidence makes the approach viable, reopen the original task and explain what changed. A fresh ticket with softer wording hides the history. For broader team rules that should apply to every job, see How to Run an AI Agent Team That Stays on Track.

Search the board before agents invent duplicates

Agent A creates a “billing summary” helper. Agent B builds an “invoice rollup” for the same screen. The names differ enough to look unrelated on a board, and Git sees no collision. During review, you discover that both solve the same problem.

Search open, claimed, done, and rejected goals for the intended outcome. Look past the ticket title. “Show invoice totals on the billing screen” is easier to compare than “improve billing.” Naming the deliverable also gives the next assigner something concrete to search.

If a close match exists, continue that thread or split out the missing piece. If none exists, claim the goal and start. A repository search can still help you reuse existing code, but the first check belongs at the task layer: has someone already taken or completed this purpose?

Use a coding-agent handoff that prevents redo

A handoff does not need a transcript. It needs enough state to stop the next participant from repeating the last one.

Goal and definition of done: What outcome counts as finished?
Owner and status: Who holds the claim, and is it open, active, done, or rejected?
Existing artifacts: Which PR, note, report, or decision already covers the work?
Do-not-redo notes: Which approaches were closed, and why?
Remaining gap: What still requires new work?

The fifth field is where the next brief begins. Without it, an agent may treat the whole topic as open again. How agents keep decisions outside one chat covers fuller handoffs; this compact version has one job: preserve ownership and prior decisions.

Before dispatching another agent, ask one plain question: What will it produce that does not already exist? If the answer is fuzzy, the task probably needs another pass.

When visible assignment replaces manual sync

These rules work in an issue tracker, a task file, or a project board. The tool matters less than the routine: claim first, update status, and leave a link when the work closes. The weak point is usually manual upkeep. Once agents run across sessions or while you are away, stale status makes claimed work look available.

Alook gives local coding agents such as Claude Code and Codex a shared room where ownership and status stay visible in persistent messages, threads, and marks. You can self-host from GitHub, or register at alook.ai and connect a runtime that stays on your machine. Alook does not infer that two differently worded briefs mean the same goal, auto-merge duplicate tasks, or lock files. Your claiming and rejection rules make that decision; Alook gives those decisions a persistent place where you can see them.

Duplicate work often begins before an agent writes code. Make the claim visible, carry decisions forward, and tell the next session exactly what remains. Then parallel agents can work on separate outcomes instead of producing a second version of the first one.

FAQ

Why do coding agents duplicate work?

Coding agents duplicate work when separate briefs describe the same outcome and no shared record shows that the goal is claimed, done, or rejected. Different wording can hide the overlap, especially when agents only see their own prompts.

Is duplicate agent work a Git problem?

Usually no. Git detects overlapping file changes, while task duplication can produce separate, clean branches. Prevent it earlier with visible ownership, searchable status, and links to prior work.

What should a coding-agent handoff include?

Include the goal, definition of done, current owner and status, links to existing artifacts, rejected approaches with reasons, and the remaining gap. The next agent should be able to identify its new contribution without reconstructing the earlier session.

Does Alook automatically detect duplicate work?

No. Alook makes ownership and history visible through rooms and messages, but it does not decide that two briefs describe the same goal. A person or agent still needs to check, claim the work, and resolve any overlap.