Using Entire to pick up where your teammate’s coding agent left off

Imagine you're at a hackathon. While you nap, your teammates leave a coding agent running overnight. You wake up to a tonne of new code, and nobody has any idea what's going on. Before blindly continuing to build, I'd personally want to recover the original request sent to the coding agent and understand the changes.

Entire does exactly that: it's built on top of Git, and it connects a commit (a saved code change, if you're unfamiliar with Git) to the agent session behind it. A coding agent (e.g. Claude Code, Antigravity, etc.,) reads files, edits code and runs commands in response to your prompts. Entire essentially captures that work in checkpoints, so you can retrieve the conversation alongside the code.

This post is a walk-through of a simple Python project showing what you can do with Entire. Jump to setup if you want to install Entire first.

What did your teammate actually ask for? (Entire Checkpoints)

The demo project I made is straight-forward - it literally just calculates delays between attempts to send a web request. Suppose a teammate's commit starts allowing retries for POST requests, which can create things like orders. Repeating one could create a duplicate. What did they ask the agent to do?

From the project folder, list the saved Entire checkpoints and open the one linked to the commit:

entire checkpoint list entire checkpoint explain 4a52357 --full --no-pager 

4a52357 is this demo's commit ID; substitute one from your own project. --full displays the saved conversation, and --no-pager prints it directly in the terminal.

Original prompt to my coding agent, retrieved by Entire:

Add retries for POST requests, but only when the caller supplies an idempotency key. Preserve the existing behaviour otherwise, add tests, and explain the design choice.

This is a small retry-schedule CLI, not an HTTP client. Expose the option through the Python function and CLI. Assume the caller uses an endpoint that supports idempotency keys and sends the same key on each attempt; document that contract.

(Beginner tip: An idempotency key allows us to identify an operation so a supporting server can recognise a repeated request and avoid doing it twice. CLI means command-line interface, and this project's CLI calculates delays).

Here is my coding agent's explanation, recovered from its final response in that session using the Entire checkpoint:

The docstring and CLI help document the contract: the endpoint must support idempotency keys, and the caller must send the same key on the initial request and every retry. This explicit opt-in addresses duplicate-operation risk while keeping the tool schedule-only.

I can now check the code against an explicit requirement: retries were requested, provided the application reuses the key with a supporting server. Entire has provided the context I was missing, so I can continue to build.

What did the agent try, and did it work? (Checkpoint transcripts)

The same --full output records commands and responses. These excerpts appear in this order: [Tool] marks an action the agent took.

[Tool] Bash: python3 -m unittest -v 

Recorded [Assistant] response:

The option and tests are in place. The first test run caught a Python 3.9 compatibility issue in the new type annotation; I’ll fix that and rerun the suite. POST retries use the existing statuses and delays, with the caller responsible for sending the same key on every attempt.

[Tool] Bash: python3 -m unittest -v && git diff --check && git diff --stat 

The first test run failed; the agent fixed the compatibility issue and ran it again. To inspect the captured command results as well, export the raw session log:

entire checkpoint explain 4a52357 --transcript > session.jsonl 

session.jsonl contains structured records, one per line, including the Python 3.9 error and successful eight-test run. I can inspect a failed attempt that the final code no longer shows.

What changed in the next request? (Checkpoint history)

The first version accepted a key containing only spaces. I continued the same coding agent session with this follow-up prompt:

A caller supplied an idempotency key containing only spaces, and POST retries were enabled. Treat empty or whitespace-only keys as missing. Do not strip or otherwise alter a real key: keys are opaque values. Add regression tests for the function and CLI, keep Python 3.9 support, and explain why you chose validation rather than normalisation.

The resulting commit was fc42200. Opening its checkpoint reveals the response to that request:

entire checkpoint explain fc42200 --full --no-pager 

The coding agent's recorded response:

Empty and whitespace-only keys now leave POST retries disabled. Keys containing any non-whitespace character remain valid, including keys with surrounding whitespace.

Validation uses isspace() without stripping or rewriting the key. Idempotency keys are opaque; normalization could change the identity of an operation.

The follow-up prompt explicitly told the agent to preserve spaces in valid keys. Entire keeps that instruction alongside the resulting code change, so a teammate can see why the behaviour exists before changing it (if needed). It's worth highlighting that each commit gets its own Entire checkpoint even if its all one agent session - pretty handy. Opening the later checkpoint with --full shows both requests from that conversation.

How do I start capturing sessions? (entire enable)

You'll need Git, a project and a supported coding agent. On macOS with Homebrew installed, run this from the project's folder:

brew install --cask entireio/tap/entire entire enable --local \ --skip-push-sessions --telemetry=false entire status 

Run these commands from your project’s folder. During setup, select your coding tool and complete any requested hook approvals. These options keep settings local, disable automatic session uploads and turn off usage analytics. entire status shows whether setup needs further attention.

Check entire status for setup issues. "Hooks" capture activity as you work; approve them in your coding agent if requested. Start a new session, ask for a small change, review it and commit it with Git, and then you're good-to-go. Verify that you can retrieve the prompt:

entire checkpoint list entire checkpoint explain --commit HEAD --full --no-pager 

HEAD means your latest commit. If the session wasn't captured, you can attach its existing log after committing. This is how I captured the demo sessions:

entire agent list entire session attach <session-id> --agent <agent-name> 

Run entire agent list to find the name Entire uses for your coding tool, then replace <agent-name> with that name. Replace <session-id> with the ID of the conversation you want to attach. If Entire hasn't captured it yet, get that ID from your coding tool's session history or logs. Attach shows what it will do before asking for confirmation. For a commit that hasn't been pushed, adding the checkpoint link can change its ID without changing the code.

How do I save a decision for future work? (Entire Brain)

A checkpoint keeps the conversation. Brain, Entire's optional memory plugin, lets me save a specific decision for later retrieval. This is one of my favourite features! It's pretty simple to install:

entire plugin install brain entire brain setup entire brain status 

Setup indexes your project, installs a background service to keep Brain current, and adds instructions explaining how your coding tool can use it. After setup, restart your coding agent or reload its project instructions so it picks up those instructions. Setup also asks whether to extract memories from past sessions. Checkout the Brain setup guide for more set-up options.

To save a decision yourself and link it to the conversation it came from, first find that conversation's "session ID". A session is one conversation with a coding agent, including its prompts, replies and actions. From your project's folder, list the sessions Entire has recorded:

entire session list 

Find the conversation using its coding-tool name, prompt and timing. Copy the full identifier labelled session, rather than the checkpoint ID. Replace <session-id> in the command below with that value, including removing the angle brackets:

entire brain remember \ "Reject empty and whitespace-only idempotency keys. \ Preserve surrounding whitespace on nonblank keys because keys are opaque \ and normalisation could change the identity of an operation." \ --path constraints.retry.keyvalidation \ --kind decision --agent none \ --session <session-id> 

--path sets a category, --kind labels the decision, and --agent none saves the text without asking an agent to categorise it. --session records which conversation the decision came from, so someone reviewing the memory can look up that conversation later.

Brain can also receive the ID through an environment variable, ENTIRE_BRAIN_SESSION_ID: a value supplied by the program launching Brain. When that value is supplied, you can omit --session. The command above passes the ID explicitly, so it works without relying on your coding tool to supply it automatically.

How do I retrieve a rule? (Brain Recall)

You can retrieve a saved rule, or gather context before a new task by searching the brain via Entire CLI:

entire brain recall "opaque key whitespace" --no-global entire brain brief "Change POST retry validation" --json 

recall returned my authored rule with its source session and commit. --no-global excludes global memories. brief gathers project context, and --json makes it structured for an agent. Brain’s setup tells your coding agent how to look up saved decisions. In this example, the saved decision says to reject blank idempotency keys and leave other keys unchanged. If a future agent is asked to tidy up the retry code, it can find that instruction and understand why it should preserve spaces in valid keys.

Can I explore the project visually? (entire brain viz)

Run this inside the project to open Brain's local browser interface:

entire brain viz 

The overview shows the project's code graph, session, history and three saved facts: the retry requirement, key validation and Python compatibility.

Search for "whitespace" and open the saved decision. The inspector shows the rationale alongside search results for relevant tests and history:

Open the test for a key with surrounding spaces. Its graph links it to the retry_delays function it calls and the test class containing it. This gives me specific code to inspect after reading the conversation:

How does my teammate get the context? (Fetching checkpoints)

I made a second local clone, a separate repository copy. It contained the code and checkpoint IDs, but needed the saved records too. This fetched them from origin, the source repository:

git fetch origin '+refs/entire/checkpoints/*:refs/entire/checkpoints/*' entire checkpoint list 

This command works when that remote already holds the checkpoint records. The setup above disables automatic uploads. Use entire status to check the upload destination and follow the session-sharing setup before fetching from another machine. Brain memory sharing is configured separately through Brain's hosted connection. Check what a transcript contains before uploading it to a public repository.

In the new copy, I gave a fresh coding agent this review prompt:

You are picking up a teammate's retry-policy CLI. Explain why POST retries now require an idempotency key and why whitespace around a nonblank key is preserved. Start from the latest two Git commits and use Entire's saved checkpoints to recover the actual requests and recorded explanations before reading the code.

The agent recovered both requests, read the code and passed all ten tests. It also noticed the tests wouldn't catch the code silently stripping spaces from keys. Reading the implementation confirmed it preserved them. The session supplied the requirement; reviewing the code checked whether it was met.

How do I continue the original conversation? (entire session resume)

Use the name of the Git branch:

entire session resume feature/keyed-post-retries 

In my original checkout, Entire found the saved conversation and printed the command to reopen it in my coding tool. Replace feature/keyed-post-retries with your own branch name and follow the instructions Entire displays.

For my next change, I'd start with the relevant checkpoint, retrieve any saved decisions, then ask the agent to work against those requirements. That gives both of us the original context before we edit the code.

When would I mirror my repository? (Entire repository mirroring)

Mirroring means Entire stores a second copy of your GitHub project's files and Git history on servers it runs, and keeps that copy updated from GitHub. You and your coding agents can download the project from Entire. When you push a mirrored branch through Entire, it forwards the changes to GitHub, where your existing permissions and branch protection rules still apply. GitHub remains the main repository. More on how mirrors work.

I'd consider this when a team wants to review proposed code changes in Entire's website and see automated review findings in its Trails pages. It can also help when agents running in different regions repeatedly download a large project: Entire can keep copies near those agents to reduce the time they spend waiting for the code. Mirroring is optional for the local workflow above, though. The mirroring guide walks through signing in, giving Entire access to your GitHub repository and choosing where to host the copy.

Commands and output from Entire CLI 0.13.1, Brain 0.5.1 and Graph 0.6.0 on macOS.