About

Learning agents
by building them.

In the first part of 2026 I wanted to understand how agents actually behave once they leave a demo — not the loop, which is easy, but everything around it. The only way to find out was to build the thing and run it for a while. These two repositories are what came out of that, and this page is the honest version of what I learned on the way.

Agentino is where I worked out the loop: a tool is a decorated function, the schema comes from its signature, and the runtime handles the round-trip. Small enough to read end to end, which was the whole point — I wanted something I could hold in my head rather than a graph DSL I had to trust. Runspace is what I built once I realised the loop was the easy part. Agents needed somewhere to live: channels, threads, a schedule, gateways to Telegram and WhatsApp, and a way to answer with a chart instead of a paragraph describing one.

Most of that time went into things no demo shows. Streaming that survives a client disconnecting mid-answer. Gates that stop a tool call before it runs, rather than a prompt politely asking the model not to. Tenant isolation checked with property tests, because the failures that matter are the ones a hand-written fixture never reaches. Every one of those started as a bug I did not see coming.

The lesson I keep relearning is that the interesting decisions are structural, not clever. Runspace never imports a runtime directly — there is a test that fails if it starts to — and that one constraint is why a sixth runtime is a new file instead of a refactor. Putting storage, vision and transport behind Protocols chosen by environment variable meant the same image runs against fixtures in a sandbox and real backends in production, with no branch anywhere in the code.

Both are Apache-2.0 because they are more useful being read than sitting in a private repository. Agents are the most interesting thing to build right now, and I would rather these were used than kept.

If you are learning the same things, come and build on it. Issues, pull requests and awkward questions are all welcome.

What they actually are

Agentino is the loop. A tool is a decorated function, the schema comes from its signature, and the runtime handles the round-trip, the retries and the dispatch. Small enough to read end to end in an afternoon, which was the point.

Runspace is everywhere the agents live: channels you reach them in, a scheduler, gateways to Telegram and WhatsApp, and a rendering layer so an answer can be a chart rather than a paragraph describing one. It drives five different agent runtimes and depends on none of them.

The documentation has the full picture, and the writing has the reasoning behind the parts I found interesting.

IS
Iliya Slavutin
Author and maintainer of Agentino and Runspace
Get in touch

I spent nineteen years at Intel, the last four building the OpenVINO organisation and leading it from a project to a deployment toolkit that shipped and got used. Since 2020 I have run Axeltec — inference, compiler and runtime engineering, vLLM through TVM, MLIR and kernels, for silicon vendors and AI infrastructure companies. What is on this page is the same interest pointed at agents instead of silicon.

If you have something interesting — a model that will not fit, a bill growing faster than the usage under it, a runtime that has to be quick on awkward hardware, or agents that need to survive contact with production — I would like to hear about it.

Bug reports and feature requests are better as GitHub issues — they stay visible to everyone else who hits the same thing. Security problems should go through a private advisory, not email or Telegram.

Both projects are on the front page, with the one question that tells you which of them you need.

Back to the projects →