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.
Top comments (0)