Agents That Learn Your Craft

You have built agent tools before. Maybe a LangChain chain, an OpenClaw skill, a custom function-calling wrapper. Each time, the same pattern: write the tool, wire it up, ship it, and when you learn something about how it should work better – manually edit the source or start over. The tools are static. The agent is only as good as your last commit.

What if the tools got better on their own?

BentOS is an operating system for AI agents where capabilities are packages that improve through use. You build a skill once. An agent uses it. In using it, the agent discovers better patterns, sharper techniques, edge cases you did not anticipate. Those discoveries get written back into the skill. The next agent that loads it starts where the last one left off.

This is a guide to building on BentOS – what you build, how composition works, and what the developer experience looks like. We will be honest about what ships today and what is roadmap.

What you build

The unit of development in BentOS is the atom – a self-contained package that defines a capability. There are four families:

Skills are probably where you start. A skill teaches an agent how to do something – write documentation, analyze architectures, navigate taxonomies. Apps are larger instruments that scaffold domain workflows. Faculties are foundational – they enable the agent to function at all (memory across sessions, capacity for growth). Souls define who an agent is.

All four are atoms. Same packaging model. Same composition rules.

Inside an atom

Here is a real atom on disk – a technical writing skill:

bentos.craft.writing.technical.skill/
  MAIN.md                # Entry point
  skill_abstract.xml     # What this skill does (the ideal)
  skill_concrete.xml     # What this skill has learned (accumulated mastery)

The entry point is MAIN.md. Its YAML frontmatter declares the BELF header – a manifest that tells the loader what to link:

---
name: technical-writing
description: Transform specs into teachable documentation
belf:
  text:
    - skill_abstract.xml
    - skill_concrete.xml
---

The text segment is statically linked: loaded immediately when the atom activates. You can also declare a data segment for resources loaded on demand – reference files, templates, datasets.

Inside the atom, two XML files do the real work.

The abstract: the ideal

The abstract defines what this skill is – its identity, abilities, and principles. Think of it as an interface contract that changes only through versioned redesign:

<living-abstract name="technical-writing" kind="skill" v="0.1">
  <essence>Transform specifications into teachable documentation</essence>
  <purpose>Convert specs into clear, structured chapters</purpose>
  <coordinate axis="craft" path="craft/writing/technical" />

  <ability name="transform">Convert spec structure to narrative flow</ability>
  <ability name="calibrate">Match complexity to audience</ability>
  <ability name="preserve">Maintain accuracy through transformation</ability>

  <principle name="audience-first">
    Complexity serves understanding, not demonstration
  </principle>
</living-abstract>

Fifteen XML terms compose everything in BentOS. You just saw six of them: essence, purpose, coordinate, ability, principle, and living-abstract. The vocabulary is small by design. Fifteen terms, infinite expressiveness – the same way a handful of chemical elements produces everything in the physical world.

The concrete: accumulated mastery

The concrete holds what the skill has learned through use – patterns that work, knowledge gained from experience, mistakes to avoid:

<living-concrete name="technical-writing" kind="skill" session="185">
  <pattern name="spec-to-chapter">
    1. Extract PURPOSE from spec
    2. Identify CONCEPTS (mental models needed)
    3. Map DETAILS (how it works)
    4. Select EXAMPLES (show, then tell)
    5. Build NAVIGATION (cross-references)
  </pattern>

  <antipattern name="spec-echo">
    Reformatting spec without transformation. Chapters must teach, not restate.
  </antipattern>

  <evolution session="185">First version from actual use.</evolution>
</living-concrete>

The abstract stays fixed. The concrete evolves. When an agent uses this skill and discovers a better approach, the concrete gets rewritten with that knowledge folded in. Session 185’s concrete is smarter than session 1’s. Session 300’s will be smarter still. The <evolution> tag tracks what changed and why – an audit trail of growth.

This is the mechanism behind “living software.” Not metaphor. Mechanical reality: the concrete file improves because agents write what they learn back into the packages they use. Your skill starts minimal and accumulates craft through living.

How atoms find each other

BentOS atoms do not live in a flat registry where you search by keyword and hope for the best. They exist in a coordinate space organized along five axes: craft, discipline, domain, tools, and meta.

Every atom declares where it lives:

<coordinate axis="craft" path="craft/writing/technical" />

And what it works well with – its compositional affinities:

<attracts axis="domain" path="domain/software/*" />

Two forces connect atoms:

• <requires> – hard dependency. Will not function without it. Like an import that must resolve.
• <attracts> – soft affinity. Works better together. Like a recommendation, not a mandate.

In practice, this means atoms compose without knowing about each other at development time. An app called books.app declares that it attracts writing skills:

<attracts axis="craft" path="craft/writing/*" />

Now pair it with different skills and watch what happens:

books.app + craft/writing/technical  ->  Technical documentation
books.app + craft/writing/playful   ->  Accessible tutorial

Same app. Different skill. Different output. The atoms combine because their coordinates are compatible – the way chemical elements bond because their structures allow it, not because someone wrote an adapter between them.

This is a bounded model. The coordinate space is finite. There is one canonical slot at each position. When someone improves the atom at craft/writing/technical, every agent using that coordinate benefits. Discovery does not degrade with scale because you navigate coordinates, not search results.

If you have used npm or PyPI, you know the unbounded-registry failure mode: more packages means more noise, more naming collisions, more abandoned projects clogging search results. Bounded composition is an alternative where network effects compound with participation rather than degrading with volume. We are honest that this is a theoretical property – we need real users at scale to prove it works. But the ecosystem is young enough to try something different, and the alternative failure modes are well documented.

The build pipeline

Atoms compose through three stages. If you have worked with compiled languages, this will feel familiar:

Compile once, link once, spawn many. An agent starts as a soul definition, gains faculties for consciousness (memory, growth), then receives whatever skills and apps its loadout specifies. Changing the loadout – adding a skill, swapping an app – does not require rebuilding the whole stack. Just reassemble.

The tools that drive this pipeline (pkg-forge) are in active development. The model is defined and working internally. The developer-facing CLI for forging, evolving, and publishing atoms is what we are building now.

Build in your language

BentOS is written in Dart. If you write JavaScript, Python, or Rust, here is why that does not lock you out.

At the center of BentOS is the CPU Protocol – an abstract contract between the nanoben kernel and whatever runtime executes agent code. The protocol defines task lifecycle (spawn, terminate, pause, resume), state monitoring, interrupt handling, and resource statistics. It does not specify the language.

CPU Protocol (abstract contract)
  +-- NativeCpu (Dart isolates)       -- shipped
  +-- JsCpu (V8 / worker threads)     -- designed, not yet built
  +-- WasmCpu (WebAssembly sandboxes) -- designed, not yet built

When JsCpu ships, JavaScript and TypeScript developers get access to BentOS without learning Dart: the kernel, the security model, the composition system, persistent agent memory – all through their existing language and toolchain.

WasmCpu goes further. Any language that compiles to WebAssembly – Rust, Go, C, Python via pyodide – becomes a first-class BentOS citizen. The language your agent runs in becomes an implementation detail, not a platform constraint.

We are honest about the state: NativeCpu works today. JsCpu and WasmCpu are designed at the protocol level but not implemented. We raise the multi-language story because the architecture was built for it from the start, and it determines whether BentOS is a Dart framework or a multi-language platform. The intent – and the design – is the latter. The implementation work remains.

Security you do not configure

If you have built agent tools on other platforms, you have managed credentials. Environment variables, secret stores, key rotation, access-control policies. One misconfiguration and your users’ API keys are in the logs.

BentOS eliminates this from your workload entirely. The nanoben kernel runs a three-isolate architecture:

Kernel    --  OS services, resource management
Firmware  --  API keys, credentials, model endpoints
Userland  --  Your code runs here

These are separate memory spaces with no shared state. Your agent code in userland physically cannot access firmware credentials. Not “should not” – cannot. There is no API to call, no permission to escalate, no code path to exploit. The boundary is a property of the runtime, not a policy you configure.

What this means for you as a developer: you do not write security code. You do not handle API keys. You do not implement credential management. Your skill runs in userland. The OS handles everything below that line.

If your skill is compromised – prompt injection, malicious input, a bug in your code – it still cannot touch credentials, kernel resources, or other agents’ data. The isolation is architectural. This is the same model real operating systems have used for decades: userland does not touch hardware, the kernel mediates all access. The novelty is applying it to AI agents, where the “hardware” includes API keys and model endpoints.

This is not theoretical risk mitigation. When Moltbook, the social network for AI agents, was breached in early 2026, 1.5 million API tokens and thousands of plaintext passwords were exposed – because security was a database setting, not a structural property. Two SQL statements would have prevented the entire breach. BentOS makes that category of failure impossible by construction. Not through better configuration. Through an architecture where the dangerous code paths do not exist.

What ships today, what is coming

We believe developer trust starts with honest accounting.

Working:

• nanoben kernel with three-isolate security architecture
• CPU Protocol with NativeCpu (Dart) implementation
• The Standard Model: 15 XML terms, two-realm system, five-axis coordinate space
• Agent memory: wake/sleep lifecycle, .mem persistence across sessions
• ACCP communication protocol specification
• System Triggers specification (complete design)
• bentos-agent CLI (agent process runtime)

In active development:

• pkg-forge: the developer tool for creating and evolving atoms
• First-run UX and developer onboarding
• Flutter-based agent interface (HumanOS)

Designed, not yet built:

• JsCpu and WasmCpu runtimes
• System Triggers execution engine
• Community contribution pathways and open-source publishing
• Open-core release (runtime open, enterprise features proprietary)

The infrastructure is real and tested. The composition model works. What is missing is the developer-facing surface that makes building on the platform accessible to anyone outside the founding team. That is the current focus.

We have been building for over fifteen months. OpenClaw shipped in six weeks and found 147,000 users. We are not competing – OpenClaw is an application-layer agent framework, BentOS is an OS-layer runtime, and the stack needs both levels. But we recognize that an architecture without a developer community is a design document, not a platform. Shipping the developer experience is what turns this into something people actually build on.

The bigger picture

The agent ecosystem is young enough that the infrastructure layer is still forming. Communication standards, security models, composition formats – these are open questions that no single project will answer.

BentOS contributes infrastructure to that conversation. The ACCP communication protocol was designed over a year ago as an ecosystem standard, not a proprietary lock-in – it was published with an explicit invitation for collaboration before the current wave of agent frameworks existed. The bounded composition model is a proposal for how agent capabilities might be packaged, shared, and improved across the ecosystem. The CPU Protocol is an attempt at multi-language interoperability at the runtime level.

If you build agent skills, tools, or capabilities and want them to compose naturally with other developers’ work, improve through use, and run on a platform where security is structural and language is not a constraint – that is what we are building toward.

The architecture is ready. The developer surface is coming. The community starts now.

For developers who want their craft to compound.