Praxis
Automate your organization with superintelligence. On your terms.
Tell us the work. We will tell you what can run on its own, what needs a person, and what it would take to prove either.
The capability arrived. The permission did not.
Nearly nine in ten agent pilots never reach production. Almost none of them fail because the model was not good enough.
They fail later, when the work meets real users, real data, real permissions, real policy and the exceptions nobody wrote down. Everything visible still looks right, so the failure is quiet, and the person who has to authorise it has nothing to point at. So they do not authorise it, and the pilot dies in review.
- The interface exists, but the workflow is incomplete.
- The happy path works, but no one owns the exceptions.
- The model is confident, but the evidence is missing.
- The application ships, but the original intent has quietly drifted.
Generation produces an artifact. Convergence produces a system.
One product, four jobs
Winning the customer, building the operation, proving it can be trusted and unblocking it when it stalls are four different problems. Most tools pick one of them.
Acquisition, customer intelligence and one coherent brand across every website, app, chat and storefront, selling only what the operation behind it can deliver.
Explore Atrium → Lattice Library Start from what already works.Reusable structure carrying workflows, roles, permissions, integrations, rules and tests, so a build begins with operational memory instead of an empty prompt.
Explore Lattice → Verity Harness Know what must be true.Turns the requirements that matter into constraints, scenarios, approvals and runtime evidence, and refuses to let a critical blocker average away.
Explore Verity → Relay Human fast track When autonomy stops, the work continues.A defined escalation path. The blocker is packaged with its context and evidence, routed to someone qualified, resolved, and returned to the build.
Explore Relay →All four run on our infrastructure, covered further down.
How a mission runs
- Declare the mission State the outcome, the people involved, the systems it must touch, the rules that govern it, and what has to be true before anyone can trust the result.
- Assemble with Lattice Praxis selects and adapts proven structure rather than rediscovering how permissions, approvals and integrations are supposed to work.
- Verify with Verity Critical requirements become machine-checkable constraints, simulated scenarios, and evidence attached to the claims it supports.
- Resolve through Relay Where the system meets genuine ambiguity, real risk, or an integration that cannot be safely inferred, a person decides and the reasoning returns with them.
- Ship, then keep converging Intent, implementation, evidence and running behavior change together. A change to the requirement reopens exactly the verification it affects.
What changes in your organization
Start with how the work moves today, then switch parts on in any combination.
The interesting change is not headcount or an org chart. It is who is waiting on whom. In most organizations people are the pipe: every request passes through one, the exceptions come back to the same queue, and the person accountable reads a report about a state that has already moved. Step through it and watch where each of the four people in the picture ends up. Switch one back off and the failure it was covering comes back.
No numbers in this diagram on purpose. Cycle times depend entirely on your operation, and inventing one here would be the exact failure our research is about. Bring us a real workflow and we will estimate it against your real constraints.
Where it runs
Everything you build here runs on our infrastructure: hosting, scale, regions and monitoring, without a platform team to hire first.
Going live is usually treated as the finish line. It is closer to the start of the risk. Whatever made a system safe to ship was true of a moment: the data it had, the policies in force, the model behind it, the volumes it was tested at. Change any of those and the approval on file describes a system you are no longer running.
Nothing outside production can see that happen. So the runtime keeps checking the conditions the approval depended on, narrows what the system may do when they move, and tells you while it is still cheap to fix.
- Deployment. One step from working to live, with the approvals attached to the exact version that shipped.
- Scale. Handle a launch or a seasonal spike without renegotiating what the system is allowed to do.
- Regions. Run where your data is allowed to live.
- Monitoring. Traces detailed enough to answer both the post-mortem and the auditor.
- Ongoing checks. Conditions rechecked, limits reset, drift surfaced before a customer finds it.
| Boundary | The split |
|---|---|
| Runtime and Verity | Verity decides whether the system may act, and for how long. The runtime is where it acts and what keeps the evidence flowing. Judgment and ground. |
| Runtime and Relay | Runtime on-call is uptime. Relay is human judgment on a blocker. Both are escalations; only one of them is a decision about what the software should do. |
What makes this a different category
Praxis is designed around the parts of software that only become visible after the demo: state, permissions, dependencies, exceptions, evidence, and change.
| Generation-first tools | Praxis |
|---|---|
| Optimize the first visible result. | Optimizes the whole operational trajectory. |
| Begin from a prompt or a blank canvas. | Begins from reusable operational structure. |
| Treat requirements as context for a model. | Turns critical requirements into living constraints and evidence. |
| Average many signals into a readiness score. | Keeps a critical blocker from disappearing inside an average. |
| Escalate informally when the AI stalls. | Provides a defined human path through Relay. |
Where this actually gets used
Praxis earns its place wherever the work has real rules, touches systems that already exist, and has someone accountable when it goes wrong. In practice that is most of how an organization runs: invoice reconciliation, refund authority, access reviews, prior authorisation, onboarding, dispatch, deal desk.
Every one of them looks simple until the exception. Forty-four of them are written out in detail, each with the reason it is harder than it looks.
Bring us the mission
Build what you mean.
Start with an outcome, a workflow, or a system that should exist. Tell us who it serves, what it has to connect to, which rules cannot bend, and what would have to be true before you would trust it to act.
Praxis, Lattice, Verity, Relay and Atrium are the architecture we are building toward. Ask us what runs today and what does not, and we will tell you plainly.