What we deliver today, what is missing, and what we are building next

Where to start

Nothing on this page is a reason to wait

Talk to our experts → See the platform this runs on

The work that pays off first is the same work the agent framework needs underneath it. The earliest step and the groundwork are the same step.

Start with data liberation, then contextualize one process. Small is the point, because a model that is small and correct is already what a fleet of agents will read from.

  1. Liberate the data

    Historians, ERP exports, files on a share. Into one platform under AGPL-3.0, running where you choose.

  2. Contextualize a slice

    Assets, their readings, their events and the relationships between them, modeled once as an ontology. One process is enough.

  3. Put it to work now

    A connected model answers questions that used to take a day. Which series move together, what changed before the trip.

  4. Then add agents, ours or not

    Any agent that speaks MCP can read it today: one you build, one you buy, or one on somebody else's stack.

None of this ties you to our agent framework. Liberated, modeled data pays off wherever your agents run.

What we are building

A framework for a fleet, not one agent at a time

An agent already reaches your model through two MCP servers, inheriting the permissions of whoever it acts for. One agent is a project. Hundreds of agents is a different problem.

So we are building the layer underneath: functions an agent can call, policies that decide whether a call goes through, and coordination across the fleet. The rules belong in the platform, not in a prompt.

Agent Agent Agent Coordination: which agent runs what, and when Policies: what runs, what waits for a person Functions: the work an agent can call The data platform and its MCP servers Running today Being built

The two building blocks

Functions and policies, and what they unlock

Two pieces of platform work, worth having whether or not you ever run an agent. Both are half-shipped, not half-promised.

Functions

Model them today Run them next

A computation that lives in the model instead of in a spreadsheet. Today you can model one and wire what it reads to what it produces. Running it is the part being built.

  • One number per question. The same figure computed in three tools becomes one derivation everyone uses.
  • Expertise stays after people leave. The trick living in one engineer's spreadsheet keeps running, and the model records who wrote it.
  • Answers while they still matter. A windowed computation is minutes old. A nightly batch is a day old.
Functions in the documentation

Policies

Naming enforced today The other three next

Rules the platform holds for you: naming, retention, access, requirements. Naming is enforced today, checked on every write. The other three are recorded rather than enforced, and enforcing them is the part being built.

  • The rule lives with the data. Findable by whoever opens the data set, instead of sitting in a document they have to know about.
  • Enforcement becomes a switch. When it ships your rules are already written and attached, so you turn retention on instead of starting a workshop.
  • And it is what makes a fleet safe. The same mechanism decides what an agent may run alone and what waits for a person, per tenant and per data set.
Policies in the documentation

Around the two blocks

A person who decides

Where policy says a person decides, the call stops and waits, and the record shows who released it.

Coordination

Runs and failures recorded against the same model the agents read, so the second agent starts from what the first one changed.

In practice

What one rule can do with your data

Take one instrument as the example. You tell the platform what normal looks like: an acceptable range, a max value, a calibration interval. Everything below follows from that one sentence.

Parts of this chain run today: the events, and the model they land in. The watching and the acting are exactly the two blocks being built, which is why they sit on this page.

  1. You set the rule

    An acceptable range for a pressure reading. A max value for a temperature. A calibration interval for an instrument. Written once, in plain words, attached to the equipment it governs.

  2. The platform notices

    A reading drifts out of its range, and an event is created automatically: timestamped, and pointing at the exact instrument rather than at a tag number in somebody's list.

  3. It lands in your reports

    Events collect into the reports you already read, so the monthly deviation list writes itself instead of being pieced together by hand the day before the meeting.

  4. An agent picks it up

    An agent reads the event, sees the instrument is due for recalibration, and prepares the work permit with the details filled in. Approving it stays with your people.

The same pattern, more places

Quiet failures count too

Most trouble never crosses an alarm limit. A sensor that flatlines, drifts slowly, or repeats the same value for a week is caught by a rule about the shape of the signal, not just its maximum.

Not only sensor readings

Work orders, permits, inspections and deliveries land in the same event log. What has happened to this pump has one answer, with the paperwork and the readings side by side.

Numbers that show their working

A figure in a report can point back at the readings and events behind it. When an auditor asks where it came from, the answer is a lookup, not an archaeology project.

Honest about the gaps

What the platform cannot do yet

Every gap below is one our own documentation admits to. If one of them is blocking you, tell us which.

  1. In progress

    Nothing pauses to ask a person

    An agent can only reach what its access allows, so one you gave read-only access stays read-only. What is missing is the pause in between: if it is allowed to write, the write happens the moment it decides to. A step where a person approves first has to be built into the agent you write.

  2. In progress

    Nothing runs your functions and agents for you

    You can model a function today and wire what it reads to what it produces, but the engine that runs it, on a schedule or on live data, is still being built, and the platform does not host your agents either. Until then, both run outside the platform.

About dates

We are not going to put dates on this

We are a small team. A date we cannot hold would tell you less than this page already does, so we publish the order instead. The work lands in public, commit by commit.

Both documentation sites Follow the work on GitHub

Tell us what is blocking you

If you are trying to put an agent into production and one of the gaps above is in the way, we want to know which one. It is the most useful thing you can tell us, and it decides what we build next.

Talk to our experts →