DEV Community: Rizèl Scarlett

How to Improve Playwright Test Coverage Using Agent Context

Rizèl Scarlett — Tue, 18 Aug 2026 00:23:30 +0000

I don’t know how to play an instrument, so obviously I built one as an app. Literally, everyone in my family can sign or play an instrument, and I’m the odd one out.

And I know what you’re thinking, “Who cares? With AI, you can build almost anything.” I’m more excited about the technique I chose to build the app with my agent. Specifically I used context from the agent session that built the app to find and fix the most important gap in its Playwright tests.

Here’s how I did it.

Step 1: Install Entire

Entire captures the prompts, transcripts, tool calls, and decisions behind agent-generated code, seamlessly connecting that underlying context to your Git commits through lightweight checkpoints.

On macOS:

brew tap entireio/tap
brew install --cask entire

Check out these instructions to install on your operating system.

Step 2: Create the project

I created an empty directory (or you can ask your agent to do this)

mkdir music-app
cd music-app

Step 3: Enable Entire

Before handing off any work to the agent, I initialized Entire directly within the repository because I wanted to capture my agent sessions:

entire enable -y

You can also target a specific agent (I personally use Codex):

entire enable -y --agent codex

This sets up the background hooks Entire relies on to capture agent activity, binding that session context directly to the commits generated along the way.

Step 4: Turn the vague idea into a plan

Rather than starting with a rigid technical spec, I simply shared my initial idea:

I'm not entirely sure about the app i want to build..but i want to build a music app that enables me to play instruments even though idk how..this should use computer vision and it should be able to work with real instruments or just like "air" instruments as in there's no instrument there..but i am moving fingers and sounds are being made..and it should like im making real music. idk if this should be sonic pi..but i know i should use media pipe for it. lets start working on a plan together

Working together, the agent helped refine this into an “Air Jam” concept: a browser app where MediaPipe tracks hand gestures, a custom gesture engine interprets them, and Tone.js handles the audio output.

Wanting it to double as a learning tool, I followed up with:

can it still show keys and chords etc..like still be a learning tool in some way

That added a crucial new dimension. Beyond being a fun novelty, the app could now render notes, highlight active scales and chord tones, and eventually break down the music theory behind what was being played.

To lock this down, I asked the agent to document everything:

ok lets put this plan into a markdown file

It generated PRODUCT_PLAN.md, detailing the vision, architecture, development stages, MVP targets, and explicit success criteria.

Phase 1 focused on laying the foundation:

Bootstrap the browser application.
Request camera access and show mirrored video.
Integrate MediaPipe Hand Landmarker.
Draw hand landmarks and confidence information.
Define eight virtual strings.
Detect a fingertip crossing one string.
Trigger a basic synth note.
Add filtering, hysteresis, and note cooldowns.
Measure tracking rate and gesture-to-sound latency.

Most importantly, it defined a clear exit condition: Deliberate movements reliably produce one corresponding sound with few false triggers.

Step 5: Set up atomic agent commits

I prefer keeping commits bite-sized, which is especially helpful when an agent is touching multiple parts of a codebase. To enforce this, I added a repo rule:

also in an agents.md write a rule that says every time we make a change to a file, make a commit

Since I didn't want that configuration change committed just yet, I quickly clarified:

no dont make any commits..just add the note

From then on, the agent created neat, focused commits as features were built. And thanks to Entire, every single commit remained tied to the exact session context that created it.

Step 6: Build Phase 1

With the roadmap in place, we dove straight into implementation:

lets start with phase 1..gesture to sound experiment

The agent systematically assembled the foundation:

Webcam access
MediaPipe hand tracking
Eight virtual strings
Gesture-to-note conversion
Tone.js audio
Velocity-sensitive notes
Gesture smoothing and cooldowns
Landmark and string visualizations
Camera-free note buttons
Live performance diagnostics

And just like that, it worked. I could wave a finger across a virtual string and play a fully functional air harp.

Step 7: Generate Playwright tests

Before expanding the app, I wanted a solid browser test suite to protect what we’d built. I kept my request broad:

write some playwright tests

The agent generated five passing Playwright tests covering:

The initial interface
Camera-free note buttons
Starting and stopping the synthetic camera
Camera permission errors
The mobile layout

On paper, everything was green. But a passing test suite doesn't automatically mean you're testing what actually matters. Because I hadn't written the code or designed the test architecture myself, I wasn't entirely convinced these five tests actually protected the core user experience.

Step 8: Start a new agent session

By this time, my original session had consumed roughly 87 percent of its context window.

I generally avoid pushing agents when their context gets that crowded. It puts them right into what I call the "dumb zone." While the agent technically retains the conversation history, its ability to prioritize key details begins to degrade.

My usual fix is to compact the history or spin up a fresh session. I opted for a fresh start here, not as a staged setup for this article, but as a natural next step after an extended session spent planning, building, debugging, and testing.

Step 9: Compare the tests with the original intent

While the new agent could easily read the code, I wanted it to evaluate the application using the rich context Entire had captured from our earlier planning, implementation, and testing sessions.

I passed it this prompt:

look at the existing Playwright tests and compare to my entire sessions and checkpoints. Do they actually test the main user experience from beginning to end, or do they only test separate pieces of it? Tell me what important behavior is still untested, and show me what you found in the sessions that led you to that conclusion.

The agent pulled up the Playwright suite, cross-referencing it with our earlier Entire checkpoints. Codex summarized its findings:

We tested the camera. We tested the notes. But we never tested that moving your hand actually plays a note.

And there it was. It hadn't actually tested whether waving your hand played a note, which is the fundamental purpose of the app.

Digging deeper into the suite revealed why:

The camera tests used synthetic video, but the MediaPipe mock always returned zero hands. It proved the video feed could toggle, but never actually passed hand data through the system.
The note tests triggered audio by clicking UI buttons directly. They proved notes could sound, but skipped testing whether a tracked fingertip crossing a virtual string would trigger one.

Entire provided the agent with concrete historical context to back up this realization:

The original planning checkpoint explicitly required that deliberate movements produce exactly one sound.
The implementation checkpoint defined the core feature around that full camera-to-gesture-to-note feedback loop.
The test-writing checkpoint showed that the initial five tests were narrowly scoped to basic UI, buttons, camera toggles, errors, and layout.

Step 10: Add the missing Playwright test

With the gap exposed, I gave a final instruction:

generate tests for the missing gap

The agent updated the MediaPipe mock to supply realistic 21-point hand coordinates, simulating an index fingertip sweeping across a virtual string.

The new test verified that:

MediaPipe successfully returned a tracked hand.
The fingertip crossed the target string.
The corresponding C4 note activated.
The note counter incremented exactly once.
Settling after the gesture produced no duplicate triggers.
No hidden browser errors occurred during the gesture loop.

That brought our suite from five tests to six. But more than just increasing the count, that sixth test mapped directly back to the success criteria we set during our very first planning session.

What makes this test genuinely better?

It’s easy to fake a bug or throw in a superficial assertion to craft a good story, but that wasn't the case here. This test is fundamentally better because it:

Protects the primary user journey.
Exercises the full stack of components end-to-end instead of in isolation.
Directly reflects our original definition of success.
Uses deterministic synthetic landmarks so it can run reliably in CI without a physical webcam.
Ensures strict reliability by validating that one gesture yields exactly one note.

To be clear, it doesn't guarantee that a real-world MediaPipe model will capture every single hand type or that audio physically plays through a user's speakers. Those require dedicated smoke runs or hardware testing. But it does prove that when realistic hand coordinates hit the app, the entire gesture-to-note pipeline executes flawlessly.

I don’t use Entire to save my chat transcript and scroll through later on. Instead, I gave it to my agent to use as the historical evidence it needs to make better engineering decisions.

Please note that I wrote some of this by hand but for much of it I asked my agent to look at my session context and turn it into a blog. Because I have other work to do, and I'm trying to catch up!!

How to Review AI-Generated Code with Multiple AI Agents

Rizèl Scarlett — Fri, 14 Aug 2026 22:40:09 +0000

Having one model review code written by a model from a different family is becoming increasingly popular.

You might build a feature with Codex, then ask Claude Code to review it. The idea is that each provider trains its models differently, so the reviewing model may catch problems the original model missed.

That sounds useful, but it raises an important question: what information are we giving the reviewing model?

Is reviewing the code enough?

A typical AI code review might include the final code, the diff, and the commit history.

That tells the reviewer what changed, but not why it changed.

In the era of coding agents, much of the reasoning behind an implementation lives inside the agent session. That session can include:

The original prompts
The agent’s responses
Tool calls and commands
Files the agent inspected
Constraints provided by the developer
Decisions and alternatives considered along the way

Without that context, a model can identify potential bugs, questionable patterns, or missing tests. What it cannot reliably determine is whether the final implementation matches what the developer actually requested.

Trying an adversarial review without context

I built an Arcade feature with Codex, then asked Claude Code to review the result.

The review produced reasonable feedback, but it felt incomplete and superficial. Claude could inspect the implementation, but it did not have the conversation that produced it.

It could review the code as written. It could not compare that code against my original intent.

This is the missing piece in many cross-agent reviews. The reviewing model sees the destination, but not the journey that led there.

Reviewing with the full agent session

Entire captures the context behind agent-assisted work and connects it to Git through checkpoints.

Instead of giving a reviewer only the final diff, Entire can provide the prompts, responses, tool activity, file changes, and decisions that produced it.

From an Entire-enabled repository, either you or your coding agent can start a review by running:

entire review

On the first run, Entire guides you through creating a review profile. A review profile is a reusable configuration that defines what should be checked, which agents should perform the review, and which agent should consolidate the results.

You can select multiple reviewers. Entire runs them in parallel, then sends their findings to a judge that combines them into one final report.

The judge resolves contradictions, removes duplicate findings, and prioritizes issues supported by evidence.

Checking the code against the original prompt

Because Entire stores the original prompts and agent responses, I could add another check to the review profile:

Compare the final code against what I actually prompted for.

To edit the checks in a review profile, run:

entire review --edit

This turns the original prompt into part of the review criteria.

The reviewer is no longer limited to asking, “Is this code correct?”

It can also ask:

Did the agent build what was requested?
Were any requirements missed?
Did the implementation add behavior that was never requested?
Did the agent drift away from the original intent?

Once the profile is ready, start the configured review:

entire review general

The selected agents perform their reviews in parallel, and the judge produces a consolidated verdict. You can learn more about this workflow in the cross-agent review tutorial.

Catching intent drift

In my Arcade example, I asked for two ad cards, one for each game.

The agent built three.

A traditional code review might not flag that. Three cards are not necessarily broken code. The implementation could be clean, tested, and technically correct.

But it was not what I requested.

Because Entire gave the reviewers access to the original prompt, the final report identified the extra card as intent drift. The implementation had drifted away from the stated requirement, even though the code itself appeared valid.

That is the difference between reviewing only the output and reviewing the complete body of work.

Code review for the era of agents

Cross-agent adversarial review is a useful start. Different models can notice different problems.

But changing the reviewing model is only part of the solution. The reviewer also needs the context behind the implementation.

When the review includes the prompts, responses, decisions, and final code, it can evaluate more than technical correctness. It can determine whether the agent understood the task and delivered what was actually requested.

That is code review built for the era of agents.

Try Entire today or explore the entire review documentation.

How to Enable Entire

Rizèl Scarlett — Fri, 14 Aug 2026 22:17:46 +0000

How to Enable Entire in Your Repository

Entire captures the context behind AI-assisted code changes and connects it to your Git history.

It preserves details such as prompts, tool calls, file changes, and session transcripts as checkpoints. A checkpoint is a versioned record of the work completed during an agent session, linked to the Git commit that resulted from it.

Here’s how to enable Entire and prepare your repository for its first checkpoint.

Enable Entire with one command

From the root of your Git repository, run:

entire enable -y

The -y flag accepts the default setup options, including enabling Entire for all supported coding agents.

Entire installs the necessary hooks and creates its project configuration. These hooks capture the context from your agent sessions and connect it to your commits.

Where Entire stores checkpoint data

New setups use Git refs by default, storing each checkpoint independently under:

refs/entire/checkpoints/

Entire also supports storing checkpoints together on a dedicated branch:

entire/checkpoints/v1

Both approaches keep your session history separate from your working branch, so transcripts and checkpoint metadata do not clutter your code commits.

To select the branch-based option explicitly, run:

entire enable -y --checkpoint-backend branch

Existing repositories using entire/checkpoints/v1 can continue using it, while new repositories use the refs-based approach by default.

Configure Entire interactively

If you want to review the setup options and choose which agents to connect, run:

entire enable

Entire will guide you through the configuration process.

You can also select a checkpoint storage option explicitly:

entire enable --checkpoint-backend refs

Or:

entire enable --checkpoint-backend branch

Confirm that Entire is enabled

Once setup is complete, check the repository’s status:

entire status

You’ll see which agents are connected, where checkpoints will be synchronized, and whether any agent sessions are active.

After you work with an agent and create a Git commit, you can view the resulting checkpoints with:

entire checkpoint list

Your repository is now ready to capture the context behind your agent-assisted work.

For a complete walkthrough, visit our Quickstart. If you are working with sensitive repositories, review Entire’s security and privacy documentation.

Happy trails!

How I Put My Agent in CI to Automate Release Notes

Rizèl Scarlett — Fri, 31 Jul 2026 19:00:39 +0000

When I joined Entire, I noticed my boss spending a chunk of time every week writing detailed release notes, called Dispatches at Entire. It looked like a painful process. Each Dispatch had to cover changes across several repositories, explain why those changes mattered, credit external contributors, and carefully avoid leaking anything that was not public yet.

I offered to take it over. I had solved a similar problem before, so I figured it would be an easy win.

The release notes generator I built at Block

While I was at Block, I built a release notes generator for goose. It ran in GitHub Actions after a release workflow completed, checked out the new tag, compared it against the previous one, and handed goose a recipe to inspect the commit diff.

Goose organized those commits into features, bug fixes, improvements, and documentation. Each entry got a short description and a PR link. The workflow then updated the GitHub release and posted the announcement to Discord, opening a thread if the notes exceeded the message limit.

It was clean and effective, but it solved a very clean problem: one repository, one new release tag, public commit history, and concise output. So when I looked at Entire’s Dispatches, I assumed I could reuse the same playbook. Gather changes, run goose, post the draft. That assumption did not survive contact with reality.

A Dispatch is not a list of commits

A Dispatch spans multiple projects: the Entire CLI, entire.io, EntireDB, external agent integrations, and open source libraries like go-git, go-nuts, git-sync, and ForgeMark. Every project also ships on a different cadence. Some push to main and deploy continuously. Others bundle work into scheduled releases. The CLI maintains separate stable and nightly channels, which means a feature can be available to testers without being part of the latest stable tag.

Then there are feature flags. Finding changes was not the hard part because GitHub APIs handle that easily. The hard part was figuring out which changes were safe to announce. A private repository might contain code for a feature that has already launched publicly, while a merged public PR might still be hidden behind a flag. Repository visibility tells you very little about feature visibility.

The pipeline could not just answer “What changed?” It also needed to answer:

Has this actually shipped?
Is it live for everyone or gated behind a flag?
Is it stable or nightly?
Does it matter to a reader?
Did a community contributor help build it?
Is there anything sensitive here that should not be shared?

A script could pull the raw data, but those decisions required more context.

The first workflow and all its bad assumptions

My first GitHub Actions workflow for Entire was called Release Notes to Slack. It mirrored my setup at Block: monitor repositories for new releases, pull the diffs, and run goose inside the runner with a recipe that inspected tags and formatted notes for Slack. It made one major assumption: a release tag was the main unit of work. That worked for tagged repositories and failed for a weekly Dispatch trying to cover projects with different deployment processes.

The commit history from the first day reads like a real-time record of my assumptions falling apart. First, I tried running the workflow across every repository and aggregating the Slack output. Then I stopped relying only on release tags and used the previous Dispatch publication date as the start of the reporting window so the same work would not appear twice. Next, I added another goose recipe to turn those raw notes into a full Dispatch draft written in Marvin’s voice.

Then came the deployment edge cases. Merged code does not always mean public code. I updated the filtering so drafts only included work that was public, while keeping nightly changes clearly labeled. For entire.io, which uses continuous delivery and feature flags, I added PostHog checks so the workflow could see whether a flag was active before treating a merged PR as public.

Contributor attribution came next, followed by several experiments with the output: Slack messages, thread replies, Markdown tables, generated PDFs, and eventually a return to plain Markdown. The history was just me learning that “writing release notes” was several smaller problems stacked together.

The workflow eventually needed different goose recipes for different types of repositories. Entire.io needed rules for continuous delivery and feature flags. Tagged projects needed rules for stable releases, nightlies, and unreleased merges. Go-git needed specific community attribution rules because it is an external open source project. It worked, but the workflow became difficult to maintain. Data collection, release checks, contributor matching, writing style, and output formatting were all tangled together.

The problem was not running goose in CI. Goose had been running there from the beginning. The problem was deciding what context goose should receive and where each rule belonged.

Building V2 around structured collection

The second iteration, Release Summary to Slack V2, separated data collection from writing. Instead of asking goose to wander through repository directories and figure out what happened, the workflow gathers the facts first.

It starts by finding the date of the last published Dispatch and using that as the beginning of the reporting window. A matrix job then runs across every repository to collect releases, merged PRs, titles, descriptions, labels, authors, links, feature flag definitions, current PostHog status, commit authors, and organization membership data.

The first version of V2 also ran an entire dispatch command for every repository. I later removed that step and kept the factual collection inside the workflow. This made the inputs easier to inspect because goose received the underlying release and PR data instead of a mixture of raw facts and an earlier generated summary.

Before goose runs, the workflow turns those inputs into two files. The first is the Source Brief, which contains the releases, PRs, links, labels, feature flags, and repository metadata goose is allowed to use as facts. The second is the Style Reference, which contains excerpts from the three most recent Dispatches as examples of tone, structure, and length.

The recipe makes the boundary explicit. Previous Dispatches are for style only, so goose cannot pull an old change into the new draft simply because it appeared in an example. The recipe also defines a JSON response schema. Goose must return a payload containing the Markdown draft, and the workflow validates it before extracting the text. If goose returns a conversational preamble, malformed JSON, or an empty response, the build fails instead of posting a broken draft to Slack.

Why the workflow uses both a recipe and a skill

The system now relies on two pieces: a goose recipe and a Dispatch skill. The recipe controls the run. It tells goose which files to read, which sources it can trust, which tools are available, and what format to return.

The skill contains the reusable editorial rules, including which projects belong in each section, how to filter private or flagged work, how to separate nightly features from stable releases, how to explain the value of a change instead of repeating a commit message, and how to capture Marvin’s tone without recycling the same introduction every week.

The way I made that skill is a little recursive. I also created Entire’s session-to-skill skill, which came from a pull request I opened in the Entire skills repository. It searches Entire-tracked sessions and checkpoints for a repeated workflow, then turns the useful parts into instructions another agent can follow. It is not meant to copy a transcript into a Markdown file. It pulls out the decisions, corrections, commands, checks, and preferences that are worth repeating.

I used session-to-skill on the sessions where I wrote and revised previous Dispatches. Those sessions captured the parts that a finished blog post does not show: asking for every bullet to explain the benefit, rejecting intros that sounded corny, correcting project coverage, checking contributor credits, and removing work that was not public. That editing history became the source material for the Dispatch skill, so the workflow now benefits from decisions I had already made while doing the work manually.

The division now looks like this:

GitHub Actions gathers and organizes the facts.
The goose recipe controls the drafting run.
The Dispatch skill contains the editorial and writing rules.

Privacy still needs a person

The workflow can collect evidence, but it should not make the final privacy decision on its own. For entire.io, it checks feature flag states in PostHog. If a flag is disabled, internal-only, or in the middle of a rollout, the recipe tells goose to leave that work out. For other projects, if the workflow cannot confirm that something is public, the safest choice is to omit it and review it manually.

This is why I do not automatically publish the result. An awkward sentence is easy to fix. Accidentally announcing an unreleased feature or crediting the wrong contributor damages trust. The generated Markdown goes to Slack for review first.

The current workflow looks like this:

GitHub Actions finds the last published Dispatch date.
A matrix job collects activity, feature flags, and contributor metadata across the repositories.
The workflow compiles a single Source Brief.
It adds the latest Dispatches as Style References and loads the Dispatch skill.
Goose runs with the recipe and generates the Markdown draft.
The workflow validates the JSON response and uploads the draft to Slack.
I review, edit, and publish.

The workflow handles the part that used to take the longest: cross-referencing activity across projects and tracking down context. I can spend that time choosing the headline, refining the narrative, checking anything that might still be private, and cleaning up sentences that sound too much like pull request titles.

What actually got automated

When I built the goose workflow at Block, I thought release note generation was mostly a matter of diffing tags. That works when the boundaries are clear: one repository, public commits, and short output. The Entire Dispatch forced me to handle messier boundaries, including several repositories, different release schedules, feature flags, private work, and a distinct voice.

I did not automate editorial judgment. I automated the research, data collection, recurring checks, and first draft. Before this workflow, writing a Dispatch meant spending hours opening tabs, reading PRs, and reconstructing the week from scratch. Now goose brings the source material together, applies the editorial rules, and gives me a draft to polish.

Stateless MCP for Beginners

Rizèl Scarlett — Fri, 31 Jul 2026 18:34:13 +0000

I've been seeing news everywhere that MCP just went stateless, but I had no clue what it means. So I decided to dig into it and write a blog post about it.

Stateless MCP for Beginners

The Model Context Protocol (MCP) connects AI assistants to tools, databases, and external applications. In the 2026-07-28 specification revision, MCP removed protocol-level sessions and became stateless.

That change makes remote MCP servers easier to operate. They can scale behind ordinary load balancers without sticky routing or a shared MCP session store. Clients can safely cache tool definitions, and agents get more control over which application resources they share.

But stateless does not mean MCP servers can no longer remember anything. A browser can still have open tabs, a database transaction can still have uncommitted changes, and a shopping cart can still hold items. The difference is how the client refers to that state.

Why MCP Sessions Became a Problem

State is information a system remembers between requests. Imagine an MCP server that controls a web browser. An agent might call open_browser, followed by navigate, click, and take_screenshot. The server needs to know that all four actions refer to the same browser.

In earlier MCP versions, the connection could provide that context. The client began with an initialize request. Under Streamable HTTP, the server could respond with an Mcp-Session-Id, which the client attached to later requests. The server could then use that ID to recover information associated with the session.

This worked naturally when one client talked to one server process. It became more complicated when an MCP service ran across several machines behind a load balancer. If Server A created a session and the next request reached Server B, Server B needed some way to recover that session. Infrastructure teams typically solved this with sticky routing, which kept the client tied to Server A, or a shared database that every server could use for session lookup.

Sessions also meant different things in different clients. A session could last for one tool call, one conversation, one page load, or the lifetime of an application. Server authors could store a browser or shopping cart inside a session, but they could not reliably predict how long that state would survive or which conversations might share it.

What Changed in Stateless MCP

Under the 2026-07-28 revision, the initialize and notifications/initialized handshake is gone. Servers no longer issue MCP session IDs, and clients no longer store or resend them.

Instead, every request carries the protocol information needed to understand it, including the protocol version and client capabilities. A client can also call server/discover to learn which versions and features a server supports without opening a session.

This means any compatible server instance can understand an incoming MCP request without recovering information from an earlier handshake. If a tool manages application state, such as a running browser, the service still needs a way to locate that resource. Stateless MCP removes protocol session state, not application state.

Making Application State Explicit

When a tool needs state across calls, the server can return an explicit identifier, often called a handle. A handle is not a special MCP data type. It is an ordinary value returned by one tool and passed to another.

For example, a browser server might work like this:

// Open a browser and receive its handle
open_browser()
// Returns: { "browser_id": "browser_abc123" }

// Pass the handle into later calls
navigate({
  "browser_id": "browser_abc123",
  "url": "https://example.com"
})

The browser still lives on the server and keeps its tabs, cookies, and history. The relationship between calls is now visible in the tool arguments instead of hiding inside the connection.

Explicit handles also give orchestrators more control over shared state. If three agents are shopping together, they can share one cart_id while each receives a separate browser_id. A single MCP session could not express those two state boundaries cleanly.

Handling Multi-Step Work

Some tools need more information before they can finish. A deployment tool might ask for confirmation before publishing to production. Under the Multi Round-Trip Requests (MRTR) pattern, the tool returns an input_required result describing what it needs. The result may include an opaque requestState value, which the client returns with the requested answers when it retries the original call. The information needed to continue travels with the retried request instead of remaining tied to an open connection.

For longer-running or durable work, servers can use task handles through the Tasks extension. The client can check or update the task later without keeping a network connection open.

Making Tool Lists Easier to Cache

In previous MCP versions, the tools returned by tools/list could vary by session. A server might expose a connect_database tool first, then add query_database after the connection was established. Because the list could depend on session history, clients could not safely reuse it elsewhere.

Tool lists can still change when a server is updated or a user's permissions change, but they no longer vary by MCP connection. Servers return ttlMs and cacheScope values that tell clients how long a result should remain fresh and whether it can be shared. This allows an orchestrator to reuse tool definitions across subagents, reducing redundant requests and improving prompt-cache reuse.

What MCP Server Authors Need to Change

If you build or maintain an MCP server:

Update your SDK and version configuration: Use an SDK that supports 2026-07-28 and enable the new revision if your framework requires an explicit opt-in.
Replace session state with explicit handles: Return identifiers such as browser_id or connection_id and require them in later calls.
Plan for cleanup: Give temporary resources expiration policies or explicit cleanup tools instead of relying on a connection closing.
Authorize every handle: Treat an ID as the name of a resource, not proof that the caller can access it.
Make side effects safe to retry: Use idempotency keys where appropriate for operations such as charging a card or triggering a deployment.

The Takeaway

MCP began with a connection-oriented model that worked naturally for local processes running on a single machine. As the ecosystem expanded into cloud services, hosted gateways, and multi-agent systems, connection-level state became a scaling bottleneck.

The 2026-07-28 specification separates these concerns. Protocol details travel with the request, application state uses explicit handles, interactive workflows pass continuation state, and tool definitions are cached cleanly. MCP servers still remember everything they need to remember. They just name that state directly inside the request.

Why Is Everyone Trying to Rebuild Git Hosting?

Rizèl Scarlett — Wed, 15 Jul 2026 19:21:36 +0000

These past few weeks at Entire have been so exciting. We just launched our git hosting platform, and the reaction from the community has been incredible. People are genuinely embracing our product and our vision.

But I’ve also seen some completely fair curiosity. Some people are wondering: why are we trying to build a git hosting platform? GitHub has done an amazing job for almost two decades. It also has established and well-loved alternatives like GitLab and Bitbucket. There's also a new wave of git hosting competitors popping up that are tackling the solution from different angles. For example:

Tangled is focused on federated, social hosting using the AT Protocol.
Cursor Origin is building an AI-native forge to handle heavy agent traffic.
Gitlawb is leaning into decentralized agent identity.

So, which architecture actually makes sense for the future?

My answer is ripe with bias, but I truly believe Entire is the git hosting platform that will matter in the end.

That's because we aren't trying to rebuild GitHub 1:1 or just make a clone of it. Simply copying existing features onto a new host doesn't solve the friction of how humans and AI agents need to work together. We are building something fundamentally different.

To understand why there is a sudden race to rebuild git hosting, and why Entire’s approach is the one that will actually last, we have to look at how git hosting works under the hood.

The Beauty of GitHub

First, let's give GitHub credit where it’s due. I love GitHub. It is the platform where I first dived into coding, made my first open source contribution, and landed my first Developer Advocacy job. My Developer Relations career started at GitHub five years ago, and it changed my life forever. I found the career path I truly fit into.

Beyond that, GitHub made software development easier for the whole industry. Before it existed, people struggled to collaborate on code. Some developers used email, while others used systems that constantly overwrote lines of code and caused unresolvable merge conflicts.

GitHub put a beautiful interface layer on top of git (a command line tool that is not always the easiest to navigate) and made collaboration feel natural. The solution was so good that people often use "git" and "GitHub" interchangeably, even though they are different things. The pull request was a brilliant invention that allowed us to learn from each other, review code, and build together.

But platforms like GitHub were designed for human traffic.

The Problem

I don’t know if you noticed, but lately, major git hosting platforms have been having outages and performance issues. It’s becoming an expected part of the developer experience. It is widely acknowledged across the industry that AI and automated traffic is a major factor behind these reliability issues.

Before I joined this company, I noticed that many platforms and apps were down or buggy, so I blamed it on companies leaning too heavily into vibe coding, creating bugs that caused systems to crash. But for the case of git hosting problems, the culprit is agent traffic.

Traditional git hosting has a system that works well for the human pace of development, where humans search for code, clone repos, create branches, push commits, and open pull requests fairly slowly.

For example, it might take me days after cloning a repo, getting familiar with it, and trying to solve a problem before I am ready to open a pull request.

Traditional Code Hosting is Centralized

Traditional platforms store data in central servers by default, meaning the majority of global developer traffic goes directly to a primary cluster of data centers.

This central hosting infrastructure includes repo storage, networking, APIs, authentication services, databases, search, and Git servers that respond to commands like git clone, git fetch, and git push. Inside this infrastructure is a replication system that stores multiple replicas, or working copies, of a repository on different file servers. This helps make sure the repo remains available if one server or copy becomes inaccessible.

Traditional platforms also use Points of Presence, or PoPs, around the world. A PoP is mainly an entrance into the hosting network. It helps route the request, but the full repository operation is completed by the central hosting systems, not by the PoP itself.

This works pretty fine for the pace of human development.

But it doesn't work well for the pace of agent development.

Agent Traffic on Traditional Git Hosting Platforms

Picture this: I am in France and I have an agent. I could have it search for a repo, clone it, fetch its contents, read hundreds of files, make changes, push commits, and open a pull request within five minutes. I could even have multiple agents doing this at the same time, either across many repos or while solving several issues in one repo.

My agent in France sends its request to the closest PoP. The PoP routes the traffic to the provider's central network. When it gets there, that central network is chugging along processing API requests, searches, and git commands on many servers in parallel.

The PoP says: "Hey, Rizel’s agent wants to put up this PR."

The central cluster says: "You’re going to have to wait. I am processing as best as I can requests from thousands of agents across the globe. You will have to wait in line. Here’s a rate limit."

And if things get really bad, the infrastructure might say: "This is way too much. I’m shutting down for a little. I’m timing out. I’m overwhelmed."

Entire’s Approach: Distributed Git Hosting

At Entire we thought of a solution: what if we stored and served repositories from full Git hosting systems running in different regions around the world?

Instead of using a European location only to route traffic back to a centralized network, Entire can run the storage and Git services needed to serve a repository directly from Europe. That way, if you are in France, you can choose Europe as your region and let your agents perform more of their work there.

Starting With Mirrored Repositories

To help people transition, we are starting with mirrored repos. We know that moving all your repos, teams, permissions, and workflows to a new platform is inconvenient. I currently have approximately 287 repos myself. (Don’t judge me. I make a lot of demo apps. It’s my job.)

We’re encouraging users to mirror the repos they already have on GitHub to Entire. Mirroring means Entire creates a synchronized copy of your GitHub repo in a region you choose. That copy includes the code, branches, commits, and Git history needed to serve many Git requests.

If my repo is mirrored into Entire’s European region, my agent in France can clone, fetch, search, and read from that European copy instead of making GitHub process every read. This reduces the amount of repetitive agent traffic hitting GitHub.

This transition does have a limitation. GitHub is still the official home of that repository. If my agent pushes to a GitHub backed branch, that write operation still has to go back to GitHub. GitHub still has to accept the push, update the repo, and store the change.

But, we do offer region local branches for mirrored repositories. These branches can stay within Entire instead of being pushed back to GitHub.

So with mirrors, reads can happen through Entire, writes to GitHub backed branches still depend on GitHub, but users can create branches that remain within an Entire region and don’t depend on GitHub.

The Next Step: Native Entire Repositories

Soon, we will roll out native repositories created on Entire with zero dependency on GitHub.

Those repositories will live on Entire’s regional network, allowing agents to read from infrastructure closer to where they are running while writes are handled by the repository’s chosen region. That means agent traffic no longer has to pass through GitHub’s infrastructure. Entire can spread that traffic across its own regions and design the workflow around the speed and volume of coding agents.

The Biggest Step: Decentralization (Not the one you’re thinking of)

Decentralization is a heavy word that carries a lot of baggage from blockchain, crypto, and web3, but decentralization just means: Entire would not have to operate every server that stores and serves repositories.

And Git was designed to be decentralized. Out of convenience, our industry didn’t follow through on that promise, but we have an idea for it.

We envision giving users the option to self host their own nodes. In this case, a node is a server, or group of servers, running the storage and Git services needed to host repos and respond to reads and writes. For example, I could run a node inside my company’s own European cloud account or data center.

That node could become the home location for my repo. My agents in Europe would send writes there. An agent in Australia working on the same repo could also send its writes to “Rizel’s European home node”. Entire would not have to operate the home infrastructure.

This option to self-host is an option; not a mandate. I see this option as ideal for users and organizations that care deeply about data privacy, ownership, security, and control over where their code lives.

As a result, it would also reduce the amount of traffic hitting Entire’s own infrastructure because companies could use their own servers to support their own agents.

Beyond Code Hosting

Entire’s vision goes beyond hosting code. We’re building an ecosystem to help humans and agents actually build together. Months ago, we already released Sessions and Checkpoints, features that track agent sessions. As you make a commit, Entire captures the transcript, tool calls, files changed, and more so you can understand the reasoning behind the code. This is because we don’t often know or remember why an agent made such a huge code change and the diff doesn’t reveal much beyond the lines of code changed.

Many people have asked me: "Why would I want to record my agent’s session history? I’m not going to go back and read it."

However, I’ve found this method helpful because I’m not necessarily reading through the transcript line by line, but I tell my agent to use the agent history to give me answers to questions I have like: why was this decision made. I don’t have to guess why a change happened because I just ask Entire.

But this collection of agent session history is only the foundation for our vision of a semantic reasoning layer directly tied to version control history, giving every agent persistent, shared, and pluggable memory.

The Future of the SDLC

We are participating in a fundamental shift in how software is written. The tools that got us through the last fifteen years of human-only development simply cannot support the next fifteen years of agent-human collaboration.

When you hear me say we are rebuilding "GitHub for the era of agents," it is a shorthand to help you visualize the scale of our vision. We are not literally cloning GitHub. Simply copying pull requests, issues, and wikis onto a new host does not solve the friction of human-agent collaboration.

Instead, Entire is introducing new primitives: building the native infrastructure for an agent-first software development lifecycle.

The agentic era is here. It is time our developer tools caught up.

[Boost]

Rizèl Scarlett — Wed, 08 Jul 2026 14:59:19 +0000

Open-core Git network for 3x larger PRs

Rizèl Scarlett for Entire

Jul 8

A New Developer Platform for Agent-Human Collaboration

#ai #agents #git #entire

5 min read

A New Developer Platform for Agent-Human Collaboration

Rizèl Scarlett — Wed, 08 Jul 2026 14:49:51 +0000

We've entered a new coding paradigm. Agents can now generate full features at a pace that outstrips traditional engineering workflows, but the systems we use to review, understand, and ship software still assume humans wrote every line.

For decades, the software development lifecycle was paced by human comprehension. Teams had time and mental bandwidth to align on implementation, intent, and quality before code reached production.

AI-assisted coding changes that balance. Code generation has accelerated, but the diff still does not carry the reasoning, tradeoffs, or intent that shaped it.

According to data from Cursor, PRs are 3x bigger than they were 18 months ago! Consequently, developers resort to rubber-stamping agent-generated code with little understanding or accountability. As ownership erodes, codebases accumulate hidden risks, and poor-quality software inevitably slips into production.

And human cognition isn't the only system under strain.

As coding agents create more branches, commits, clones, pushes, and automated workflows, today's Git infrastructure is hitting limits it was never designed around. Rate limits, latency, and outages are becoming part of the developer experience.

It's time to rebuild the software development lifecycle for human-to-agent collaboration.

Today we're launching an entirely new Git network, built for agent scale. The Entire Developer Platform is now in public preview: an open-core, agent-agnostic, distributed Git-hosting platform built to restore comprehension, traceability, and intent to how teams review and ship code.

But wait, what is Entire?

Let's take a step back. Entire is a CLI-first system of record that captures the context behind agent-assisted code changes and links it to Git. In other words, whenever you commit changes from your agent, Entire automatically captures:

Your prompts
The agent's response
The full transcript
Files the agent inspected
Tools it ran
Decisions it made

This helps you review, search, share, and continue agent work with confidence. This means if something goes wrong in production, you don't have to say, "I don't know. The agent did it."
For example, Entire allows you to run commands such as:

entire search: search not just your code history, but the prompts and reasoning behind it. "Why did we add this workaround?" is finally an answerable question.
entire blame: like git blame, but for why. Surface the session, prompt, and decision behind any line, not just who last touched it.
entire review: send a branch to multiple agents in parallel and get a review grounded in the actual sessions and intent behind the diff, not just the syntax.
/session handoff: move work from one agent to another with the full session state carried forward, so the new agent doesn't rebuild context from scratch.

We're Launching: An Entirely New Git-Hosting Network

All of that context lives in your repo. But your repo still lives on infrastructure that struggles to support your agents. That's what we're fixing today.

Starting today, you can mirror your public or private GitHub repositories onto Entire's distributed Git network.

Here's how it works: your repo stays on GitHub, and you keep pushing exactly like you do now. Commands like git clone, git fetch, and git push all work exactly as they always have. Behind the scenes, Entire syncs your changes into a read-optimized copy in the region you choose. Your coding agents clone and fetch from that regional Entire mirror, which absorbs the heavy, concurrent read traffic, so they run fast without hitting the origin repo's rate limits. And when we say fast, we mean it.

We benchmarked the network under agent-fleet load patterns, and here's what it sustained:

~570,000 clones per hour from a single repository
586 pushes per second (about 2.1 million per hour)
~470 clone + push operations per second on a single repo, at 50 to 60 ms p50 latency, simulating the real loop agents actually run: clone, push, repeat

We measured all of this with ForgeMark, an open source benchmarking tool we're also releasing today, so you can run the numbers yourself.

How to Mirror Your Repos

# 1. Install the Entire GitHub App: https://github.com/apps/entire

# 2. Install the CLI and log in
curl -fsSL https://entire.io/install.sh | bash
entire login

# 3. Create your mirror (interactive: pick repos, pick regions)
entire repo mirror create

# 4. Clone from your regional mirror
entire repo clone /gh/OWNER/REPO

Under the hood, Entire runs distributed nodes across multiple regions and jurisdictions, with our first active cells in the US, EU, and Australia. You pin your data to the region you choose, reads get served from the cell closest to your agents, and writes are replicated across multiple providers and availability zones so your repos stay available even if a node goes down.

We're rolling users off the waitlist progressively starting today, aiming for full capacity in the coming weeks.

Tune In

Our CEO Thomas Dohmke is speaking at WeAreDevelopers World Congress about why Git hosting needs to change and what we're building next. The talk streams live on Thursday, July 9th at 9:30 am CEST (3:30 am ET for the night owls):

What's Next

This launch is only the beginning of what's to come! Here's what's on the horizon:

Native repos: public and private repositories hosted directly on Entire's network, no GitHub required
Multi-region mirroring for a single repo
Intent-based review: a developer lifecycle where reviewers start with the prompt and the reasoning, not a 500-line diff
Open sourcing more of Entire. (Our CLI is already open source!)
Full decentralization, including self-hosting, so no single company (us included) sits at the center of how the world's software is hosted. We recognize that Git was designed to be decentralized, but we traded that for convenience. We're making a committed effort to build our way back to that original promise without giving up the convenience.

Join the Rebellion

📚 Read the docs to go deeper on mirroring and the CLI
💬 Join our Discord and tell us what works, what breaks, and what you want next
🐦 Follow @EntireHQ for updates as we roll out

And because no launch is complete without him, meet our lovable, sarcastic, robot mascot, Marvin:

Human Attention is a Scarce Resource

Rizèl Scarlett — Mon, 22 Jun 2026 12:20:08 +0000

I recently chatted with a Distinguished Engineer about how he uses agents in his engineering workflow and how he builds new team processes around AI-generated work.

// Detect dark theme var iframe = document.getElementById('tweet-2068069283184144450-994'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2068069283184144450&theme=dark" }

During the conversation, David Fowler made a really poignant take: when producing code becomes trivial, human attention becomes scarce resource. 🤯

You can listen to our full conversation on Spotify. (It's a recording of a Twitter Space I did with him. People have said they really enjoyed the spaces I run, so I saved them as lightly edited podcast episodes).

See below for my own thoughts on code review in the world of agentic coding:

My own thoughts

For decades, software engineering has relied on a foundational necessity: a reliable paper trail. As version control matured from changelogs to CVS to modern Git diffs, we built our craft around durable artifacts that preserve intent, track progress, and safeguard quality.

Historically, this system worked because software development operated at human speed. An engineer reasoned through a problem, committed code, and opened a pull request. Colleagues reviewed that code, engaging in a back-and-forth dialogue to unpack the underlying logic. We deliberately used this collaborative friction to maintain code quality.

But today, a new class of autonomous collaborators has disrupted the traditional engineering workflow.

Coding agents have drastically compressed the implementation window from typing code line-by-line to writing a single prompt that generates a full feature. The most forward facing teams are already moving past single-agent execution, orchestrating parallel sessions where a main agent manages subagents to complete larger bodies of work on demand. (When I worked at Block, this became the way many teams I encountered worked).

This sudden leap in speed is intoxicating, but it threatens to outrun our ability to keep software trustworthy. In practice, an engineer uses an agent to generate hundreds of lines, but the engineer only skims the results. Reviewers facing a growing backlog do the same. If the Git diff looks right, the team ships. Then a production outage occurs. In the past, you could bring the authoring engineer into the incident room to trace their logic and patch the system. But when the decision was made by one of a dozen subagents running in parallel, there is no one to bring in, and the commit history shows only the result, not the reasoning.

This is the central problem I keep seeing in AI-native development: we can now produce code faster than we can understand it. And yet, for an industry obsessed with artifacts, meticulously tracking commits, pull requests, and logs, we often throw away the one record that explains all of them: the agent session itself.

The company I work at, Entire, has been aiming to maintain velocity without sacrificing engineering integrity by preserving agent sessions alongside the tools developers already use. The full chain of AI-assisted work, including prompts, responses, tool calls, subagent activity, checkpoints, and the final commit, can all become part of the engineering context. The mechanics do not have to be heavy. We do this using lightweight hooks around the agent and Git workflow.

But the purpose of capturing session history is not for users to simply reread a diary of logs and transcripts. (A lot of people tell me, "So what, I don't want to read the logs!") Instead, session history can become an active surface for understanding, unlocking capabilities that standard Git diffs simply cannot support.

When an engineer or agent needs to understand a complex block of autonomous code, the investigation should not stop at a timestamp, a commit hash, or a best guess. I want to be able to ask why this implementation exists, what prompt produced it, which agent or subagent touched it, and what validation or review context shaped the final result.

If we want to build at this new speed without losing our grip on the codebase, a static diff of the final code is no longer enough. When the system breaks at 2:00 AM, we cannot rely only on tools built for a human pace to audit agent-to-human collaboration. To keep our systems reliable, we have to preserve more of the actual narrative of how the software came to be.

Because in an AI-native world, the session is the story.

Check us out on entire.io !

And check out this episode of a crazy time I was on an AI coding game show for CodeTV . I look back at this episode many times, and just think "Ugh, we should've used Entire. It would've made handing off work between my team so much easier."

How I Added Goose as an External Agent to Entire

Rizèl Scarlett — Thu, 11 Jun 2026 19:13:21 +0000

I just opened a PR to add support for Goose to Entire. Goose is an open source coding agent under the Agentic AI Foundation, the first ever MCP client, and a reference implementation for the Model Context Protocol. I am super excited about this because it is exactly where my two worlds collide. I previously worked on the team building out Goose. Although I left the team to join Entire, I still maintain the Goose documentation and stay semi-active in the project.

This post walks through how I built the integration. It also doubles as a guide for adding support for your own favorite agent to Entire.

What is Entire?

The traditional software development lifecycle was not built for AI agents, so Entire is building the one that is. We identified major friction points that make it hard for humans and agents to collaborate. For example, agents often put up massive PRs that human developers simply do not want to review. Additionally, you completely lose the reasoning behind AI-generated code days after it gets merged because no human actually wrote it.

We have much more coming down the road, but we started by launching a CLI-first tool that records your agent sessions. It logs the prompts, the agent responses, tool calls, and everything in between.

That way, when you want to find out why a feature was implemented a certain way, you can go straight to the transcript and read through it .Personally, I prefer to either ask my agent or run a command like entire checkpoint explain to get a summarized rundown of the exact conversation behind a line of code. All sessions get version controlled via git and live on a dedicated metadata branch within the same repo.

Why add your own agent?

Entire ships with built-in support for leading coding agents like Claude Code, Gemini CLI, Codex, Cursor, and Copilot CLI. But the agent ecosystem moves incredibly fast, and no single team can support every new tool that drops.

So, we built the external agent protocol that allows you self-serve add support for any agent you prefer to Entire. It gives you a completely self-serve way to add support for any agent you prefer. The user experience is identical to using a built-in agent. All the exact same commands and functionality just work. If Entire doesn't support your favorite agent yet, you don't have to wait on us. You can build the integration yourself directly in the entireio/external-agents repo.

Why Goose?

As a maintainer and former full-time developer on Goose, I've been looking for the perfect excuse to wire it up to Entire. The main technical blocker was that Goose didn’t support hooks. Hooks inform Entire when a session starts, when a user submits a prompt, and when the agent finishes a turn. This allows Entire to know when to start and stop recording the session activity.

Recently Goose implemented support for hooks, following the Open Plugins hooks spec, so now I could fulfill my dream.

What your agent needs

To wire your agent up to Entire, it needs to have the following:

A hooks or lifecycle mechanism: You need a reliable way to run an external command when a session starts, a prompt is submitted, or a turn ends. Without this, Entire cannot observe the session.
Readable session data: You need access to transcripts or an exportable session store containing the actual conversation. We need real assistant responses and precise tool calls, not generic placeholder text like "Working...".
Stable session identity: A consistent session ID that you can extract from hook payloads, ideally paired with a resume command (like goose session --resume --session-id <id>).
A non-interactive CLI mode: Running commands cleanly (for example, goose run -t "prompt") makes writing automated lifecycle tests dramatically easier.

What you need

You also need the following items on your device:

Your target agent’s CLI install and authenticated
Entire CLI installed
Go toolchain because external agents for Entire are written in Go.
Open an issue first to get alignment with the team at Entire requesting that you want to add this agent. Introducing a new agent means a long-term support commitment for us!
Optional: An agent that you would use to implement this integration. I used Claude Code with Fable 5. This way, I didn’t have to manually write all the code. Claude Code just followed the pattern to integrate Goose with Entire.

The step-by-step workflow

1. Run the Agent skill

The external-agents repo includes a built-in developer skill that automates the heavy lifting: entire-external-agent. Clone the repository, open it up in your favorite AI development tool, and run:

/entire-external-agent

2. The three development phases

Phase 1: Research - The skill analyzes the protocol spec, probes your agent's binary commands, and, crucially, writes a verification script to capture real hook payloads.

For Goose, this script wired a capture plugin into a temporary workspace, executed a real goose run prompt, and dumped the exact stdin payloads to disk. Documentation can lie, but captured payloads never do. This phase also ensures the session data is clean and stores everything in an AGENT.md summary file.

This phase revealed that Goose sessions live in a global SQLite database rather than isolated files, meaning our binary had to materialize transcripts on the fly using goose session export --format json.

Phase 2: Write tests - The skill scaffolds a fresh Go binary that stubs out the required protocol subcommands with valid JSON shapes. It registers your agent in our end-to-end testing harness. At this point, the shared compliance suite (entireio/external-agents-tests) is supposed to fail. Those specific failures become your exact development roadmap.

Phase 3 - Implement - Now that we (you and the agent implementing the integration) have specific test failures, your agent can use a test-driven development approach to identify the code needed for this to work. It can take those failures and write the code to fix them step by step. For Goose, the failing tests pulled the agent through hook installation, session read and write round trips, and transcript validation. Finally, the agent writes unit tests using the actual data it recorded back in Phase 1 to prove its translation code works perfectly.

When Entire first discovers your integration, it does a quick programmatic handshake to ask, "What features do you (the target external agent) actually support?" Your external agent binary (mine was Goose in this case) answers by declaring its capabitilies. This list tells Entire exactly what tasks it is allowed to hand off to your agent.

Here are the specific capabilities Goose declared:

hooks: Tells Entire that the binary can use Goose's native plugin system to listen for session events.
transcript_analyzer: Tells Entire that the binary can read the raw JSON data to find the user's prompts, the tool calls, and the files that were changed.
transcript_preparer: Tells Entire that the binary knows how to pull the conversation history directly out of the local SQLite database.
token_calculator: Tells Entire that the binary can track the total AI tokens used during the session.
compact_transcript: Tells Entire that the binary can clean up the raw conversation formatting so it looks readable when you run entire checkpoint explain.

The test harness (in my case Claude Code) automatically runs your new binary (Goose now integrated with Entire) through protocol compliance checks, live LLM prompt scenarios, and session persistence validation to ensure everything works perfectly.

4. Open your PR

Before putting up a pull request, remember to open an issue first to get alignment with the maintainers. Introducing a new agent means a long-term support commitment for the repository. Once aligned, push your branch and open the PR. Our CI pipeline will automatically compile your binary, run the compliance suite, and verify your unit tests.

Check for additional bugs

After the agent skill finished running, I tested the integration myself.

I ran the following command in a repo I didn’t care about:

entire enable --agent goose

Then, I prompted goose to make some file changes, commit, and push. I found one bug where it wasn’t generating the full session transcript, and it only generated the first user prompt. I had Claude Code survey past agent integrations to look for patterns and identify what was missing. I added those fixes to my PR, and then I was done!

It felt lightweight because Claude Code did all the heavy lifting.

Now, I have to wait and see if my teammates approve my PR.

Resources

There’s some more resources from us about agent hooks and adding external agents:

Hang out with us!

You can find the Entire crew here:

And we’ll be at We Are Developers Berlin this July 2026. See you soon!

How to Make Coding Agents Remember Past Solutions

Rizèl Scarlett — Wed, 10 Jun 2026 21:40:59 +0000

Some engineering problems are only painful because they happen so rarely. Even with a coding agent, the frustration still feels the same. I’ll wrestle with a tool that isn't my daily driver, hit a wall of errors, finally find a resolution, and then I neglect to note the solution because the problem is "fixed."

This happened to me recently with a custom, internal GitHub Actions workflow I use for a post-release DevRel task. To make it work, I need to pass a specific authentication token to run Entire in a headless mode.

A couple of months ago, I sat down with my AI agent to configure this for the first time. Because Entire is new and our setup is completely undocumented, it took a grueling trial-and-error process to figure out how to generate the token via a local device-flow login.

Eventually, we found the answer. I pasted the token into my GitHub secrets, the workflow turned green, and I went about my day without writing anything down. I rarely take notes now that I use coding agents, but it’s not a sustainable practice. I need something to take note of the resolution (even if it’s my agent).

Today, when the token expired, I was back at square one.

Why I Didn’t Make a Skill

Normally, my instinct is to automate repetitive tasks by building a reusable workflow, like an Agent skill or a goose recipe. But a dedicated skill didn't make sense here:

Low Frequency: This happens once every few months. Writing and maintaining code for a skill I barely use is textbook over-engineering.
Security & Context: Generating an auth token involves sensitive device flows. I didn’t want a generic token-generation script floating around in my global automation suite.

I wished my agent had a memory, so I could ask “How did we get that GENERIC_ENTIRE_TOKEN last time?" and have it recall the context.

Instead, I spent an hour re-debugging a problem I had already solved. It was just my agent and me making guesses.

To break the loop before the next expiration, I decided to use Entire. (At the moment, I was literally working in Entire’s repos. I work for Entire, and I’m like okay this is the perfect use case).

What is Entire?

Entire is a tool for preserving the context behind software work.

When you work with coding agents, a lot of important information lives outside the final diff: the prompt you gave, the dead ends the agent tried, the commands it ran, the reason a change was made, and the little debugging discoveries that never make it into code comments.

Entire captures that session history and connects it to your git history. So instead of only seeing a generic commit message like:

docs: note dispatch auth refresh process

You can also recover the agent session that led to that commit and find the answer to questions like:

what problem you and the agent solved,
what files you and the agent touched inspected,
what scenarios you and the agent ruled out,
what was the final fix

Using my session history as an artifact

Unfortunately, my agent could remember the solution from two months ago because Entire connects agent sessions to commits.

When I fixed the problem the first time, I hadn't changed any code. I just asked my agent a question and it responded with an answer. This meant I didn’ commit. Because there was no commit, there was no permanent record or session transcript for my agent to review.

So today, after solving the problem a second time, I decided to leave a breadcrumb.

I created a small markdown file in the repo. I didn't want to document the exact terminal commands step-by-step, nor did I want to risk exposing a security vulnerability by pasting sensitive outputs or token patterns into a file. I needed to document the process, not leak the credential.

I checked in a minimalist note that looked like this:

# Workflow Token Refresh

If this workflow fails because its token is missing, blank, or rejected, refresh the the token using the flow captured in the session history for this commit.

Here’s how my agent responded

Now, I wanted to test if this theory would actually work in the future. I asked my agent the following question:

how do i get the GENERIC_ENTIRE_TOKEN?
in my github action workflow it says that token is expired

This triggered my agent to run a skill called using-entire. This skill is an orchestrator built for codebase exploration and tracking down "why did we do this?" questions. Its core instruction is simple: read the repository's recorded session history before guessing from raw code.

Here is the exact step-by-step trace of what the agent did autonomously behind the scenes to find the answer:

First, the agent ran a quick status check to see if Entire was active in the local project workspace.

entire status

The agent scanned the codebase for the search keywords from my prompt and successfully located the markdown file I checked in earlier.

docs/runbooks/dispatch-workflow-auth-refresh.md

Once it found the file, my agent checked the git commit history of that file to find the associated Entire Checkpoint.

git log --format='%H %b' -5 -- docs/runbooks/dispatch-workflow-auth-refresh.md | grep -B1 'Entire-Checkpoint:'

This command allows the agent to extract the unique session identifier tied directly to the commit:

Entire-Checkpoint: f3aaa4d4eafd

This checkpoint hash acts as a permanent anchor, linking the codebase straight back to the exact historical session transcript where we originally solved the problem.

With the checkpoint ID secured, the agent called Entire's explanation tools to pull the history.

entire explain --checkpoint f3aaa4d4eafd --transcript

Once the transcript streamed in, the agent scanned the text for relevant authentication phrases like oauth/device/code, and oauth/token.
Because the agent successfully dug up that historical context, it handed me the exact commands I should run to retrieve the token and add it to my GitHub Actions secrets.

By committing a file to the repo, I forced Entire to generate a permanent session history for that specific commit.

A new approach to institutional knowledge

The first time I used an agent memory tool in mid-2025, it was essentially a manual knowledge graph. It remembered what I explicitly told it to remember, and retrieved it on command.

But I don’t want to manually prompt an agent to remember a scenario. I often lack the hindsight to know what information I will need down the road. This is why Entire’s background recording is so valuable. By automatically saving session transcripts, it transforms raw developer activity into a retrievable artifact that your agent can tap into at any time.

Just a few years ago, every company valued that one engineer who knew everything, holding the context that code alone couldn't capture: the background of architectural decisions, stakeholder trade-offs, and historical workarounds.

We used to have to track that person down for answers. Now, we can query agents instead. But to do that effectively, we must equip them with the right context regarding troubleshooting steps and past failures.

Capturing our agent sessions and version controlling them ensures this rich decision history becomes a live, permanent part of the project repository.

The #1 Developer Skill in the Agentic Era

Rizèl Scarlett — Tue, 02 Jun 2026 23:12:42 +0000

At first, many dismissed AI as a temporary bubble, but now that engineering organizations are adopting agentic workflows at scale, it is much harder to negate this new reality. Naturally, this shift has triggered a wave of industry anxiety. Engineers are looking at the landscape and asking a frantic question: What skills do I need to keep my job?

For decades, developers prided themselves on memorizing syntax, writing algorithms from scratch, and passing LeetCode interviews by repeating patterns. The pivots we made in the past were typically centered around the framework of the week (especially in the JavaScript world). Switching frameworks only required relying on the strong foundational software engineering skills picked up at school, in a coding bootcamp, or even from a YouTube video. But now that AI agents can produce code in seconds, developer egos are crumbling.

In pursuit of relevance, developers have to sift through the noise of industry influencers pushing various strategies: Agent Skills, MCP, Gas Town, or building custom agents from scratch. Yet every one of these strategies boils down to a single foundation. That same foundation remains the number one skill for developers today, just as it was before the AI boom: communication.

The Value of Communication in Software Engineering

Code alone does not make a great developer. When coupled with strong communication skills, it becomes a distinct competitive advantage. However, we often overlook these skills because our industry excuses poor communication, hiding behind the stereotype that software engineering is an isolated job for people who just want to avoid human interaction.

Early in my career as a junior software engineer, I struggled. It was not due to technical aptitude; instead, I simply struggled to verbalize my thoughts well. For example, when I was stuck on a problem, I didn’t understand how to ask for help. I would write essay-length questions on Slack, burying my actual problem in a mountain of unnecessary context, or I wouldnt provide enough information at all. Either way, my teammates werent motivated to help me because they didn’t understand what I was trying to say.

I finally made progress in my career when I learned how to communicate with clarity. That realization eventually propelled me out of junior loops and into senior leadership roles in developer advocacy, where communication is the core focus.

This requirement is evident in the way our industry identifies talent. In technical interviews, the engineers who get hired are the ones who vocalize their reasoning, explain their trade-offs, and talk through their strategy as they adapt to new constraints. The candidates who pass are rarely the ones who silently type out a perfect linked list.

The Need for Communication in the Agentic Era

// Detect dark theme var iframe = document.getElementById('tweet-2060553984947950017-414'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2060553984947950017&theme=dark" }

Coding agents have increased the need for clear communication. To have a successful session with an agent, you must be able to clearly express your intent. I find that when engineers claim coding agents are hard to use, unreliable, or hallucinate too much, or when they rely too heavily on overly complex workflows to guide an agent through a codebase, their communication skills often need improvement.

Methods like context engineering, planning, and leveraging Skills are simply different user experiences designed to help engineers better communicate with their agents. For example, while you can create a plan with an agent before starting work, using a command like /plan ensures you provide the right details upfront and saves an artifact of that plan in a markdown file.

Orchestration Makes Communication Less Visible

As agent harnesses and models improve, and as executive leaders demand more output, engineers are getting creative to work faster. One common solution is orchestration. In practice, this means you act as a manager of multiple agents working simultaneously, even while you sleep, and you simply review the output at the end.

AI engineering leaders are starting to point out the trade-offs of this approach. @addyosmani wrote an article about it titled The Orchestration Tax.

// Detect dark theme var iframe = document.getElementById('tweet-2059844244907696186-109'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2059844244907696186&theme=dark" }

While your agents might produce a massive amount of work, you now have to review a mountain of output. My main issue with this setup is that the underlying reasoning behind the output often gets lost.

Treat Agent Sessions as Engineering Artifacts

// Detect dark theme var iframe = document.getElementById('tweet-2061159078479663601-61'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2061159078479663601&theme=dark" }

To solve this, we have to start treating agent sessions as durable engineering artifacts. Just like we use version control for our lines of code, we need an audit trail for our agent interactions. You should be able to go back and view the transcripts, the prompts, the tool calls, and the trade-offs an agent made, giving you the context you need to answer for your architectural decisions.

This is one of the many tools my team is building at Entire. We wanted to create that missing track record for agentic workflows. Now, if I open a commit from last week and see a vague message like fixed, I dont have to wonder what happened. I can run a simple command like:

entire checkpoint explain

Entire then surfaces what was asked, what files changed, what the agent reported back, and which commit it belonged to. It is incredibly useful because I can even ask my agent to look at those tracked sessions to help me better understand and expand on the context. This allows me to keep honing my communication skills and progressing as an engineer.

A Real Example

Ill be vulnerable. Yesterday, I published a blog post on our company website. While the tests for the blog post passed in staging, when I merged it to production, it failed to deploy because of a failing Cloudflare test. I worked with my coding agent to diagnose the problem, and then I learned I had to revert a PR from the Head of Design Engineering where he had bumped our Node version up. Someone approved my PR to revert his code, and I merged it. I did this without him knowing because we are in different time zones. However, I anticipated that the next morning, he would want to know why I reverted his code, and I needed to be able to explain myself.

The problem was that I do not have direct access to Cloudflare since I am not on the core engineering team. I didnt fully understand why he made his original PR, or exactly how my deployment broke it. So, I spent a lot of time asking my agent what happened, why it happened, and how I could fix it. I knew that by the next morning, I would probably forget some of the major details, especially since a lot of the troubleshooting happened at 10 p.m.

But I used Entire to help remind me. First, I ran a simple terminal command:

bashentire checkpoint list

This command surfaces a clean snapshot of my history, giving me a list of various checkpoints and commits from my session with the agent.

Normally, I would choose a specific checkpoint from that list and run entire checkpoint explain to get an explanation for each individual moment. But because there were so many checkpoints, I wanted to fast-track the process instead of digging through them one by one.

Fortunately, I have agent skills installed that teach my agent how to interact with Entire commands and execute custom workflows. I handed the agent that same screenshot of my checkpoint list and gave it a simple prompt: Can I get an explanation of each of these checkpoints?

My agent responded by explaining the decisions from beginning to end, covering my initial workaround attempts, how I got confused with the version numbers, and how we finally identified a fix, so the next day I would be able to respond to my coworker.

How to Keep Improving Your Communication Skills

Use agents daily: This one is simple. The more you use agents, the more you will understand how to use them and how to communicate with them. Over time, you will build your own personal workflows that ensure you get the best outcome. It can be a bit of a learning curve at first, but after constant use, you will get a hang of it.
Watch others work: Through reading blog posts, watching livestreams, or even reading my teammates past agent history, I learn a lot about how they operate agents, and I can adapt different parts to my own workflow.
Own the outcome: Never ship code you cannot explain to a human peer. If your agent makes a sweeping change across ten files, trace its steps, audit its intent, and ensure you completely understand the reasoning behind those lines before hitting approve.
Track your agent sessions: Let Entire track your sessions behind the scenes. When you find yourself in a moment where you need durable artifacts because someone is asking what happened and why, you will be fully prepared to communicate it.

It’s a strange world. The best engineers are no longer defined by how well they memorize syntax. At first, the developers who stand out will be the ones who work the fastest, spinning up multiple subagents and impressing everyone with their raw speed.

But very soon, the most valuable engineers will be the ones who can bring clarity back to the humans on their team. When a system inevitably breaks down, they will be the ones who can look back at their sessions, trace exactly what the agents did, and explain the choices to their team.

Code is cheap, but clarity is getting more expensive.

You can get that clarity today with Entire.

Resources:

Website: entire.io
Documentation: docs.entire.io
Discord community: https://discord.gg/jyAENMgmb3