The end of deterministic automation
For fifteen years we automated work by drawing it. That held while every step was predictable. It stops holding the moment a model sits inside the flow — and the answer is not a bigger diagram.
This is what we believe, and what we are building because of it. It is not a product page: there are no prices here, and nothing we could not show you in the code.
1. The deterministic era and its ceiling
Deterministic automation made a simple promise: same input, same path, same output. For moving a row from a form into a spreadsheet, that promise is exactly right, and nothing in this manifesto argues against it. Code that always does the same thing is the cheapest thing in software to trust.
The ceiling was never the code. It was the assumption underneath it: that someone could write down, in advance, every situation the flow would meet. For forms and webhooks they could. For a customer writing in their own words, a contract with an unusual clause, or a supplier who answers half the question, they can't — and every automation team knows the week the exceptions queue started growing faster than the flow.
2. Why visual graphs were a Web 2.0 patch
The visual builder was a real advance. It let people who don't write code wire together the APIs that Web 2.0 opened up, and it turned a flow into something you could look at. That is why it won.
But a canvas holds the happy path beautifully and everything else badly. An invariant — «this price must always come from the quote» — is not a step. Neither is a contract («this field is at most 4,000 characters») or a policy («never promise a date you cannot source»). None of them has a place on a diagram, so they get encoded as more branches, and the graph grows in the one direction it reads worst.
The tell is not the number of nodes. It is the day the team starts adding sub-workflows and code nodes: that is the canvas admitting it stopped being the representation. We wrote the long version in Workflows vs agents.
3. Dynamic LLMs: every branch becomes brittle
Put a language model inside that graph and something quieter breaks. A branch used to test a value the system produced: a status code, a field, a number. Now it tests text a model wrote. The condition looks the same on the canvas; underneath, it has become a probability.
The graph cannot show that. It draws «if category = refund» as the same clean fork whether the category came from a database or from a model reading an angry email. Every branch downstream inherits the uncertainty of the first one, and the diagram presents all of it as certain.
The usual fix is more branches: one for when the model says «refund», another for «reimbursement», a third for when it says both. That is drawing your way out of a problem that drawing created.
4. Bentho as an agentic substrate
The answer is not to hand everything to the model either. The best guidance available — Anthropic's included — says to start simple and add autonomy only where simpler solutions fall short. What changes is not how much determinism there is. It is where it lives.
A substrate is what the work stands on. Bentho's is a deterministic spine written in code, not drawn: it owns the turn, the money and the contracts. Models do what models are good at — reading, extracting, drafting — inside boundaries the spine enforces. Work whose length nobody can predict goes to bounded sub-agents, which hand back a typed result that the spine checks like any other input.
That is why we say «agentic» and not «agents»: the system delegates work to a model, and it never delegates the decision it is accountable for. By the strict definition, our own conversational orchestrator is a workflow — we have said so in public — and we think that is the point, not a weakness.
5. Runtime principles
Contracts, not trust
Every capability the system can call declares what it takes, what it returns and for which customer, and checks that before it runs. Input is validated at the boundary before anything decides. A capability that verifies who is asking cannot be talked into answering for someone else.
Memory belongs to the business, not to the run
An execution that holds a conversation in memory dies with it and grows with it. In Bentho, what the system knows about your business — your documents, your language, your rules — lives in a private space of its own, and each domain keeps its state in its own service. A run can fail without the system forgetting.
Humans where the stakes are
Handoffs and disputes stop at a deterministic interrupt for human approval. Not because the model is usually wrong, but because «usually» is the wrong standard for money and for someone's complaint. And before anything leaves, every figure in the answer must come from a source the system can name; one that can't is discarded, and a fixed template answers instead.
6. A call to alpha evaluators and founders
We are early, and we would rather be tested than admired. If you run a flow you no longer fully trust — the one with the exceptions queue, the one nobody wants to touch — we want to put Bentho against it with you, and publish what changes in the changelog.
If you invest in infrastructure and this is an argument you have been waiting for someone to make with code instead of slides, write to the founders directly.