Last reviewed: 10 July 2026
Every organisation already has a layer that turns business knowledge into action.
Historically, that layer has been people. They understand the client, interpret a report, remember what happened last month, apply the exception nobody wrote down, ask for approval, and update the external system.
Generative AI can now perform parts of that translation. The important question is not whether a model can produce an answer. It is where the organisation puts the operating context, authority, interfaces, and history around that answer.
I call that the Operating Intelligence Layer.
The layer already exists, even when nobody has named it
Consider a recurring client-reporting workflow.
The visible output may be a dashboard or document. The operating work around it includes selecting the correct accounts and date range, checking data quality, remembering commercial context, applying client-specific rules, identifying exceptions, drafting commentary, routing it to the correct reviewer, and recording what was approved.
Much of that work lives between systems. Some is encoded in software. Some is written in process documents. A large amount remains in people's judgement and working memory.
An AI agent does not remove the need for this layer. It makes the need more explicit.
Once an agent can read data, call tools, or change an external system, the organisation needs to answer:
- Which identity is the agent acting under?
- Which workspace, client, or business unit does the work belong to?
- What context is valid for this run?
- Which tools and resources may it use?
- Which actions require approval?
- What happened, and who can inspect it later?
- Where do exceptions go?
- Who changes the workflow when the business changes?
Those questions are not model prompts. They are operating-system questions.
Model providers are becoming operating environments
The major AI providers are building increasingly capable enterprise workspaces. They connect to company knowledge, support custom agents, expose tools, and add administration and governance.
For many organisations, those products will be the correct place for broad employee productivity and common assistance.
But the provider also defines the product boundary: the primary interface, supported extension points, deployment options, administration model, and roadmap. The organisation configures a powerful environment, but does not own the environment itself.
That distinction matters when the workflow is unusual, operationally important, or part of how the organisation differentiates.
Business knowledge becomes valuable when it can be applied safely
Business knowledge is not only a library of documents.
It includes:
- the relationship between customers, accounts, projects, and systems
- thresholds and exception rules
- who may approve which action
- how judgement changes by context
- the sequence in which work should happen
- what evidence a reviewer needs
- which result counts as good
- what the organisation learned from earlier runs
Putting that knowledge to work requires more than retrieval. It requires tools, policy, interfaces, workflow state, and an audit trail.
This is why chat cannot be the only operating surface. People may need a queue of low-confidence records, a dashboard of scheduled runs, an approval view with source evidence, or a structured form for changing policy. The interface should fit the work rather than forcing every process back through a conversation.
The organisation should be able to own and reshape this layer
The stronger the layer becomes, the more business-specific value it accumulates.
Over time it contains private agents, evaluation cases, interfaces, approval rules, mappings between systems, internal connectors, workflow history, and decisions about how the organisation operates.
Those assets should not exist only as configuration inside one vendor workspace.
Ownership does not mean avoiding commercial models or external services. An organisation-owned layer can use OpenAI, Anthropic, Google, local models, and specialist services where each is appropriate. It can also use LangChain, LangGraph, Pydantic AI, or other orchestration frameworks internally.
The operating workflow should remain stable enough to change those components without moving the organisation into an entirely different product.
Why the foundation is open source
Praxis Agents OS is my attempt to make that organisational layer a shared open foundation.
The project is licensed under Apache 2.0 and built around workspaces, identity, agent execution, typed tools, skills, files, schedules, approval, audit, jobs, and controlled side effects.
It is currently an early-stage public build. Important product surfaces, including business-system integrations, knowledge, persistent memory, and artifacts, remain on the roadmap. The repository makes that incomplete state visible.
Open source matters here for practical reasons:
- the organisation can inspect the code carrying its operating process
- teams can self-host and choose their deployment boundary
- the runtime, persistence, interfaces, and policy can be changed below supported configuration points
- model and service providers can remain replaceable components
- generally useful improvements can be maintained once upstream
- the private implementation does not disappear if a commercial relationship ends
Open source does not automatically make a system secure, cheap, or easy to operate. It creates control and the responsibility that comes with control.
Open foundation, private capability
The intended boundary is the same as a private application built on an open-source framework.
Core runtime infrastructure, generally useful governance improvements, and reusable provider integrations can improve upstream.
The organisation's agents, instructions, views, workflows, business rules, private internal connectors, configuration, credentials, data, outputs, and operating history remain part of its private implementation.
Paying for implementation does not buy an exclusive licence to the underlying OS. Using the OS does not require publishing the private system built on top of it.
The roadmap should follow operating value
The commercial model around Praxis Agents OS follows the same distinction.
An Initial Implementation establishes a useful private deployment around the organisation's infrastructure, governance, systems, and first workflow.
An optional Ongoing Development Roadmap then expands what the organisation can reliably delegate: new agents, integrations, tools, views, policies, teams, and data sources, prioritised around actual operating value.
Maintenance supports that roadmap, but it is not the main reason for the relationship. The value is continued capability development around one organisation.
Business knowledge, put to work
Praxis means putting knowledge into action.
For AI agents, that requires a controlled path between what the organisation knows and what software is allowed to do. The layer includes people, policy, tools, interfaces, and records, not only a model.
Organisations should be able to own that layer when it matters to how they operate.
Praxis Agents OS provides an open foundation for building it.