Forem: Entire

How to Keep Entire Checkpoints Separate from Your Code

Rizèl Scarlett — Fri, 08 May 2026 08:02:39 +0000

Storing a record of your agent sessions solves the biggest friction point for developers: limited context. On the surface, this may look like a dormant log, but Entire transforms those records into procedural memory. By default, the Entire CLI stores your agent history right alongside your code. More specifically, it stores your checkpoints, snapshots of your prompts, agent transcripts, and the state of your work at each step, on a dedicated branch in the same repository called entire/checkpoints/v1.

But as valuable as that memory is, it raises a valid question: What if I don’t want anyone else to see the conversations I have with my agent?

We’ve heard a few consistent reasons why developers want to keep their agent history private:

The conversations are, frankly, a little embarrassing. (I’ve yelled at my agents before. I am not proud of it, but when tokens are few, so is my patience).
It can start to feel like surveillance from their employer.
It's a privacy concern. Those conversations might include context their company doesn't want to share publicly or with external collaborators.
They want to keep your main repo lean and focused on source code.

If any of those reasons resonate, you have two main paths to a more private workflow.

Push checkpoints to a separate private repo

This is the sweet spot if you’re working on a public or shared project but still want a history that you (and maybe your trusted teammates) can access.

1. Create a private repo for your checkpoints

On GitHub, create an empty private repo with any name you want. In this example, we’ll use myorg/checkpoints-private. This is where all your agent sessions will live. You don't need to add a README or initialize it. Entire will push the first checkpoint branch on its own.

2. Point Entire at the new repo.

From inside your project, run:

entire configure --checkpoint-remote github:myorg/checkpoints-private

The format is provider:owner/repo. Today, github is the supported provider. This writes the setting to .entire/settings.json under strategy_options.checkpoint_remote:

{
  "strategy_options": {
    "checkpoint_remote": {
      "provider": "github",
      "repo": "myorg/checkpoints-private"
    }
  }
}

Now, your code will be stored in your main repo, and your agent sessions will go to your new private repo. You can read more about this in the Checkpoint Remote docs.

Keep your agent sessions local

If you want the highest level of privacy, you can keep your agent sessions local and opt out of pushing them to remote using the following command:

entire configure --skip-push-sessions

This modifies .entire/settings.json with the following values:

{
  "strategy_options": {
    "push_sessions": false
  }
}

This setting still allows you to store your sessions locally. For example, you can still rewind, look back at what happened, and use all the local features. However, because the checkpoints never get pushed to GitHub or any remote provider, you cannot retrieve them if you switch devices. Also, your teammates won’t have access to your checkpoints.

What if I accidentally paste a secret?

We know that mistakes happen, so we have guardrails in place. Whether you store your history alongside your code, in a private repo, or on your local machine, Entire runs every session through a redaction pipeline before it hits git.

We use Betterleaks to automatically scrub:

Cloud credentials (AWS, GCP, Azure)
Source control tokens (GitHub, GitLab, Bitbucket)
Service keys (Stripe, Slack, Discord, Twilio)
Private keys (RSA, SSH, PGP)
Database connection strings with embedded passwords
Bearer tokens, JWTs, and high-entropy strings that look secret-shaped even if they don't match a known pattern

TLDR; Which one should you pick?

The Goal	The Command	Where data lives
Full Visibility	Default	Same repo as your code
Private Collaboration	`--checkpoint-remote`	A separate private repo
Total Isolation	`--skip-push-sessions`	Your local machine only

Note: Redaction runs across all three. Whether your checkpoints live in your code repo, a private repo, or only on your laptop, secrets get scrubbed before they're written.

Conclusion

We recognize that your agent workflow is going to look different based on who you are, the codebase you're in, and your team's unique security needs. Entire is built to adapt to those needs.

Ready to dive deeper into configuring your setup? Check out our documentation on checkpoint remote and Security & Privacy docs.

In the comments section, let me know: Do you even care if people see your agent history, or would you rather keep those transcripts private?

Turning Agent History into Procedural Memory

Rizèl Scarlett — Sun, 03 May 2026 23:40:08 +0000

For about a year, my primary coding agent was goose. Since I worked at Block and served as a Developer Advocate for the project, I was deeply embedded in its ecosystem. I contributed code and provided product feedback that shaped how it functioned.

Then, I moved to a company called Entire that provides the infrastructure for the agentic software development lifecycle. To do my job well, I have to dogfood our product across the agentic ecosystem. This means I am constantly switching between Claude Code, Codex, and other agents that support hooks to contribute to docs, investigate and resolve bugs, understand new features, and produce content.

Switching between AI agents made me realize every agent has tradeoffs. Some are faster or more polished, but I find myself deeply missing a specific goose feature called recipes.

The Problem with Operational Glue

Recipes are reusable, shareable workflows. At the core, they are YAML files that describe a process you want goose to run again. You can write the YAML files manually, but I always preferred the magic of clicking a button to package a successful session into a recipe.

My work in Developer Relations is creative, but it’s built on repeatable systems. For example, writing a blog post, building a code demo, creating a video are creative. The publishing process is not. Publishing a blog post involves a series of tiny, forgettable steps: checking the folder structure, adding the correct front matter, wiring up the metadata, dropping the image in the right asset folder, opening the PR. Each of these steps take a few minutes, but those minutes add up and become hours of operational glue. At Block, I automated as much of that as possible. I had goose generating release notes in CI/CD and creating documentation tickets in Asana. Some of these ran on a schedule, others I triggered manually. The point was always the same: if I found myself explaining a process to an agent more than once, it was an operational smell that needed to become a reusable asset.

While my use cases focus on content and community, this pattern is universal. In many fields, employees find themselves frequently explaining the same sequence to an agent, so why not automate this into repeatable workflows?

For engineers, those repeated conversations may look like:

Upgrading a dependency safely
Bootstrapping a new microservice
Triaging a production error
Writing a design doc or RFC
Preparing a release PR

The inputs and thinking may vary, but the process: conventions, the file paths, the validation steps, the commands you run, the people you always notify stay the same. And this level of automation is necessary today where employers are demanding more output.

The System of Record

I'm constantly jumping between different agents. Each one has its own process for automating workflows, but none of the automation tools hit the mark for me like goose did. While I don’t have access to my treasured repeatable workflows anymore, I do have access to the unique and valuable agent session data that Entire collects. Entire is a CLI-first system of record for agent-assisted development. It captures the context behind your work: the sessions, prompts, responses, tool calls, file changes, and Checkpoints. A Checkpoint is a specific moment where work is tied back to git. It connects the "why" of the agent session to the "what" of the final commit.

I realized this data isn't just for review, audit, or to sit quietly in the background. It's a source of truth that can be used for building better workflows. I thought, “What if I could use my Entire session history to recreate that ‘package up a session’ magic, but in a way that works across any agent, and works retrospectively?”

The most popular way people are currently building reusable workflows is with Skills, so I built an orchestrator skill called Session-to-Skill. It creates Skills for me based on repeated behavior.

The Before and After

Before I used to say:

“Look at past blog posts in this repo, check the folder structure, and the front matter.”
“I want to add a new blog post. Here’s the content: [insert content copied from google doc here] ”
“Create a new PR. Make sure we’ve pulled the latest from main and branch off main before you create this PR.”
“Why did you make the word Checkpoints lowercase when I purposely had them capitalized? Please restore that.”
“Does the OG image work? What’s the path for me to check that again?”

Now, I can say:

“Create a blog post from this content [insert content copied from google doc here].”

This is possible because I prompted my agent to use the Session-to-Skill Skill: "Look at my past sessions where I set up blog posts. Find the repeated steps and conventions, then draft a Skill from that data, so I can create blog posts quickly in the future." My agent created a Skill called Create-blog, which included requirements to properly format the blog, open a PR, and return the path to confirm the OG image rendered.

Well, that’s kind of dumb..

Some may have pushback on this idea of me building an orchestrator Skill because at any moment in a session you can prompt any agent to turn it into a Skill.

The reality is I don’t have perfect foresight. Most reusable workflows are recognized later. After the third time I publish a blog post, I realize I have been doing the same thing over and over again. By then, the valuable evidence is spread across past sessions.

There is also the issue of quality. Asking an agent to summarize a transcript often leads to overfitting and noise. The resulting Skill might include accidental details, temporary file paths, or one-off preferences that happened to be present in that single session.

Instead my Skill is extracting the answers to the following questions:

What was the reusable behavior?
What should a future agent know before attempting this again?

I don't have to remember the session ID from six weeks ago. I just know the work happened. The Skill uses Entire to search my session metadata, checkpoints, and explanations of prior work to find the durable pattern.

Procedural Memory as Infrastructure

My approach creates procedural memory for agents. Procedural memory is the answer to the question, "How do I do this kind of work well, here, in this repo, with this team?"

Daily engineering work is not net-new. You may receive a new ticket, but somebody has solved this problem before.

By using Entire's data to generate Skills, I get a layer of determinism and portability. The agent starts with a template based on real work rather than a generic prompt. It encodes patterns that have already succeeded. And because Skills are portable files, I can take my blog-publishing Skill from Claude Code to Codex without re-explaining my workflow and share it with teammates.

With all this said, I want to urge readers to stop treating our agent sessions as disposable and start turning our history into our infrastructure.

Check out Entire at entire.io

I Don’t Make Slides Anymore. My Agent and Entire Do It for Me.

Rizèl Scarlett — Sat, 25 Apr 2026 17:00:18 +0000

Signing up to speak at conferences is fun until the conference date starts approaching and you realize you still have to write and practice your talk. For me, writing the talk isn't the hard part. I have a process of talking to myself on a peaceful walk (or even in the shower), recording my voice, and then inserting the demos afterward. The part I often procrastinate is making the slides. Creating slides used to be fun, but as I’ve grown my career and my family, it's no longer a good use of my time.

I've looked for a way to automate slide generation, but most options have been fragile. They generally struggle with formatting and taste. However, a few months ago, some of my teammates at Block discovered the frontend slides skill and introduced me to it. This skill enables agents to build out HTML presentation decks that can be exported as PDFs or PowerPoint presentations.

Agent Skills

If you're not familiar, agent skills are markdown files that provide instructions for the agent to understand how to use a tool (i.e., a CLI or an MCP server). This way, your agent immediately knows what commands to run and how to navigate the tooling when you make a request.

How I Use the Frontend Slides Skill

As I mentioned, I already have my talk transcribed, which gives me a talk track to follow. I typically give the transcript to an agent and ask if there are any parts that don't make sense or any gaps for the audience.

Once the talk track is polished, I give the copy to my agent and prompt it to use the frontend slides skill to build a deck based on the track. I prefer to use Claude Code for this task, as it seems to work really well with the frontend slides skill, but any agent that supports skills should work. The agent then produces a beautiful slide deck for me. It really doesn't look bad or overly generic at all. It has various themes to choose from, and since it's generated with HTML, CSS, and JavaScript, I can prompt my agent to edit parts like making the font bigger, changing colors, and so on.

Here's an example:

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

My favorite thing to add is a presenter view. It doesn't generate that view by default, but I do like to take a peek at my notes as I speak. So I usually tell my agent to implement that view if I press a key like the letter "P," and I make sure it syncs with what everyone else can see. Then, I upload my deck to GitHub Pages. Goodbye, Canva, PowerPoint, and Google Slides.

How Entire Enhanced My Workflow

Let me rewind for a second and introduce you to Entire. Entire is the company I work for. We're building the next developer platform for the AI-native software development lifecycle. The team recognized that agents have changed our workflows, so the infrastructure we use should change too.

Our first tool is a CLI that captures prompts, agent responses, tool calls, and other session data from the work you do with an agent. That gives you a way to inspect what happened, rewind work from a past session, and stay accountable. For example, if a production outage ever happens, instead of saying, "Oh, the root cause is that my agent did it," you can actually track the decisions made between the agent and the person prompting it. I described this to someone at a conference the other day, and they boiled it down to version control for agentic work, which is honestly exactly what it feels like.

Now, it took me a while to see how Entire could make my workflow even better, but the founders opened my eyes. I can use Entire while I'm building out a demo and then use that captured work to help build the slide deck later. Entire has a command called entire dispatch. It generates a markdown summary of the work Entire captured between you and your agent in a repository.

For example, after experimenting with OCR in a repo, Entire generated this dispatch summary for me:

# Dispatch: blackgirlbytes/pretext-handwriting-demo

Shipped a full handwriting recognition demo built on Pretext, moving from  
initial scaffolding to a polished scrapbook composition surface within a  
single day.

## blackgirlbytes/pretext-handwriting-demo

### Handwriting Recognition

• Built draw-mode handwriting recognition as the core interaction surface.  
• Added image upload as a second recognition path alongside the drawing  
canvas.  
• Implemented auto-recognition after drawing completes, removing the manual  
trigger step.  
• Added camera mode to round out the three input methods.  
• Removed the explicit draw button to streamline the input UX.

### Scrapbook Composition Surface

• Introduced a scrapbook composition surface for arranging recognized text  
and shapes.  
• Integrated Pretext to handle obstacle-aware text flow around placed shapes.  
• Added animated motion layer to the scrapbook background.  
• Added resize handles to scrapbook shapes for direct manipulation.  
• Matched scrapbook background typography to the handwriter component for  
visual consistency.  
• Moved scrapbook controls into the composition header to consolidate the  
toolbar.  
• Fixed scrapbook layout and output tab rendering, then simplified and  
tightened tab spacing across multiple passes.  
• Corrected background line wrapping and ensured background renders before  
shapes are placed.

### API Key & Session Management

• Added session-based OpenAI key setup to avoid requiring environment-level  
configuration.  
• Hardened API key gate interactions to handle edge cases more reliably.  
• Added environment key setup path as an alternative to session entry.

### Documentation

• Added project agent working rules and intent guidance early in the commit  
sequence.  
• Documented project setup and architecture in the README.  
• Refined and clarified the README project description across two follow-up  
commits.

All core features landed on main on April 1, 2026; the repo is in a  
reviewable state.

That's helpful for me because building a demo usually takes a few days. I'll leave it, come back to it later, and then have to remember what I actually did, what mattered most, and which technical details are worth calling out. Instead of trying to reconstruct all of that from memory, I can use the dispatch summary, give it back to the agent, and ask it to make a strong slide that captures the main technical highlights of the demo. That saves me from having to recall every step I took days or even weeks later.

Beyond DevRel

My particular use case works best for folks in Developer Relations or folks who do DevRel-related work like conference speaking, but this can actually work well for various roles. Here are a few:

Developers demoing completed features to their team. My husband is a developer, and he's expressed that building the slide deck is time-consuming just to show off a feature he built to his team.
Hackathon participants demoing their project to judges. Presentation decks often get neglected because everyone is focused on building the actual project during a small window of time.
Solutions engineers or sales engineers preparing customer demos. A lot of time goes into building out the demo environment itself, so having help turning that work into a clear deck can save a lot of time.
Workshop instructors or developer educators teaching technical material. It can be useful to turn the work captured while building the demo or sample app into slides that explain the flow, architecture, or key takeaways.
Engineering managers or tech leads giving project updates. Sometimes the hard part is not the work itself, but summarizing what happened clearly enough for leadership or cross-functional teams.
Founders or indie hackers pitching what they built. When you are moving quickly, the last thing you want is to spend hours making slides after already doing the hard part of building the product.

I don’t believe in automating things that deserve a human touch, but I do believe in automating things so I can spend more time with humans. The slides skill has been great for me, but adding Entire to this workflow has made it even easier for me to do that.

Much of my previous work with GitHub and Block (goose) was focused on using agents to build faster. Recently joining the team at Entire has pushed me to think more about the next layer: making agentic work durable and accountable.

Building fast with agents is fun, but in practice, I also need to be able to understand what happened, pick work back up later, explain it to other people, and turn it into something useful beyond the moment it was created. I’ll be sharing more of my agent-native workflows as I continue experimenting.

If you want to learn more about Entire, check out our:

And follow me!