We wanted an open-source coding-agent API that could hot-swap providers and models without losing context.

That means the same agent loop should work on top of Anthropic, OpenAI, Google, Kimi, Qwen, MiniMax, and self-hosted models. It should be usable as a terminal coding assistant, but also as normal Python code: import an agent, give it tools, run it inside a script, spawn reviewers, switch models, persist sessions, and inspect the typed results.

That became sagent, a strongly typed Python API and CLI for building coding and developer agents.

The public package is about 31k lines of typed Python code with another 26k lines of tests. The main design rule is still simple: everything that crosses the runtime boundary is a message, and every surface uses the same agent loop.

pip install sagent

from sagent import tools
from sagent.agent import Agent
from sagent.lib.json import json_freeze
from sagent.providers import Google

agent = Agent(
    model=Google.from_env().model("gemini-2.5-flash"),
    system="You are a scientist.",
    tools=[tools.Read(), tools.Glob(), tools.Grep()],
)
result = await agent.run(json_freeze({"prompt": "analyze the CSV in ./data/"}))
print(result.content)

Everything is a message

The core idea in sagent is simple: everything that crosses the runtime boundary is a Message.

Text, bytes, JSON, tool calls, tool results, model responses, user prompts, compaction summaries, and multi-part assistant turns all move through the same typed message graph. Conceptually, a message is content plus a MIME descriptor, such as text/plain, application/json, or multipart/x-tool-call.

That decision removes a lot of special plumbing. Providers, tools, sessions, compaction, the CLI, Slack, parent agents, and child agents all speak the same shape. The runtime does not need one representation for model output, another for tool calls, another for persisted sessions, and another for UI events.

The second core idea is that an agent owns an inbox.

while True:
    drain inbox into user messages
    call model
    if tool calls exist: dispatch tools and loop
    if inbox is empty and model is done: go idle

The inbox is a deque. User messages go to the front, so a person can interrupt a running session. Background completions, peer-agent messages, delayed wakeups, and tool results go to the back. The agent keeps draining, running, and checking until there is nothing left to do.

This is closer to an Erlang-style process than to a request-response wrapper. An agent has state, a mailbox, and a loop. It can wake, receive messages, spawn other agents, and keep working without each surface needing its own control plane.

Tools are the core abstraction

A Tool is anything with a schema and a run method. It takes a Message, which may be multipart, and returns a Message. Streaming tools yield intermediate Message events and finish with a final result message.

That makes Agent fit the same shape. An agent can be used directly, but it can also be treated as a streaming tool: send it a message, stream its events, and receive its final message.

This is why AgentSpawn is small conceptually. Spawning an agent is just calling another agent-shaped tool with an isolated model, tool set, session, and depth limit. Recursion falls out of the type, not from a separate orchestration layer.

Agents can change themselves

Sagent has three built-in coordination tools: AgentSelf, AgentSend, and AgentSpawn.

AgentSelf lets an agent inspect and mutate its own state. It can update its status, compact context, clear history, inspect diagnostics, adjust token limits, and change models.

The model swap is a useful consequence of this design. You can conversationally hotswap the backend while keeping the session context. Start with Claude, switch to Gemini, move to an OpenAI-compatible endpoint, then switch back. The provider normalization happens at the edge, so the agent loop keeps seeing the same typed model response shape.

That makes provider choice a runtime decision instead of an architectural one. Researchers can compare model behavior inside the same agent session. Framework builders can route different work to different backends. Coding-agent users can switch models mid-task without restarting from scratch.

Agents can talk to agents

AgentSend lets one live agent send a message to another live agent's inbox. This gives agents peer-to-peer communication instead of only parent-to-child calls.

AgentSpawn creates child agents. A parent can spawn an isolated reviewer, a specialized implementation agent, or a map-reduce worker. Spawned agents can also spawn more agents, subject to explicit depth and tool limits.

This matters because agent composition should not require a separate orchestration framework. In sagent, an agent follows the same protocol shape as a tool. A parent calls AgentSpawn, the child runs in isolation, and the child's final output returns as a normal tool result.

The same primitives cover common agent workflows:

• ask one child agent to review code;
• split a large search across many child agents;
• keep a persistent background agent alive;
• let two agents coordinate through inbox messages;
• use different models or tool sets for different subtasks.

The important constraint is that these are still typed Python objects. You can construct them, test them, limit their tools, inspect their sessions, and embed them in another application.

A lightweight interface over a real runtime

For day-to-day use, sagent also works as a terminal coding assistant:

GOOGLE_API_KEY=... sagent --provider Google --model gemini-2.5-flash

The REPL is intentionally lightweight: closer to an IPython-like working session than to a full IDE. It has local tools for files, shell commands, web fetching, search, scholarly papers, and agent coordination. It persists sessions per working directory by default, tracks cost, and compacts old context when the session gets long.

The same Agent powers the CLI, Slack service, parent agents, child agents, and Python applications. Surfaces differ in how they put messages into the inbox and render events. They do not own separate agent logic.

What sagent is for

Use sagent when you want:

• a strongly typed Python interface for coding agents;
• provider and/or model hot-swapping without changing the context or agent loop;
• custom tools as normal Python objects;
• session persistence and compaction;
• child agents and peer messaging for review, delegation, and map-reduce work.

It is not a sandbox. Enabled tools run with the current process permissions. Sessions are plaintext local state. If a task needs hard isolation, run sagent inside your own OS or container sandbox and give the agent a narrow tool set.

Sagent is also not trying to be every agent framework. There is no hosted service, desktop UI, browser automation, MCP integration, or LSP integration today. The focus is smaller: a typed Python runtime with concrete coordination primitives.

Try it

Sagent is open source under Apache 2.0.

• GitHub: github.com/rekursiv-ai/sagent
• Docs: github.com/rekursiv-ai/sagent/tree/main/docs
• Examples: github.com/rekursiv-ai/sagent/tree/main/examples
• PyPI: pypi.org/project/sagent

If you build agent systems in Python, try it and tell us where the abstractions hold up and where they break.

github.com/rekursiv-ai/copybarista

The hard part of open-sourcing code from your company's private source is not copying the files. Anyone can copy a directory from one place to another.

No, the hard part starts ten minutes later: it needs to be a normal public Python package, but the source of truth is still private. The imports point at internal modules, and README mentions internal workflow details. The GitHub Actions can push files one direction, but now someone sent a pull request and you need to send the changes back.

I wanted the boring version of this workflow: push private changes out as a clean pull request, pull public fixes back only when the reverse mapping is verifiable, and never maintain a second hand-edited copy of the package.

The first working version came together in a day of work. The release-ready version took another day of review, hardening, and documentation, but the core shape stayed small: choose a source subtree, rewrite it deterministically, export it as a clean repository, and let public fixes flow back through pull requests only when the mapping is safe.

That became Copybarista.

The problem was not copying files

The concrete case was a small Python tool inside our private monorepo. We wanted to release it as its own repository, and wanted that repository to look like a package someone would actually install:

• copybarista/ at the repository root
• a standard pyproject.toml, since we work with lots of ML code and love uv
• public docs and examples
• GitHub Actions for linting, type checking, tests, build, and publishing
• no private docs, source paths, internal workflow files, caches, or generated junk

The private source of truth still lived in the monorepo. I did not want to manually maintain a second copy of the package, and I did not want the open-source repository to become a fork that slowly drifted away.

The sync had to work in both directions:

1. Source changes in the private monorepo should export into a public pull request.
2. Public fixes should be importable back into the private source tree.
3. Both directions should use GitHub's normal PR review model.
4. The public repo should never receive private-only files or metadata.
5. The private repo should not blindly accept public edits that cannot be mapped back safely.

At first glance, this sounds solved. Just use rsync or git subtree. Or if you want to pull out the big guns, use Copybara.

But after trying these options, I immediately ran into a great deal of friction.

Why not just use Copybara?

Copybara is the obvious comparison. Its README describes almost exactly the class of problem we had: moving code between repositories, often between a private repository and a public repository, with one repository treated as the source of truth.

I've used Copybara many times when I was at Google, it works. It supports broad repository migration workflows, transformations, and bidirectional movement. It is also intentionally general: built with a Java runtime, using a copy.bara.sky config, and a large surface area.

But I ran into a snag: I had to do a few manual steps to install a separate Java runtime, which didn't interface nicely with the Python ecosystem we were familiar with. We just wanted to run uv sync and have it available as a dependency.

I came to the conclusion that we wanted a Python-native tool for one narrow workflow:

• export a Python package from a private or monorepo source tree
• rewrite imports, docs, and private blocks
• preserve public .github/ metadata like GitHub Actions
• open GitHub PRs instead of pushing directly to main, in both directions
• run verification checks before anything can ship
• easily install the tool with the rest of my Python packages using uv

Copybara could likely be made to do most of that with enough glue, but we weren't satisfied with glue.

The design fell out of the requirements

The core design stayed simple:

config -> stage files -> transform staged tree -> write destination

This was inspired a lot by Copybara's design philosophy, but the design is quite mature so in this case it's pragmatic to not reinvent good ideas. The basic principles lay out how to export the code and make sure the transforms are deterministic and safe. But now, it's written in a lightweight Python profile.

Export is fairly simple, coping a selected tree into a temporary directory, running deterministic transforms, then writing a folder or one clean Git commit.

Import is where things get more interesting. Copybarista compares the public tree before and after a public change, maps that diff back into the private source tree, reverses the supported transforms, and then exports again. If the new export does not reproduce the public head exactly, the import is rejected and touched files are rolled back.

That one invariant shaped the code, i.e., public changes come back only when they are reversible and verifiable.

The GitHub Actions part was the real test

Once I had a basic transformation and sync working, the real test became: "Can Copybarista export itself in a safe way"? This required writing and testing the full pipeline between our source repo and a new test repo, while ensuring security best practices.

GitHub's Security Lab has written about one class of security problem in the context of Actions: untrusted pull request code should not run in a privileged context with repository write permissions or secrets. Copybarista follows the same rule. Import and validation run without GH_TOKEN. The token appears only in the final PR creation step, and that step runs trusted helper code captured before public changes are applied.

All of this in a day of work?

I truly believe we are rapidly approaching a completely new paradigm of software. It's never been cheaper to spin up a bunch of coding agents to do your bidding and write lots of code to do your task.

Now I know what readers may be thinking: "doesn't this lead to lots of unintelligible AI slop?". And if you use the coding agents in the way most people do, my answer is yes.

But that's not quite what happened (at least from my reviews and testing). The results seem to paint a different picture: the code has docstrings that explain intent, is fully typed, has 90+% test coverage, was tested with a profiler to ensure fast execution, and uses a clean set of abstractions. The repo also contains lots of documentation, tutorials, and examples, and withstood my manual testing. The first time I ran Copybarista to export itself, it just worked out of the box.

The coding workflow was not "ask for a tool, receive a tool." It was: state a desired end goal, describe the workflow, and write and rewrite a spec 3 times over. I spent a couple of hours just going back and forth to design the right set of core primitives. Once that was done, the task was to implement the smallest working version, run tests, and then harden the implementation by having multiple agents run the software manually as if a person would.

The human part was scope control. Without a narrow target, the agents would rathole in some unimportant direction, so watching the shape of the APIs between major module rewrites was important. The project was able to stay on track because the answer to many changes was "no, we don't need that yet, let's try a simpler way."

What came after the first day

Now I should mention that technically it did take an extra half-day to polish the implementation. The first working version was functional, but not ready for release. That is the part that I underestimated the most. A tool can work internally long before it is ready for strangers. Making it open-source-ready meant writing more solid documentation and examples, setting up PyPI, deciding what happens when a public PR cannot be reversed, when an export PR goes stale, etc. The answers became docs, tests, and workflow rules.

What Copybarista is, and what it is not

Copybarista is for Python projects where the source of truth lives inside a private repository or monorepo, but the package should be released as a clean standalone repository.

It is good at:

• exporting a selected tree
• rewriting imports and docs and stripping private blocks
• keeping GitHub PRs as the sync interface

It is not trying to be:

• a full Copybara-compatible migration engine
• a replacement for human review

The lesson

The surprising part was not that AI helped write code quickly, but rather how it's still possible to move fast and yet write battle-hardened, clean, and working software that does its job.

Copybarista was a test in seeing how far we can push making OSS software in the new paradigm of coding assistance tooling. And it makes me excited to see all the cool software people build.

With the right approach, you can now move fast and not break things.

From November 26 to December 25, 2025, I experienced a new joy: every morning I rushed to my terminal to read what my autonomous research team had discovered overnight.

The team was four AI Scientists. They ran on a Claude Max subscription and a single GPU in my garage (an unnecessary but fun alternative to a cloud GPU). And by the end of the month, they'd written a machine learning paper, "Speed is Confidence", where the total cost amounted roughly to staying at a hotel for several days. The paper proposed an idea, that despite 21 years in ML I would not have come up with myself, because it involved wasting compute. The end result is that it achieved 97% accuracy on Sudoku-Extreme, a benchmark where the previous state-of-the-art was 85%, using 167× lower training compute.

This is the story of how that happened, what it felt like to work alongside them, and why we started rekursiv.ai.

What today's AI systems are missing

Everyone is building on top of AI systems that write code and has been for quite some time. And they're getting really, really good at it. But writing code isn't the hard part of research. The hard part is knowing what to build and why.

Current AI systems execute but struggle to discover. They don't form avant-garde hypotheses. They don't design sophisticated experiments. They don't stare at an unexpected result and ask "wait, why did that happen?" They don't do the thing that has driven every major discovery in human history.

The scientific method is in its infancy in AI research loops.

Observe, hypothesize, experiment, analyze, and repeat. This cycle is ancient, and while "obvious," no AI coding tool on the market does it well enough to invent fundamental and transformative ideas.

Four AI Scientists + one RTX 5090 ≈ $500 for one month

To see how far I could push commercial LLMs, I tried to set up a system that could do scientific discovery, which immediately failed. The second attempt was a lot more promising, but that also failed. It took 8 attempts before it worked. But when it did, it was able to iterate on research for a whole month.

The final system revolved around the design of 4 distinct AI Scientists, each with their own role:

• Scientist: forms hypotheses, designs experiments, owns research strategy. Never runs an experiment without a prediction of what should happen and why.
• Analyst: studies results, identifies patterns, proposes diagnostics. Gut-checks the scientist's proposal.
• Engineer: implements exactly what's specified. No freelancing. Asks for clarification rather than guessing.
• Reviewer: validates code against spec, dispatches GPU runs, owns the leaderboard.

A coordination script routes messages between the four scientists and manages their lifecycle. I built the system so a human can join as a fellow Scientist, allowing me to propose ideas, redirect experiments, and provide guidance. It also runs fully unattended when I step away.

Watch them think

Here's one experiment cycle, one of 984. It starts with a single prompt:

The Scientist searched the literature, found quantitative evidence against its own hypothesis, and changed its mind. It pivoted to the simpler explanation the Analyst suggested, despite no human telling it to do this.

984 experiments in 30 days

To kick-start the research loop, I pointed them at an open problem: take the Tiny Recursive Models paper and try to reach 100% accuracy on Sudoku-Extreme. TRM is a 7M-parameter neural network that solves constraint satisfaction problems by iteratively refining its predictions. Its reported test-set accuracy was about 85%.

Over those 30 days, the team ran 984 experiments and generated 882,534 lines of scientific discourse. Most experiments failed to make improvements. They documented 23 different approaches that made things worse: diversity losses, causal masking, entropy regularization, confidence weighting.

But buried in the wreckage were three observations that changed everything.

Three discoveries

First, the scientists noticed that training four models with different random seeds and averaging their predictions improved accuracy. Standard ensemble result.

Second, the Analyst flagged something in the halting dynamics. TRM learns a "stop" signal: when the model is confident, it halts early rather than iterating further. They noticed that when you run multiple models in parallel, the one that halts first is almost always correct. Selecting by speed instead of averaging significantly increased accuracy while using 10× fewer reasoning steps.

The result is "speed is confidence". The model that converges fastest has found the cleanest solution path. It's the same principle behind cortical winner-take-all circuits: the first neuron to fire suppresses the alternatives.

Third, I posed a revised objective to the scientists: achieve the halt-first-ensemble accuracy but as a train-time procedure with test-time compute matching the TRM baseline. The result? An algorithm I wouldn't have devised.

The algorithm I wouldn't have invented

During training, maintain four parallel models from different random initializations. At each step, find the one with the lowest loss (the "oracle winner") and only backpropagate through that one. Copy the winner's high-level reasoning state to all four chains, but let each keep its own low-level state so they stay diverse. At inference, run just one chain.

	Hardware	Training	Accuracy
TRM, Previous SOTA (Oct '25)	8× H100	5.3 GPU-hours	85%
Our AI Scientists (Dec '25)	1× RTX 5090	0.67 GPU-hours	97%

The AI Scientists invented an approach that is roughly 167× cheaper, and 12 points more accurate.

Here's why I wouldn't have invented this: the algorithm throws away 75% of the training compute. Every instinct I've developed over two decades says to use every gradient. The scientists didn't carry that baggage. They had a hypothesis (diversity in solution paths matters more than gradient efficiency), they tested it, and they found a reasonable solution.

Waking up excited

Every morning, I'd open the Analyst's latest report. Sometimes it was a failed experiment with a puzzling note. Other mornings, it was a breakthrough. The day the Analyst reported the halt-first result (97% accuracy where we'd been stuck at 91%) with an explanation grounded in biological winner-take-all circuits, I sat at my desk and laughed.

This is what the scientific method gives you: surprise.

What this means

That system was just a proof of concept. What it demonstrated is that AI Scientists can create new knowledge. Given a research problem and the right methodology, they form hypotheses, run experiments, interpret results, and arrive at novel solutions.

That's what rekursiv.ai is building. We're creating a platform for self-improvement, where AI Scientists collaborate with humans to do research, not just write code.

We're not done until we've scaled to millions of AI Scientists working collectively to solve important challenging problems.

If that interests you, consider reaching out to contact@rekursiv.ai.