# Self-improving managed agents, steered by your team

> Teams running agents end up building a research lab one tool at a time. Sikaru is that lab, with your team's judgment in it. Now in private beta.

Published 2026-10-30 by Sikaru team. Canonical: https://sikaru.ai/blog/self-improving-managed-agents

*Sikaru runs managed agents that improve from their own work, guided by your team's judgment.*

Every team that runs agents long enough ends up building a research lab, one tool at a time. Sikaru is that lab, already built. It runs your agents in the cloud, serves their models, reads every run, and improves each agent through better context, a better harness, or post-trained weights.

Here is where your agent starts. On [FrontierHarness](https://frontierharness.org/), every harness runs the same open model, Kimi K3, on identical machines. Sikaru's baseline harness leads, even with self-improvement switched off.

*Figure: FrontierHarness pass rate against cost per task. Every harness ran the same open model, Kimi K3, on identical machines. Sikaru's baseline harness, with self-improvement switched off, passed 86.7% of tasks at $1.84 per task. MiniMax Code reports 76.7%, and the best published harness, Codex, passed 66.7% at $3.47. Source: https://frontierharness.org/.*

## Why agents need to improve

Teams that run agents in production tend to go through the same stages. They ship an agent and watch it work. Sooner or later someone starts reading trajectories to understand why it failed. Then they write evals, and after a few rounds they learn which evals are worth trusting. The most serious teams start post-training models on everything they've collected.

By then, without quite meaning to, they've built a lab out of separate tools: one for traces, one for evals, scripts for datasets, and another stack for training. Each piece works. The loop that connects them, from a failed run to a tested release, is held together by a few engineers who would rather be building what customers asked for.

Frontier labs have run that cycle for their models for years. We think every agent a business depends on will need one too, and almost no team can hire a research group to run it.

All of it runs on trajectories, the full record of what an agent saw, what it called, and what happened. Whoever serves an agent's model calls already sees most of that record and usually throws it away. Sikaru serves the model and runs everything around it, so it keeps the complete record of every run and uses it to improve the agent. That lets a small team get the kind of results a frontier lab would, while spending its own time on customers.

## How a change gets made

Signals reads every trajectory, the part most teams start doing by hand. A decision model flags runs worth a closer look, groups failures that share a cause, and explains why each group fails. Your team can review any flag and add signals for things only it would notice, like an agent promising a refund it can't give.

Flagged runs become tests. Evals are real tasks every new version has to pass. Environments are practice tasks built from production runs, each with a grader, that the agent is replayed against and trained on with reinforcement learning.

Then Sikaru tries fixes in three places. The context is what the agent knows: instructions, memory, skills, and examples. The harness is how the model works the task: planning, tools, retries, and budgets. The weights are the model itself, post-trained with reinforcement learning on your runs. Any of them can be the answer, so Sikaru replays each candidate against the same real runs and proposes the one with the best outcome. Your team can add fixes of its own, like a policy that changed this morning, and they go through the same tests. A person approves every change before it ships, and any release can be rolled back.

*Figure: the lab for an example support agent. Signals groups failed runs by cause, flagged runs become evals and a practice environment, and candidate fixes in context, harness, and RL post-trained weights are replayed on the same tickets. The best outcome goes to the team for approval.*

Here is the same support agent through a full run, from a refund ticket to the release that fixes how it handles refunds.

*Figure: one support agent's run step by step, from a refund ticket through the durable session, inference, sandbox, tools, and recovery, to signals, a drafted fix, evals, team approval, and a new release.*

This is what the support lead reviews. Sikaru drafted the second half after seeing refund tickets escalated that support later approved, and the lead added the new policy window.

```diff
 ## Refunds
-Refunds are allowed within 30 days of delivery. Escalate anything older.
+Refunds are allowed within 45 days of delivery.
+Before escalating a refund, check the delivery date in the order history
+and quote it in the escalation note.
```

Beside the change, the lead sees how the new version did on past refund tickets: more resolved without a person, and none of the good ones worse. One approval, and the next refund ticket gets it right.

Every agent improves the same way. Some lessons it finds in its own runs, and some only your team knows.

*Figure: for each example agent, what it learns from its own runs and what the team adds to steer it.*

A fix can look good on the runs it was tested against and still be wrong in general. That's why every fix is also tested on runs the agent already handled well, why a person signs off, and why releases can be undone.

## What Sikaru runs underneath

Most of the work in running an agent sits outside the model call. Sikaru handles it:

- Every turn checkpointed, so long runs survive crashes and deploys
- Private conversation history, condensed before it outgrows the context window
- Memory shared across a team or kept per person
- Any model in the Sikaru catalog, behind one API
- A sandbox and workspace per session, or your own machine when the work needs it
- Your apps and MCP servers, with credentials in a vault and per-agent grants
- Skills, subagents, and messages that steer a run already underway
- Sign-off from a person before risky actions
- Email, Slack, HTTP, and the CLI to reach it, and schedules to wake it
- Caps on time, tool calls, and spend
- The full trajectory of every run

Agents keep working after you close your laptop.

*Figure: four example agents (GTM, support, IT, and autoresearch) on one platform that provides channels, identity, memory, sandboxes, schedules, and durable runs, with the lab and inference underneath.*

## Setting one up

An agent is a name, a model, instructions, and the tools it may use.

*Video: Creating a coding agent on Kimi K3, browsing the tool catalog, launching it, saying hi, and adding a weekday schedule.*

Or do it from the CLI: describe the agent in `agent.md`, create it, and run it. The last command keeps the agent in the cloud and runs its tools in your current directory.

```text
$ sikaru agent create support-agent --project <project-id> --file agent.md
$ sikaru agent run support-agent --project <project-id> "Summarize today's escalations"
$ sikaru agent run coding-agent --project <project-id> --compute local "Fix the failing test"
```

## When Sikaru fits

Sikaru is for business-critical agents that do real work over and over: long tasks, real tools and credentials, and people relying on the results. If the work is one question with no tools, skip the agent and call a model directly.

```text
$ sikaru inference chat moonshotai/kimi-k3 "hi"
Hi there! How can I help you today?
```

Both use the same API key and SDK, so a single call can grow into an agent when the work needs tools.

## Private beta

Sikaru is in private beta, and we're working with teams whose agents are critical to their business and need to keep getting better. If you want those agents to be the most delightful AI experience in your category without building a research lab first, we'd like to partner with you.

[Join the private beta](https://sikaru.ai/request-access)