This post is part of our series on how C1 is building the agentic enterprise internally.
Every developer has a pet environment. A long-lived dev instance they've cared for, carefully configured, fixed when it breaks, restarted when it drifts. It works. Until it doesn't. Until it's three weeks behind main. Until someone asks "can you repro this?" and the answer is "not on my machine."
We decided to stop keeping pets. We started raising cattle.
What Squire actually is#
Squire is an agent-first ephemeral development environment. Every Squire instance consists of a fully-functioning app with a 24/7 AI agent running on it, waiting for work. You spin one up, point an agent at a problem, and let it go. When the work is done, the environment goes away.
No drift. No "works on my machine." No environment that's been alive so long it has its own personality.
The shift here is subtle but important. Traditional dev environments exist for humans to sit inside and write code. Squire environments exist for agents to operate in. Humans can observe, review, and steer, even write some code, if they really have to. But the default operator is the agent. Now that we've built the agentic conveyor belt, the software factory comes to life.
Software Factory — The workflow engine#
An agent with a fresh environment still needs to know what to do. Level 0 is direct human prompting. That may include reading Linear, Slack, or other sources of truth to synthesize an individual task. Then the engineer tells the agent to "make a new branch" or "test your changes with Playwright / Integration Tests / Magic". But, if we already spent time writing the Linear ticket, let's skip the redundancy. So, the workflow engine is born:
When you assign a Linear ticket to Squire, this is what happens:
- Squire loads the workflow defined for "Implementing a Linear Ticket"
- Squire reads the issue
- Identifies the relevant product
- Spins up a new environment with the latest running version of that app
- Does research, planning, and when possible, opens a pull request with the changes
- Then it updates the Linear ticket with whatever it learned and accomplished
- Plus, the PR and Ticket will have a link to the running squire environment where the fix is implemented
That last step matters. The reviewer isn't just reading a diff. They can click through to a running instance of the app with the fix applied, poke around, and validate the behavior before approving.
Meeting people where they work#
Of course, we want to make adoption as fluid as possible. We created a stellar CLI to go along with Squire, that does pretty much anything the frontend can do and in some cases more. My favorite is squire open which will open every environment you have in a single Zellij (or Tmux) window. Here's a demo of me doing this with 100 environments:
Or if you're not a CLI fanatic like I am, we built a Slack integration as well. Say you notice a bug, or a coworker notes something that isn't working quite right, and you know that's a nice quick fix but you're about to jump in a meeting. Just write "@squire, fix the bug that Claire just talked about in this thread" and voila, after your meeting you have a PR and running environment waiting to be validated.
Since Squire has MCP integrations, you can also use it to write more fully-featured work. For example, "@squire, create a Notion doc about this Slack conversation. Search online for what technologies may work for this, and present pros and cons as well as links to your findings."
And once we like the RFC, we can "@squire implement the feature branch using Vite, Pebble, and Cloudflare tunnels."
Why this matters beyond our engineering team#
Squire is one piece of how C1 is operationalizing the agentic enterprise internally, giving agents a place to operate on real, running instances of our product.
The pattern is the same one we keep seeing across the company: lower the barrier, remove the structural bottleneck, let agents handle the routine work so people can focus on the decisions that actually matter.
We're not done. Squire is getting smarter about the codebases it works on, how to validate its work, and how to handle multi-step changes that span services. But even today, it's already changing how fast we move on the small stuff. The paper cuts. The "I'll get to it eventually" tickets. The bugs that sit in a backlog because nobody has an environment ready to reproduce them.
Those tickets don't sit anymore.
At C1, we're building identity governance for the agentic enterprise. We're also building the agentic enterprise ourselves. This is part of an ongoing series where our team shares how we're using AI agents internally to move faster, build smarter, and rethink what a small team can do.
