Introducing Sikaru: self-improving agents, with the lab built in
Today we're launching Sikaru.
Built for agents that run in production, Sikaru unifies inference, managed agents, and a lab on one platform. It serves the models and runs the agents. Its lab turns every production run into evals, practice environments, and training data, and tests each change to an agent's context, harness, or weights against real runs before your team ships it. Your team never has to build or maintain that infrastructure.
Giving every agent team its own lab.
If you already run agents in production, you already have the data to make them better. If you are about to launch one, you can start with the lab from day one. Over time, AI will do more of the lab's work, and your experts will keep deciding what good looks like.
The next big gains in AI will come less from code people wrote by hand and more from what agents learn by acting.1 Agents at work already have plenty of that experience. A production agent makes thousands of decisions a day, and its users react to each one. They retry, rephrase, ask for a human, or take the answer and move on. That is about the best training signal an agent will ever get, and most teams leave it in a log nobody reads.
Sikaru is built to use it. Each agent gets a lab that learns from its runs, and we expect AI to take on more of that work each year, with your experts deciding where it goes.
Every agent on Sikaru runs one loop
- Managed agentsThe agentHarness, tools, sandboxes, Slack and HTTPserves live traffic
- InferenceThe trafficEvery call, tool step, and user reaction, recordedbecomes tests
- LabThe updatesContext, harness, or weights, replayed against real runsships as a new version · back to the agent
Every agent team ends up building the same stack
It usually goes like this. You start with model access and a fallback for when a provider is slow. Then you build the agent around it: tools, credentials, sandboxes, a Slack bot, a scheduler, and sessions that survive a crash. After the first regression nobody can explain, you add run logs and evals, then prompt tuning, and eventually some training.
A few months in, most agent repos look roughly like this.
A few months in, every agent codebase looks like this
Now picture four agent teams at four companies, each building the same thing.
Four agent teams building the same infrastructure four times
28 systems to build, run, and keep current: 4 teams × 7 layers.
Each team really only owns the top row. Everything under it is the same work, built and maintained four separate times. And because the system that runs the agent is usually separate from the one that improves it, every fix starts with exporting logs and ends with a migration.
We think two assumptions behind that setup are out of date. Inference used to be the last step in the pipeline, and now every call is something to learn from. The model used to be the only part that learned, and now instructions, memory, tools, and the harness can improve too. So Sikaru runs the traffic, the agent, and the updates in one place.
Inference
The runs you serve this week become the tests and training data for the version you ship next. That is why learning on Sikaru starts where the model is served, not in a separate pipeline you export data to. You pick a model from our catalog for each agent and can switch when a better one comes out. We serve every call and track what each run costs.
Since we serve the model, we can also serve one we have trained for you. A LoRA adapter (a small set of weights trained on top of a base model) goes live through the same release process as a prompt change.
Managed agents
An agent is a model plus a harness. A managed agent is that agent plus the runtime and infrastructure to run it, hosted for you.
Getting a production agent live used to take months of infrastructure work before the first real user showed up. On Sikaru you define the agent's task, tools, and guardrails, and we run it. Every part of it is recorded and versioned, so its context, harness, and weights can change without breaking what already works.
The harness is the code around the model that plans, calls tools, and keeps memory. Every agent on Sikaru starts with a state-of-the-art baseline: a recursive language model (RLM) harness. The model treats long inputs as something it can inspect, split, and call itself on, so it can work through inputs far longer than its context window.2 A lead agent plans the work and hands bounded pieces to sub-agents. The harness runs separately from the sandboxes where code and tools execute, so a crash in one does not take down the other.
The answer goes out, and the run is kept in full
- ChannelsHTTP · Slack · schedules
- HarnessLead agent plans, sub-agents do bounded work
- Tools and sandboxesComposio · your MCP servers · managed or your own compute
- InferenceModels from the Sikaru catalog
Run record
- 0:00slack · “Which deals slipped this week?”
- 0:02plan · pull pipeline → compare to last week → summarize
- 0:04tool · crm.deals.list(stage=commit) · crm.history(7d)
- 0:06model · 3 calls · 2.1s · $0.006
- 0:08record · run saved for signals and evals
Every agent comes with:
- Tools from hundreds of apps through Composio, your own MCP servers, or custom tools, with credentials kept in a vault
- Managed sandboxes, or your own machines if the work has to stay there
- HTTP, Slack, and scheduled runs
- Approvals for sensitive actions, and personal agents that act for a single user
- Draft, staging, and production releases, where every change is versioned and can be rolled back in one click
If your agents already run somewhere else, you can import their traces and see how they behave before moving them.
The lab
Every agent on Sikaru goes through the same loop.
- Run. We record each conversation in full: what the agent saw, what it decided, which tools it called, and what it said.
- Notice. Signals are checks that read every run. They flag failures, user frustration, and drift, then group similar cases, so a million runs turn into a short list of patterns.
- Test. Flagged runs become evals, which every new version has to pass, and practice environments. An environment is the unit the agent improves against, and it has three parts:
- tasks taken from real runs
- the agent's harness and tools
- a grader that scores the result
- Ship. Sikaru proposes the cheapest fix that passes. Your team approves it and it goes out as a new version. If nothing passes, the agent stays as it was.
What we watch is whether the same failure shows up less often in the next release, more than any single score.
Hosted evaluations, environments, and training
Everything in that loop runs on our infrastructure, so your team does not have to stand up its own.
- Hosted evaluations run your evals against any version of an agent, in sandboxes like the ones it runs in during production, so a passing result means what it should.
- Hosted RL environments package tasks from your runs, the agent's harness and tools, and a grader, ready for evaluation or training.
- Hosted training runs RL and fine-tuning on your trajectories and environments. The result is a LoRA adapter that goes live through the same release process as a prompt change.
AI builds, people decide
Models keep getting better at the work around the work. Give one a task and it can already suggest a harness for it, tests to check it, and environments to practice in. We expect AI to end up better at this than people doing it by hand.
Our reasoning is simple. If agents are good at writing software, they should be good at improving agents. So on Sikaru, AI and people work from the same record. The managed agents and their inference produce the runs, and AI reads them and drafts harness changes, evals, and environments.
| AI does | Your experts do |
|---|---|
| Reads every run and groups the failures | Define what good and bad look like, both the agent's behavior and the outcome |
| Drafts harness changes, evals, and environments | Decide what gets rewarded, whether the change is RL training or harness and context engineering |
| Replays every fix against real runs | Pick which failures are worth fixing and approve what ships |
What your experts reward matters most, because it decides what the agent gets better at. In one study, about 80 expert ratings were enough to build automatic graders that agreed with people more often than an AI judge on its own.3
The drafts also improve as the agent does. When practice tasks are rebuilt from an agent's latest failures, it keeps improving. With a fixed set of tasks, progress stalls.4
Practice rebuilt from the latest failures keeps improving; a fixed set stalls
| Series | RL step → value |
|---|---|
| Fixed set of practice tasks | 0: 41.1, 160: 44.9, 288: 47.2 |
| Task builder stops learning | 0: 41.1, 160: 40.1 |
| Tasks rebuilt from latest failures | 0: 41.1, 160: 48.9, 288: 53.3 |
Three places to fix an agent
People often equate learning with new weights, but many production agents run on closed models whose weights only the provider can change. For those agents, learning happens in the context and the harness. Open models let you change the weights as well.
- Context is the cheapest to change. Shopify moved a large workload to a self-hosted open model, used an optimizer to rewrite its prompts, and cut cost by more than an order of magnitude.5
- The harness changes how the model approaches the work. Harvey split long legal reviews between a planning agent and sub-agents that read the documents, then trained the planner with RL.6
- Weights change what the model can do at all. Coinbase reports that a small open model, fine-tuned on its own fraud cases, beat frontier models on that task while running cheaper and faster.7
These three limit each other, which is why Sikaru works on all of them.8
Improving the harness and the weights together beats either alone
What stays with your team
Nothing ships without your approval. Every change is versioned with the reason it was made, and you can undo it in one click. Credentials stay in a vault, and each agent can reach only the tools you grant it.
We use Sikaru to improve Sikaru. Our own self-improving agents run in the same lab you do, making inference faster, improving the harness, and building better evals and environments from real runs.
When we ship an improvement to inference, training, or infrastructure, every team on Sikaru gets that frontier research at the same time. The optimizations specific to your domain and product stay with your agents.
How we work
We work closely with a small number of teams we can grow with. Our founding team embeds with yours, from defining what a good result looks like to the first eval, the first production release, and every milestone after that. We hit those milestones together.
Come build with us
Bring your product. We keep the inference, the agents, and the lab at the frontier, so your team can focus on customers.
References
- David Silver and Richard S. Sutton. Welcome to the Era of Experience. 2025.
- Alex L. Zhang, Tim Kraska, and Omar Khattab. Recursive Language Models. arXiv:2512.24601, 2025.
- Ryan et al. AutoMetrics: Approximate Human Judgments with Automatically Generated Evaluators. arXiv:2512.17267, 2025.
- Yu et al. AutoEnvScaling: Automating the Data Flywheel with Terminal Agents. 2026.
- Shopify. From One-Shot to Agentic: Optimizing Shop Intelligence with DSPy at Shopify Scale. Conference talk.
- Harvey. Post-training RLM agents for M&A diligence. 2026.
- Brian Armstrong. Post on fine-tuning an open model for fraud prevention. October 11, 2026.
- Kim et al. WHALE: A Simple Recipe for Joint Harness–Weight Optimization. arXiv:2609.00196, 2026.