It's 11:14 PM on a Tuesday. I send two messages to our team Slack channel:
"Add basic rate limiting to the auth proxy — per-IP, in-memory is fine for now."
"Build a Slack integration for the human review approval block. Details in the Linear ticket: SLATE-214"
Then I go to sleep.
Not "go to sleep and hope someone picks it up in the morning."
Actually go to sleep.
By 7:30 AM, both tasks have gone through the full cycle. Spec written.
Code implemented across our backend middleware. Pull requests opened. A security vulnerability caught on the rate limiter (IP spoofing via X-Forwarded-For), flagged, sent back, fixed, retested, and cleared.
When I log in, I don't see a to-do list.
I see two PRs, raised, reviewed, and ready for deployment.
No human touched any of it overnight.
At Slate, we haven't just automated the grunt work. We've built a system where AI agents have the deep skills to architect, critique, and diagnose complex systems.
We call it SlateClaw, built on the OpenClaw framework.
Here's how we built the team that works while we sleep.
The Squad: Four Specialists, Zero Overlap
We stripped the system down to four focused specialists.
They don't chat. They don't socialize.
They work.
Each one has a specific personality, toolset, and context window dedicated to a single job.
Every agent gets the same dev tools any engineer on the team would: codebase, GitHub CLI, AWS CLI, Linear, whatever the task demands.
The difference is scoping. Each one only gets the access and permissions it actually needs.
Yoda, The Router
Yoda is the front door. It lives in Slack. It's the only agent that talks directly to the team.
It handles daily chores, flagging stale PRs, walking a new hire through local setup. But its real job is traffic control:
- Build task? Route to Mando.
- Code review? Route to Vader.
- Production on fire? Route to R2.
Fast, decisive, no wasted cycles. Yoda runs on GPT-5.3 Codex at low reasoning.
It doesn't need to think deeply; it needs to think quickly.
Mando, The Architect
Mando doesn't just "write code."
It writes a spec first. A full SPEC.md defining the problem, scope, and technical approach, before touching a single line of Go or TypeScript. No questions asked, no shortcuts taken.
You give Mando the job, the job gets done.
Spec first, code second. Every time.
It runs on GPT-5.3 Codex at extra-high reasoning. Complex implementation and architecture demand the heaviest thinking budget.
Vader, The Gatekeeper
Vader never writes code. Vader judges it.
Think of it as the most intimidating code reviewer you've ever worked with, except it never gets tired and it never lets things slide.
OWASP vulnerabilities, multi-tenancy leaks, regression risks. It doesn't hand out vague advice. It points to specific lines and demands fixes.
Nothing gets past Vader. That's the point.
Also running Codex at extra-high reasoning, because security auditing can't afford shortcuts.
R2, The SRE
R2 works quietly in the background, connecting symptoms to root causes. It has read access to AWS and our logs, and it knows the difference between a surface-level alarm and the actual problem underneath.
When things break at 3 AM, R2 is already running the investigation before anyone wakes up. It runs on Claude Opus 4.6 at high reasoning; log analysis and infrastructure diagnosis play to its strengths.
(We actively benchmark between Codex 5.3 and Claude Opus 4.6, swapping based on performance. No loyalty to any single model, just whatever produces the best results right now.)
The Problem That Almost Broke Everything: Context Loss
Four sharp agents are useless if they can't remember what each other did.
This is the single biggest killer of agent workflows. Agent A does the work, summarizes it for Agent B, and all the nuance evaporates. We hit this wall hard.
The fix was a shared file system we call the Packet Bus.
Every task gets a unique Work ID and a persistent folder with three living documents:
- SPEC.md: The contract. What are we building?
- STATUS.md: The timeline. What happened, when, and by whom?
- REVIEW.md: The verdict. Pass, fail, or warn, with specific findings.
If the chat session dies, the work persists. If the thread gets lost, the work persists. No agent ever starts from scratch wondering what happened before it showed up.
Institutional memory. That's what turned four independent agents into a functioning squad.
The Part Most People Get Wrong: It's Not About Generating Code
Let's go back to that rate-limiting task from the opening.
Mando wrote the code. Vader reviewed it. And Vader found a problem:
"auth-proxy/rate_limit.go:72: X-Forwarded-For is trusted from any source, allowing IP spoofing. Fix: Verify against trusted proxy CIDR."
Now here's where it gets interesting.
Yoda didn't forward this to me. It routed it back to Mando.
Mando read the finding, updated the code to extract the trusted proxy correctly, added a test case for spoofing, and pushed the fix. Vader reviewed again. Green light.
That entire review-reject-fix cycle happened autonomously. No human in the loop for any of it.
But, and this is the part we care about most, we aren't removing the human from the loop. We're elevating them.
By the time I look at a PR, the syntax checks are done. Security audit, done. Logic review, done. I skip all of that and focus on the things that actually need a human brain: product value and architectural fit.
The agents handle the execution. The engineers handle the judgment.
When Production Is on Fire
This is where R2 shines brightest.
An alert fires: ECS Memory above 90%.
R2 doesn't guess. It doesn't hallucinate a solution. It runs a forensic investigation:
- Check state: Query AWS describe-tasks: are containers flapping?
- Check metrics: Pull CloudWatch timelines: when did the spike start?
- Check logs: Hit ZincSearch: any OutOfMemory or heap errors around that timestamp?
- Correlate: "The spike coincided with a deployment 30 minutes ago, but the error logs point to an unpaginated query on endpoint X."
Root cause analysis. 90 seconds. Delivered before anyone's rubbed the sleep out of their eyes.
That's not a nice-to-have. That's the difference between a 90-second diagnosis and a 45-minute war room at 3 AM.
The Hard Lesson: Why We Simplified
Now that you've seen how the system works, here's the part we almost got wrong.
We didn't start with this clean four-agent squad. We started with seven.
A DevLead, an InfraLead, separate Backend and Frontend specialists, and a QA bot, on top of the Router and Critic. On paper, it looked like a dream team. More specialists, more coverage, better output.
In practice? A mess.
Overlapping responsibilities meant agents were constantly stepping on each other. Instructions got so bloated they crowded out the actual task context. More agents didn't mean better output; it meant more confusion and worse results.
So we killed three of them.
The lesson was painfully clear: fewer agents with sharp boundaries beat many overlapping agents.
Every single time.
For an agent to be effective, its entire context budget needs to go toward its specific task, not toward figuring out whose job it is.
By consolidating to four, we made sure every token of thinking power was spent on the right problem. That's the system you just read about. It took getting it wrong first.
Ship From Anywhere
Because Yoda is the front door, the whole system is channel-agnostic.
- Slack for the core team during the day.
- Telegram for shipping quick features at midnight from your couch.
- Cron for scheduled daily health sweeps, auditing infrastructure and flagging stale PRs every morning at 10 AM, before anyone's even opened their laptop.
The entry point doesn't matter. The pipeline behind it is always the same.
The New Way
We didn't build SlateClaw to replace our engineers. We built it to free them.
No more ticket ping-pong. No more 3 AM log-grepping sessions. No more PRs sitting unreviewed for days because the team is buried.
Software engineers are the directors now, not just the laborers. We set the intent. The agents handle the execution, the verification, and the maintenance.
Two Slack messages at 11:14 PM. Two deployment-ready PRs by 7:30 AM.
If you're running a modern engineering team in 2026, this isn't a nice-to-have.
This is the way.
