Open organizational runtime
For leaders who want to hand work to machines without handing over control. Taimen runs the work of your organization: it notices what needs doing, hands each piece of work to the best executor — a person, an AI agent or an automated process — checks the result and shows what it changed.
Fragment of the console, demo data. Work: approve payment of the Alpha Supply invoice, $2,400. Origin: the rule “Invoice received”, from a supplier email. Done by: the agent “Invoice parsing”, attempt 1. Proven by: auto-check, three of three — details, contract, budget. Signed by: waiting for the finance director, because the amount is above the $2,000 threshold.
Nobody can tell you who decided what — and what actually changed. With agents it gets worse: more work happens, and you can explain less of it.
Work is an obligation of your organization. It exists regardless of who performs it — and always answers five questions.
Models change; work, authority and history stay.
The same loop for people, agents and processes. The line is the machine. The dots are where a person decides.
Diagram of the loop: observe, derive work, delegate, execute, verify, measure the change — and the measured change becomes a new observation. People act at three points: they set the rules before the loop, sign off at the gate before verification, and can step in at any time.
Connectors watch the outside world: a procurement portal, accounting, repositories.
Rules and processes create work, and each piece names the rule and the observation behind it.
To the best executor: a person, an agent or a process.
Taimen records every attempt and every step.
A deterministic check first, then the state of the outside world, a person, and only then a model's judgement.
Money, time, risk, obligations.
The measured change becomes a new observation
Which observations create work, who may take it, which agents exist, what counts as done, who approves above which threshold. All of it is data in packages, reviewed and applied like code.
Checkable: every piece of work created by a rule links the rule evaluation and the observation behind it.
Example of a rule as data: an approval table. Invoices up to $2,000 are approved by accounting, above $2,000 — by the finance director.
No agent can be granted the right to decide an approval. The decision reaches the person where they already are, in Telegram today.
Checkable: the API rejects such a binding.
Fragment of the console, demo data. Zone “Awaiting your sign-off”: approve payment of the Alpha Supply invoice, $2,400. Why you: the amount is above the threshold. On “yes” the payment order goes to the bank; on “no” the invoice returns to the supplier with the reason. Delivered to Telegram.
Why the work exists, who did it and how, what proves it. An attempt can be stopped, work returned or reassigned, a process paused or rolled back.
Checkable: any piece of work answers “where from, who, with what rights, how accepted, what proves it” in one API call; an empty answer is a defect.
Fragment of the console, demo data. Provenance chain: an observation from mail — invoice received; the rule “Invoice received” created the work; attempt 1 by the agent “Invoice parsing”; verified by auto-check.
A person's own work goes through the same pickup, execution and acceptance; a personal assistant holds exactly its owner's rights.
Today: this holds for one person on a personal model subscription; an organization-provided model is next.
A person, an agent and a process go through the same three stages: pickup, execution, acceptance.
Counted separately, never summed.
We measure against your own baseline: how many human touches a closed case took before Taimen, and how many after. Rework and missed deadlines must not rise.
People move from searching, copying and chasing status to intent, decisions and responsibility.
Example
Notice appears on the portal
Screened by deadlines and company profile
Go/no-go goes to the head of tenders, with past cases attached
a person decidesPrice from memory, approved by the threshold table
a person decidesA person submits with their e-signature
a person decidesResult observed: win → contract, loss → lessons a person confirms
a person decidesPackage tested · awaiting a deployment with portal access
Demonstrated: invoice payment with a threshold decision table
Organizational memory
Processes and organizational memory are inseparable. Before a decision a process takes from the knowledge base what bears on it; after the decision it writes down how the case ended. The next case starts with that knowledge.
A process recalls before a decision: the counterparty, the contract, prior cases, prices, outcomes and lessons. After the decision it remembers what was decided, how the case ended and the lessons a person confirmed.
Every fact has a source it came from.
You see when a fact was true, not only that it was recorded.
A person and an agent see only what they are allowed to see.
AI proposes with citations; a person confirms.
a person confirmsWhat the memory knows — which kinds of things and how they relate — is described by an ontology. It is declared the same way as a process: a package adds a new kind, its attributes and its relations to what the knowledge base already knows.
In the claims example the package adds the claim and links it to the customer and the product, which the platform ontology already has. The process of the same package writes the case into memory and remembers the decision.
Example of an ontology declared by a package: the knowledge pack “claims” extends the platform ontology default@1, adds the kind “claim” with its attributes and the relations “filed by” to a legal entity and “concerns” to a product.
For leaders
For your implementation team
$ git clone --recurse-submodules https://github.com/taimen-ai/taimen.git && cd taimen
$ make secrets
$ make up
$ make bootstrapFor developers and integrators
To have Taimen run a tender department, invoice payment or customer claims, you don't write one more system. You describe how the work is organized: which process, which types of work, which rules create it, which agents and connectors do it, with what rights and where they run. That description is a package. The core executes it.
Example of a declarative description: the work rule “claim-reopened”. Its trigger is the observation that a helpdesk ticket was reopened; the condition excludes internal tickets; a skill classifies the text; the action creates work of the type “claim-followup” assigned to the role of claims officer.
A new approval threshold, another model for an agent, one more step in a process — an edit to a file, not a development project.
Before installation you get a plan of what will change on the stand. Exactly that plan is applied, and only after a person says yes.
a person approves the planA package lives in git. Scenarios of processes and rules are run by the code of the core in a sandbox — before the package reaches a stand.
A vertical has no runtime of its own. An integration needs code only where the outside system begins: an observer and skills.
With it you write the description — yourself or together with an AI assistant — check it, test it and install it.
Status as of 2026-10: version 0.1.0, under construction · Apache-2.0
$ package-sdk check
$ package-sdk test
$ package-sdk lock
$ package-sdk plan --install … --out plan.json
$ package-sdk apply --plan plan.jsonTaimen develops itself through its own loop. A connector notices a commit, rules derive work, agents described in data take it, a person reviews, a deterministic skill merges.
Status as of
Tell us what work you would hand to machines and which decisions you would keep. We'll take it apart together: where the work comes from, who does it, how the result is accepted.
Your request has been sent.
Prefer to write directly? mail@taimen.ai · Telegram @monthu