Self-improving managed agents, steered by your team

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, every harness runs the same open model, Kimi K3, on identical machines. Sikaru's baseline harness leads, even with self-improvement switched off.

SikaruMiniMax CodeCodexDSH CreatorClaude CodePiDSH PTCDSH StandardOh My PiKimi CodeDSH MinimalExo HarnessOpenCodeHermes

CostSpeed

Pass rate

50.0%

62.2%

74.5%

86.7%

$1

$2

$5

$10

$20

Sikaru (self-improvement off)86.7% · $1.84Sikaru (self-improvement off)86.7% · $1.84 · 4m 28sMiniMax Code76.7% · $1.82MiniMax Code76.7% · $1.82 · 4m 33sCodex66.7% · $3.47Codex66.7% · $3.47 · 6m 43sDSH Creator63.3% · $3.28DSH Creator63.3% · $3.28 · 6m 44sClaude Code63.3% · $18.34Claude Code63.3% · $18.34 · 9m 38sPi60.0% · $2.43Pi60.0% · $2.43 · 7m 33sDSH PTC60.0% · $4.58DSH PTC60.0% · $4.58 · 7m 44sDSH Standard60.0% · $3.46DSH Standard60.0% · $3.46 · 6m 17sOh My Pi56.7% · $4.75Oh My Pi56.7% · $4.75 · 6m 46sKimi Code56.7% · $3.65Kimi Code56.7% · $3.65 · 7m 56sDSH Minimal56.7% · $4.72DSH Minimal56.7% · $4.72 · 5m 41sExo Harness53.3% · $1.05Exo Harness53.3% · $1.05 · 6m 17sOpenCode50.0% · $3.24OpenCode50.0% · $3.24 · 6m 27sHermes50.0% · $2.90Hermes50.0% · $2.90 · 6m 58s

Median cost per task

Quality Leader: Sikaru

86.7% pass rate · $1.84 per task

Balanced Pick: Pi

60.0% pass rate · $2.43 per task

Cost Leader: Exo Harness

$1.05 per task · 53.3% pass rate

Speed Leader: Sikaru

4m 28s median runtime · 86.7% pass rate

Numbers for other harnesses are taken from their reported results on frontierharness.org; MiniMax Code was reported separately. Sikaru ran with self-improvement off.

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.

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

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.

 ## 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.

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.

Setting one up

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

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.

❯ 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.

❯ 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.