DEV Community: Arcships

How Dim Gives AI Agents an Input Guide: Meta Prompts, State, and Timeline

Arcships — Tue, 10 Nov 2026 07:13:34 +0000

Just after midnight on November 3, at 00:00:22, a local Dim session appended the day's date state. By the next model call, both dates appeared in the request:

<dim-state source="dim/environment/date">2026-11-02</dim-state>
<dim-state source="dim/environment/date">2026-11-03</dim-state>

The requests on either side of midnight (main #1910 and #1930) used the same System Prompt. The new date arrived in the messages, while the old date remained in the history. How should the model know which one means today?

The answer is Dim's Meta Prompt: an input guide supplied with each request in the Rust implementation. Its System section has a direct title, How to read your input. One of its rules says that a later state from the same source supersedes the earlier current value.

Why send environment state separately?

If today's date were inserted directly into the System Prompt, crossing midnight would require a new System version. The date, runtime environment, and available skills change on different schedules. Binding those values to the rules for interpreting them would force the prefix to change whenever any value changed.

Dim separates the instructions for reading an input from the input itself:

System tells the model how to interpret state.
Messages carry current values with their sources; updates have their own source and order.

To investigate the environment of an earlier request, you can follow the Timeline back to the inputs used at that point. Input guide and state definitions

If both messages have the `user` role, who said what?

Consider another recorded sequence. A background command finished, Dim recorded exec/ended at #413, then wrote a notification containing <dim-notification> at #414. Once consumed, that notification appeared in the model request at #421 with the API role user.

The human operator's own words also use the user role. The role alone cannot distinguish them. Dim sends the notification as a separate message with a runtime marker, and the guide explains its origin and meaning. A background completion notice is a result of earlier work; the model should relate it to its current task and decide whether it needs to read the full output. Message projection implementation

Branches follow the same principle. In another recorded sequence, a child timeline inherited the main timeline's history through #97. Its first model request contained both the inherited messages and a newly written branch identity block. That block also arrived in a user message; the guide explained that it described the current timeline.

One agent can have several timelines. The model needs an input that tells it which one it is on.

The diagram divides the model's input into eight categories:

System prefix
Rules and state
Tool declarations
Runtime inputs
User inputs
Tool results
Compressed context
Input guide

State describes the current situation. Rules have their own scopes. Files, web pages, and command output returned by tools are material for the model to analyze. The guide explains how to read each kind of input. Runtime permission checks still happen in the runtime: a marker identifies a source; it does not grant authority.

Who writes the guide for a new plugin?

Take background execution as an example. The capability that produces a notification also registers the explanation for that notification. Prompt combines shared guidance with the entries applicable to the current branch. A plugin registers its explanation when loaded and withdraws it when unloaded. Once the configuration adopts the change, subsequent requests use the updated guide.

Three model calls on the main branch of one session. The blue sections show the guide delivered in System each time; the message excerpts show a date update, a branch message, a background notification, and compacted context.

This matches the way Dim assembles capabilities with rutis. When a new capability sends messages to the model, its developer can maintain the marker, meaning, and explanation in the same component. Core owns the shared reading rules; each capability owns the content it introduces. Guide registration and composition

What can the model understand with this guide?

The Meta Prompt does more than explain one message. It helps the model maintain an accurate picture of its environment. Follow the main Timeline in the diagram above:

Configuration: Prompt combines the shared guidance and registered plugin entries into Guide A. At context/configured, that guide is adopted in System.
Request 1: Messages include a project rule (<dim-rule>) and the current date (<dim-state>). The model can see both the rule it should follow and the date.
Request 2: A date update (<dim-state>), branch message (<dim-branch-message>), and background notification (<dim-notification>) arrive in order. The model can tell that time has advanced, another timeline has sent a message, and a task has finished.
Request 3, after compaction: A history summary (<dim-summary>) and tool digest (<dim-digest>) replace older detail, while currently effective rules and state are reaffirmed. The model can distinguish past events from conditions that still apply.

All three requests use Guide A in System. The Messages change. The reading rules stay stable while the environment moves through the input stream.

In concrete terms, the model can track:

Time: which date is current, without mistaking an earlier date for today.
Rules: which project rules still apply and what their scopes are.
Position: which branch and timeline it is on.
Events: whether a background command finished or another timeline sent a message.
History: after compaction, what happened earlier and what still governs the present.

These are no longer stray lines mixed into a conversation. They form an account of the environment with a source, an order, and a reading guide.

How do rules change midway through a session?

So far, the examples have started from an already configured guide. In a real session, a plugin can be enabled or disabled midway, and rules can become active or expire. Two questions need separate answers: how should the model read a kind of content, and which specific content is currently effective? Dim handles those through different channels.

Reading rules: register with a plugin, withdraw with it

When a plugin is enabled:

It registers the markers it will emit, their meanings, and their explanations.
Prompt recombines the shared guidance with those entries into a new guide.
After configuration adoption (context/configured), subsequent requests use the new System.

Disabling it reverses the sequence: the plugin unloads, its explanation is withdrawn, Prompt recombines the guide, and later requests stop carrying that explanation.

This ordering puts the explanation in place before the content appears. It also prevents the model from continuing to interpret new input using withdrawn guidance. Earlier requests are not rewritten; the Timeline still records which guide version each one used.

Current content: append new rules, expire old ones within their scope

Rules and state do not rewrite history either. They are appended. The op on a <dim-rule> describes what happens to that rule:

set or replace makes the rule in the block effective; replace identifies the currently adopted version.
revoke or expired makes that rule ineffective within its scope. A rule with the same name in another scope is unaffected.

State is simpler: a later value from the same source supersedes an earlier one. A state block with cleared="true" says that state no longer applies.

Adding a rule during a session means appending an effective block. Removing one means appending a block that marks it ineffective. The old block remains in history; the model uses the latest block for the same source and scope. The two dates at the start of this article work the same way.

After compaction, expired rules stay expired

When compaction happens, subsequent state blocks reaffirm only the rules and state still effective at that moment. Each is restated in its most recently delivered form, such as a replace block for the adopted rule version. A revoked rule is absent, so the model does not treat it as current again. The guide also says these reaffirmations confirm the current situation: they are not new changes and do not grant permissions.

Which state survives compaction?

Return to the session that crossed midnight. Later, #2025 recorded a successful context compaction. The next model request, #2026, carried the summary and then reaffirmed five rules and state values still effective at that point. Of the two dates, only November 3 remained as current state.

The two parts have different jobs. The summary describes what happened before; the subsequent state blocks describe the conditions the model should keep working under. The input guide explains that these restatements mean the earlier rules and state are still effective.

To see exactly what a model received at a given moment, return to that request and compare its adopted guide, state, and retained history. Post-compaction message projection

Editorial note: AI tools assisted with the English adaptation and illustrations.

Timelines, Bike Theft, and the Art of Designing Dim: Event-Driven Architecture for AI Agents

Arcships — Tue, 10 Nov 2026 06:43:10 +0000

By duskzhen

Imagine I park my bike outside my front door. Worried it might get stolen, I set up a security camera and hire an AI Agent:

"Keep an eye on my bike for me."

A naive implementation is to have the Agent poll the camera feed every few seconds:

Bike is still there. Bike is still there. Bike is still there. Someone walked past. Bike is still there.

By morning, the bike is safe—and the context window is completely blown.

Sure, that approach works. But what I actually need is for someone to notice when the bike might be in danger, review what happened, and decide what to do next. Eight hours of peace and quiet on the street shouldn't translate into eight hours of continuous LLM inference.

While designing Dim, we came back to this scenario so often that we started calling it our "Bike Theft Theory." It illustrates a simple core principle: Just because the environment is constantly changing doesn't mean the model needs to be constantly thinking.

The Camera Records; the Agent Checks on Demand

Let's try a different setup.

The camera records continuously. Meanwhile, the Agent can work on other tasks or simply wait idle. At some point, a lightweight motion detector notices someone approaching the bike and fires a notification.

Only then does the Agent pull up the relevant video clips: When did this person arrive? Did they just walk past, or are they tampering with the lock? Has the bike moved?

After inspecting the footage, the Agent might realize it's just a neighbor picking up something they dropped. It logs that assessment and goes back to waiting. Or, it might see the lock being cut and alert the owner using a pre-agreed method.

Here, the notification's only job is to say, "Something happened that's worth looking into." Someone approaching is a clue; whether they are stealing the bike requires looking at the evidence.

Four-act conceptual animation: record, detect change, notify, and review on demand. (Bike surveillance is a hypothetical scenario used to explain our runtime architecture, not a built-in camera feature in Dim.)

What if the detector misses something? The owner might walk out the next morning, see the bike is gone, and ask: "What happened last night?" As long as the underlying records exist, the Agent can work backward from that question and inspect the past.

To pull this off, the system has to solve two distinct problems:

Leave behind records that might be needed later.
Pull the Agent's attention over at the right moment.

Without the first, an alarm goes off and there's no way to investigate what happened. Without the second, you end up with a hard drive full of footage that nobody ever looks at.

This exact division of labor is where Dim's Timeline and Event-Driven Architecture begin.

Why Chat History Alone Isn't Enough

When I previously worked on DeepChat, I was inspired by the "Tape" mental model: treating Context as an append-only tape. User prompts, model responses, and tool outputs all move forward along a single track. That gives you a solid foundation for context compression, sliding windows, and branching.

With Dim, we wanted to take a step further outside the chat box.

The environment an Agent lives in is much busier than a simple request-response loop. Background commands finish on their own, other branches send messages, the system date rolls over, plugins load, and users change their minds while a tool is still mid-execution.

Some of these changes demand an immediate reaction. Others just need to be logged for posterity, or queued until the current task wraps up. We can't pretend these events didn't happen just because the model wasn't looking—nor can we dump every single environmental change straight into the model's prompt.

Going back to the bike: "The camera recorded this footage" and "The Agent watched this footage" are fundamentally different facts.

Dim's Timeline bakes this distinction directly into the runtime. It records operational events across tasks that affect subsequent behavior, while the model's context is projected selectively from facts like inputs, outputs, tool results, and context states. The scope of what's recorded on the Timeline is intentionally broader than what the model sees in any single inference request.

And "recording the environment" doesn't mean dumping the entire world raw into a database. In our bike setup, heavy video files stay in blob storage while the Timeline records clip indices, detection events, and follow-up actions. In Dim, the key is recording the operational facts needed for coordination, auditing, and recovery—while reading the heavy raw materials on demand.

The Timeline: Giving Every Event a Deterministic Place

The word "Timeline" might sound like a simple timestamped log. In Dim, however, it defines the canonical execution order of the runtime.

Every branch has its own Timeline. As events are appended, the Timeline assigns a monotonically increasing sequence number. The runtime understands causality and order strictly through this sequence; a wall clock can tell a human when something happened, but it cannot replace the deterministic order of the sequence.

Why does this matter?

Suppose you tell the Agent, "Forget about the bike for now," right as a slow background detector finally returns "Someone is approaching." The system needs to know which task that detection belongs to and exactly where the cancellation command sits in the sequence so it can apply the right rules. Relying on whichever async callback finishes first is a recipe for resurrecting canceled tasks.

In our bike analogy, the Timeline looks like this:

Records append continuously →

Park Bike ── Clip Index ── Approach Detected ── Notification ── Read Clip ── Verdict
                                  │                                 ▲
                                  └─── Draws Attention ─────────────┘

Raw footage stays in storage for later review; the current judgment only fetches the relevant clip.

New conclusions don't overwrite old facts, either. First we record "Approach Detected," and later we record "Confirmed just passing by." We know both the current state of the world and the exact reasoning trail that got us there.

In code, this ordering comes with a strict persistence guarantee: in the SQLite storage path used by the App Server, the Timeline only advances its published cursor after an event batch is successfully committed to disk, which in turn allows the Dispatcher to broadcast them. Returning from append, committing to storage, and publishing to subscribers are explicitly distinct phases (see Timeline commit and publish implementation).

This ensures every subsequent reaction is grounded in verifiable history. Records aren't just for post-mortem debugging—they actively drive how the system moves forward.

Event-Driven Runtime: Only Wake Up What Needs to Move

Once you have a Timeline, something needs to consume it.

Dim uses a Dispatcher to broadcast published events in sequence. Runtime capabilities subscribe only to the event types they care about. Upon receiving an event, a capability updates its internal state or kicks off a job, writing any resulting facts back to the Timeline (see Dispatcher subscription and dispatch implementation).

Being "event-driven" happens first and foremost between these runtime components. It does not mean firing an LLM request for every single event.

When the camera detects motion, a lightweight heuristic can decide if it warrants a notification; when video archiving finishes, it just updates a record; when a monitoring task is canceled, it quietly cleans up its resources. Only items that genuinely require the model's reasoning are routed into the input channel.

We strictly separate three stages:

Stage	What It Means
Record Event	The fact has entered the auditable history.
Dispatch Event	Interested runtime capabilities can react to it.
Deliver to Model	Relevant content has entered the model-visible context via inputs or tool results.

Recording an event does not mean the model knows about it yet.

Dim's context management makes this boundary explicit: ordinary runtime events don't magically turn into LLM messages on their own. Content meant for the model must enter the context through adopted inputs or tool results. For instance, an input is first recorded as an event, and only when input/consumed occurs does the history projection expand it into an actual model message (see Input consumption and message projection).

Using a background command completion as an example, this animation shows how an event triggers a new notification input. Arrows indicate processing causality; notifications, input consumption, and model requests themselves also leave records on the Timeline.

This gives us a two-tier filter for "what's worth looking at." First, the runtime follows capability contracts to decide which environmental changes warrant delivery. Second, once delivered, the model evaluates the notification against its current goal to decide whether to inspect deeper or take action. Meanwhile, the user can step in at any time to adjust the goal or shift focus.

No Bike Required: Background Commands as a Real-World Example

You don't need a physical security camera to see this in action. Consider a classic developer workflow: an Agent kicks off a long-running build or test suite in the background and moves on to other work. When that command finally finishes, how do we bring the Agent back?

Dim's background execution capability follows the exact path we just described:

The command finishes, emitting an exec/ended event with the execution result.
Once committed and published, the Dispatcher routes the event to the background execution capability.
The capability checks the exit status and branch state; if wake-up conditions are met, it appends a notification input.
The notification wraps a <dim-notification> tag, a short output preview, and instructions on how to fetch the full log, entering the scheduler as a Steer input.
Once the input is consumed, the model reads the notification in its next turn and decides what to do.

In our current implementation, canceled background tasks won't trigger a wake-up along this path, nor will branches that are in the middle of shutting down. Because the completion event and the notification input are committed separately, our crash-recovery logic also checks for completed jobs that needed a wake-up but haven't emitted a notification yet (see Background result handling and Notification input construction).

This is the exact developer equivalent of the bike scenario: the full stdout/stderr log is the recorded footage, the completion alert is the motion notification, and calling a tool to read the full log is pulling up the video clip.

The model never has to spin in a loop asking, "Is it done yet?" And when the command does finish, it doesn't blindly force the old task to resume—if the user has already pivoted to a new goal, the Agent interprets the late-arriving result in the context of its new instructions.

At this point, the Timeline handles recording and ordering, and the event-driven runtime handles reaction and scheduling. That leaves one final puzzle: When the model receives this text in its context, how does it know what the message actually means?

Meta Prompt: Teaching the Model How to Read Its Inputs

In our previous post on Dim's Meta Prompt (An Input Manual for Models), we highlighted a subtle quirk of LLM APIs: whether a piece of text is typed directly by a human operator or injected as a notification by the runtime, it often arrives at the model API wearing the exact same user role.

If the model relies solely on the message role, it can easily confuse "The human user just gave me a new command" with "A background process from five minutes ago just exited."

The bike analogy works the same way. When the camera says "Someone is approaching," that's a sensor observation. When the owner says "Check who was just near my bike," that's an operator command. Both might point to the exact same video clip, but their origin, authority, and expected next steps are completely different.

Dim's Meta Prompt bridges this semantic gap. Alongside the system prompt, it provides an explicit "Input Guide." Each runtime capability registers the structural tags it introduces and their exact semantics, while dynamic payloads are delivered later through corresponding inputs:

For <dim-notification> (Background Alerts): The guide explains that this is the result of previously initiated work, the snippet is a preview from that command, and full output can be fetched on demand—and crucially, if the parent task is obsolete, do not restart it.
For <dim-state>: It explains state-update semantics, where newer values from the same source supersede earlier ones.
For <dim-rule>: It defines scoping and activation/deactivation lifecycles.

(See Input Guide implementation and Background notification semantics.)

Applied to our bike scenario, the model knows immediately which message is a sensor observation, which is the owner's instruction, whether bike monitoring is still active, and what countermeasures are authorized.

Of course, XML tags alone don't grant security permissions, and slapping an "Alert" label on sensor data doesn't turn it into an executable command. The model uses the Input Guide to understand meaning, while the runtime strictly enforces permission checks before any tool action is executed.

The Timeline gives events a place, the event-driven Dispatcher routes changes to the right handlers, and the Meta Prompt gives the model a framework to interpret them.

Making the Entire Harness Part of the Intelligence

Now, let's wire all these pieces together.

The environment changes, and facts are written to the Timeline. Runtime capabilities react to those events and push only what requires reasoning into the input queue. The model combines the Meta Prompt, its current objective, and its context history to make a judgment—calling tools when it needs more evidence, or triggering actions when it needs to intervene. Those tool outputs and subsequent environmental shifts then become new records on the Timeline.

Architectural overview: The Meta Prompt provides rules for reading inputs rather than acting as an async queue processor. The model's actions affect the environment via tools, and the results flow back into the Timeline.

When you view an Agent Harness this way, you realize you don't have to shove every ounce of responsibility onto the LLM. Recording, ordering, scheduling, provenance tracking, and permission enforcement are handled deterministically by the runtime; the model saves its tokens and attention for synthesizing goals and evidence.

This separation also makes long-horizon tasks sustainable:

Context Compression & Recall: When the context window fills up, summaries carry forward the past while re-asserting active rules and states. If the model later needs fine-grained details, Dim's recall tool lets it search and retrieve prior conversations and work records on demand. Compression only changes what is packed into the current inference request—the underlying historical facts remain safely stored on the Timeline (see Context compression checkpoints and Recall tool).
Idempotent Crash Recovery: Recovery respects the boundary between state and side effects. Re-reading a record that says "Alert already sent to owner" restores the system's awareness that the alert was sent—it doesn't fire the alert a second time. Rebuilding internal state and re-executing external side effects have strictly separated boundaries (see Time-bus side-effect guarantees).

Naturally, architecture alone doesn't make detectors infallible or models immune to misjudgment. If notifications are too noisy, the Agent gets woken up constantly; if they're too sparse, critical changes slip through. And if you still end up piping every raw video frame into the prompt, calling your log a "Timeline" won't save you a single token.

What's truly worth engineering is the coordination between the runtime and the model:

Can past records be retrieved when needed?
Do notifications provide enough clues without overwhelming the context?
Does the model understand the provenance and authority of incoming messages?
Does it have the evidence required to act, and does it get feedback after acting?

Back to that bike parked outside my door: I want an Agent that doesn't stare at the camera feed all night, yet snaps to attention the moment someone approaches; reviews the footage before jumping to conclusions; remembers if I've changed my mind about watching the bike; and can explain clearly the next morning what happened and why it handled things the way it did.

That is the exact coordination we're building in Dim—making sure environmental changes are reliably recorded and routed, so the model can see clearly right when it needs to.

The Dim repository contains the Rust implementation discussed here.

Editorial note: AI tools assisted with the English adaptation and visuals.

Introducing dim: A Better Runtime and Body for Agents

Arcships — Thu, 05 Nov 2026 09:24:03 +0000

Today, we’re open-sourcing dim—an agent harness built around an event timeline.

We want agents to perceive their environment, revisit their history, explore in parallel, and keep making progress toward their goals.

As models become more capable, agent architectures need to evolve alongside them. Our guiding principle is simple: fewer constraints, more guidance, and more room for models to understand, explore, and act.

That idea shapes four core architectural choices in dim.

An Event Timeline at the Core

Many agent harnesses are organized around message lists and model requests. dim is organized around a continuously growing event timeline.

User input, the agent’s decisions and actions, tool results, and the harness’s own operations can all become events on this timeline. Together, they record the agent’s interactions with the world and preserve the history of its ongoing work.

Once written, events are immutable and dispatched for processing. The state machines that consume and handle these events are called capabilities. Each capability advances the work it is responsible for, turning events into concrete changes and actions.

The agent’s history therefore includes its observations, actions, and results alongside its conversations.

Perceiving the Environment and Recalling History

We want agents to actively understand the environments they operate in.

In dim, an agent can choose to receive additional events from its environment. For example, it can learn which terminal, web interface, or client a user is interacting through, or become aware of configuration changes around it.

Developers, users, and even the agent itself can define meta-prompts to help the agent interpret what is happening.

The agent can also retrieve history from across the entire timeline in a structured way, including past conversations, events, actions, and results.

This richer view of its environment and history gives the agent more context for understanding tasks—and a foundation for more proactive exploration and action.

Exploring in Parallel Through Timeline Branches

dim supports timeline branches, allowing an agent to explore, reflect, and advance multiple lines of work in parallel.

We call this capability split attention: the same agent splitting its attention across multiple branches. Unlike subagents or collaboration across separate sessions, these branches represent the same agent thinking and working along different paths.

Each branch has the same resources, isolation boundaries, and rules as the main branch. At the prompt level, the branches maintain a consistent identity as the same agent.

Branching gives the agent room to examine problems from different angles and use reflection to keep advancing long-term goals. dim’s goal (pursuit) mode is one example of this capability in practice.

Building the Agent’s Body with Plugins

The model provides the ability to think. Tools, devices, and the runtime environment give the agent ways to interact with the world. We think of these capabilities as the agent’s body.

dim’s plugin system is built on rutis. Developers can write plugins in TypeScript, Go, Python, Swift, Kotlin, and other languages, connecting capabilities from different ecosystems and helping the agent extend and refine its body.

Plugins can run on different devices. Components such as dim’s timeline, store, and execution can also be mounted remotely, opening up more possibilities for agents running in the cloud.

Looking ahead, we want mobile devices, ESP32 boards, and other hardware to be able to host an agent or one of its branches, connected through different networking stacks.

Getting Started

Start with the installation instructions in the repository README.

You’ll need a Node.js version that satisfies ^22.19.0 || >=23.11.0, with npm’s optional dependencies enabled.

Then run:

npm install -g dimcode-alpha@alpha
dima

Once dim starts, use login/ to sign in or models/ to select a configured model.

Already using dimcode? The dimcode package is still the existing TypeScript CLI. The Rust alpha introduced here uses a separate package, dimcode-alpha, and command, dima. Both can coexist, and each maintains its own data.

Plugins, hooks, and MCP services can execute code when enabled. For an initial exploration, we recommend starting in read-only mode:

dima --permission read-only

Help Us Build It

We’ll continue improving the code and documentation in the repository.

If you run into a problem, find something unclear, or have a use case you’d like to explore, please share the details in GitHub Issues.

We’ll also publish more articles and video tutorials covering setup, how dim works, and how to use it.

Explore the source code and getting-started guide →

Building rutis: Replaceable Plugins Across Languages and Machines

Arcships — Tue, 03 Nov 2026 06:07:41 +0000

By Eric Cheng · Arcships · First published in Chinese on October 23, 2026

TL;DR: rutis is a Rust-based plugin runtime for agents and other long-running software. Plugins provide named services, so a caller can keep using calendar while its implementation changes language or moves to another machine. rutis tracks dependencies, cleanup, and the restart of affected plugins so those changes can happen without restarting the host.

Agents can write integration code quickly. The harder question is how to try that code, replace it, and roll back failures while the system keeps running. This post explains rutis's lifecycle model, how it crosses process and machine boundaries, and where the design is headed.

1. When changing code is no longer expensive

In the past, we designed software on the assumption that changes were costly. We tried to settle requirements first, stabilize interfaces, lock down dependencies, and then change as little as possible.

When changes become cheap, that assumption no longer holds. For software that can iterate on itself, the everyday activity is not simply running. It is trying things out:

Today it needs to connect to an internal calendar system, so it writes a first version and tries it.
Tomorrow it finds a better interface for that system and swaps in a new version.
The next day it needs a model on a GPU machine, so it moves part of its capability there.
Later, a heavily used component needs to be faster and more reliable, so it is rewritten in another language.

Each change is small. But a running system may go through dozens of these small changes in a week.

The hard part shifts from how to write it to how to keep replacing it. When a component is replaced, are old connections, timers, and listeners left behind? Do the components that depend on it break? Can a bad replacement be rolled back? If a service moves to another machine or is rewritten in another language, must all of its callers change too?

These questions determine whether software can really grow.

2. Wait for others to adapt, or connect to them ourselves?

Today, the usual way for software to gain a new capability is to wait for someone else to make it available.

The maintainers of an environment provide an API, an SDK, an open platform, or, more recently, an MCP server. Software calls what they provide. This is a good approach, but it assumes that what software can do depends on what someone outside it has prepared. The connection sits outside the software. It belongs to the environment, not to the software.

Once software can write its own code, that assumption becomes unnecessary. It can reverse the direction of the work:

It can spend its own effort connecting to and adapting to other systems.

Whatever it needs to reach, it can write a plugin to connect to it—in the language that fits best, perhaps with an agent writing the plugin. It can try, revise, and replace that plugin. The connection becomes part of the software, with its own lifecycle. It can be observed and cleanly removed.

Eventually, software could even replace an external interface or system. That may sound like a slogan, but in rutis it follows from a simple mechanism:

A consumer depends on a service's name, not on its implementation.

Suppose a scheduling feature depends on a service named calendar.

At first, a plugin provides calendar by wrapping the company's existing calendar system.
After real use, the team understands which methods calendar needs and what they should return.
Later, the provider is replaced with an in-house implementation that still exposes the name calendar.

The scheduling feature does not change a line of code across those three stages, and the host program does not restart. Adapting to a system and replacing it are two stages of the same process. There is no separate migration project between them.

Both approaches can coexist. An MCP client can be an ordinary plugin in rutis. But the environment should not determine the limits of what software can do.

3. The foundation: replace one piece while the system keeps running

For software to iterate this way, it first needs to be split into pieces that can be replaced individually at runtime. Those pieces are plugins.

Plugin systems are not new. But replacing plugins frequently while a system is running demands stronger guarantees. The rutis core focuses on a few of them, each stated as a promise and backed by tests:

A plugin does not start before its dependencies are ready. It declares the services it needs and runs only when all of them are available.
Everything it registers is cleaned up exactly once when it stops. Services, listeners, background tasks, and child plugins are released in the reverse order of registration—no more and no less.
A failed startup rolls back. Anything already registered is withdrawn, leaving no half-finished state.
Replacing one piece restarts only the parts that use it. When a service provider changes, its dependent plugins stop and wait for the new provider to become ready. Unrelated parts keep running.

With those guarantees, replacing a component once and replacing it a thousand times should be equally safe. Software can iterate in smaller steps: replace one part instead of releasing the whole system, test it in a real running environment, and switch back if it does not work.

The term hot update can mean different things. Some systems replace machine code in place. rutis replaces running components. This approach is in the same tradition as Erlang/OTP and Java's OSGi. Rust's ownership model gives clean unloading a firmer foundation: in a garbage-collected environment, one stray reference can keep an old module alive indefinitely.

But plugins are only the foundation. What rutis really aims to do is let this kind of iteration spread outward.

4. Let iteration cross processes, languages, and devices

If iteration can happen only within one process and one language, the environments software can reach remain limited to that ecosystem. To use Python's model ecosystem, it has to be brought in. To use a device on another machine, someone has to build a separate remote-call layer. Every boundary forces the system to solve startup, dependencies, and cleanup again.

rutis makes those boundaries invisible to a plugin: a plugin does not need to know which process provides a service, which language implements it, or which machine runs it. It knows the service by name. rutis handles where the service comes from, what happens when the connection drops, and how dependents follow a replacement.

The following three examples cross three different kinds of boundary.

Example 1: an agent whose shell runs on another machine

Imagine an agent built with rutis. Its model calls, conversations, and decisions happen locally, but it needs to execute commands somewhere else—perhaps in an isolated sandbox or on a GPU machine with CUDA installed.

The shell can be a plugin running in a Python runtime on that machine:

import asyncio
from rutis import define_plugin


class Shell:
    async def run(self, command):
        proc = await asyncio.create_subprocess_shell(
            command, stdout=asyncio.subprocess.PIPE, stderr=asyncio.subprocess.STDOUT
        )
        out, _ = await proc.communicate()
        return out.decode()


def apply(ctx, config):
    ctx.provide("shell", Shell())


plugin = define_plugin(apply, provides={"shell": Shell})

That machine runs a listening Python runtime with shell_tool installed. The rutis host where the agent lives decides how to configure the plugin and when it starts and stops:

{
  "id": "agent",
  "rows": [
    { "id": "sandbox", "name": "rutis-host/dial",
      "config": { "address": "wss://sandbox.example.com:7443/rutis" } },
    { "id": "shell", "name": "sandbox:shell_tool" }
  ]
}

This is an architecture example, not a complete deployment recipe. The remote runtime also needs TLS and a shared token; the node connection guide covers those steps.

The agent's side depends only on the name shell. As a result:

Moving to another execution environment requires changing one address in the configuration.
If the remote machine disconnects, the parts that depend on shell stop and wait instead of crashing. They load again when the connection returns.
The execution environment can evolve too. The shell plugin may begin in Python and later be replaced with a Go version without changing the agent's code.

The agent's "hand" has reached another machine, yet it uses that hand much as it would a local one.

Example 2: a server with components spread across processes and machines

Consider a more familiar case: a backend service.

Its main logic is written in Rust, but different supporting components belong in different places:

Server's main logic (Rust)
  ├─ Database client                 Same process
  ├─ Third-party API integration     Python process, using the official SDK
  ├─ Inference service               Runtime on a GPU machine
  └─ Adapter for a legacy system     To be replaced with an in-house implementation later

Each component is a plugin that provides a named service. The main logic uses those services by name. Where they run and which language implements them live in configuration, not in the callers' code.

This has several consequences:

Failures have boundaries. If the Python process crashes, the services it provided are withdrawn and their dependents stop and wait. Other parts of the same host keep running. rutis can also restart a failed runtime according to a backoff policy.
A configuration change does not leave the service half-broken. Reloading configuration at runtime is all-or-nothing. If the new configuration is invalid, the old one keeps running unchanged.
Adapt first, replace later happens here. A plugin initially wraps the legacy system. Once the service contract has settled under real traffic, it is replaced with an in-house implementation. The main logic does not need to know this happened.

Example 3: multiple rutis hosts sharing capabilities

The final boundary is the device. Each rutis host can be a node in a network.

Office node ── exports calendar ──▶ Cloud node running the agent ◀── exports device ── Home node
            ◀── shared services · remote plugins · forwarded events ──▶

Nodes are joined by an encrypted connection. Over that connection, they can:

Share services: export a local service to another node or import a remote service as a local one.
Run plugins on another node: a plugin uses that machine's services while its configuration and lifecycle are controlled from here.
Forward events: an event on one side can be received on the other.

A dropped connection reconnects automatically. While the other node is offline, the parts that depend on it wait and then resume when it returns.

This is the clearest picture of iteration spreading outward: each node contributes the capabilities of its own environment. The office node can reach internal systems, the home node can reach devices at home, and the cloud node has compute capacity. When one node learns to connect to a system, software across the network gains access to that capability.

Further ahead, phone and desktop apps could join in the same way. An app could expose contacts, location, or notifications as plugins, connect to rutis, and become part of the network. This part is still at the design stage, but the direction is the same.

5. Give the stable parts to Rust and the changing parts to the ecosystems

This works because rutis makes a basic division:

Give what is stable and unlikely to change to the systems layer. Give what changes and needs an ecosystem to other languages.

The stable part is the lifecycle: what starts first, what happens when a dependency disappears, how cleanup works, and what cannot be done across a process boundary. rutis implements those rules once, in Rust. Its core depends on tokio and only a handful of other libraries. Each guarantee is recorded and tied to specific tests.
The changing part is connection and adaptation. Python has an ecosystem for AI and data processing; Node has npm and existing Cordis plugins; Go has a large set of infrastructure libraries; and another machine has its own processes and devices. On these language-specific sides, there is only a small SDK, not another implementation of the framework.

This division also describes a progression over time. A capability often starts in Python or TypeScript so it can be tried quickly. Real use gradually clarifies its shape. The parts that have stood the test of time can then be rewritten in Rust for reliability and performance. An early design note put it this way:

TypeScript is the lab; Rust takes the graduates.

Which parts deserve to "graduate"? Parts whose meaning has settled; parts that are mechanisms rather than wording; parts that are performance-sensitive or sit on a trust boundary. For an agent, for example, the mechanism for assembling prompts can be made permanent, while the prompt content should remain changeable.

Because consumers depend only on service names, the path from experiment to stable implementation can be taken one step at a time. There is no need to stop one day for a large migration. Each additional runtime connects the software's ability to evolve to another ecosystem.

6. A new container for growth

Placing rutis next to an operating system helps clarify what it is.

	Traditional operating system	rutis
Assumption	The program has already been written and runs inside it	The program keeps growing and changing while it runs
What it manages	CPU, memory, and processes	Connections and capabilities: who provides what, and who depends on whom
Boundary	One machine	Across processes, languages, and devices
How a program gains a new capability	Install software or a driver	Write a plugin to connect to something, try it, and replace it
Main concern	Isolation and scheduling	Whether the whole system remains correct and clean after one piece is replaced

rutis does not replace the operating system; it runs on top of it. An operating system lets programs run. rutis aims to let programs grow. From the perspective of rutis, plugins are like processes, services are like system calls, and language runtimes and remote nodes are like drivers. All of them follow the same lifecycle rules; none receives special treatment.

Closing

For the first time, software has a chance to understand and engage with the world around it on its own. Instead of waiting for someone else to prepare an interface, it can go out, connect, try, improve, and, when needed, replace what is there.

That requires a container that remains reliable through frequent change, one that is not confined to a process, a language, or a device. That is what rutis aims to become.

The rutis lifecycle model comes from Cordis by Shigma. rutis implements it in Rust and carries it across more languages, processes, and machines.

Try it with Node 22+:

npx @arcships/rutis-host new weather --lang node
cd weather && npm install
npx rutis-host dev        # Run the plugin and reload it automatically when files change

Python, Bun, and Go can be starting points as well.

GitHub: https://github.com/arcships/rutis
Design philosophy: How rutis is designed

English translation prepared with AI assistance. Original article by Eric Cheng.