Praxis

Inspiration

Praxis comes from our work on co-op, a local-first business management application we have been building to bring day-to-day business operations into one place.

co-op started with a fairly practical goal. Small teams often manage customers, inventory, invoices, expenses, tasks, documents, and other operations across several disconnected tools. We wanted to bring these workflows together while keeping the application local-first and allowing users to connect their own AI providers.

As we started adding AI capabilities to co-op, the problem became more interesting.

An assistant that can answer questions about a business is useful, but we wanted it to eventually perform actual work inside co-op. A request such as "follow up on unpaid invoices" may involve finding invoices, checking customers, deciding which records require action, drafting messages, updating records, and potentially interacting with an external service.

At that point, simply giving an LLM more tools did not feel like the right architecture.

That became the starting point for Praxis.

What it does

The current work is still at an early stage.

co-op acts as the first environment where we are exploring Praxis. It already gives us a controlled business application with real entities and operations such as customers, transactions, inventory, tasks, and other business records.

Praxis is the layer we are designing between an AI's decision and those operations.

Instead of allowing an agent to immediately execute every tool call it generates, we want to first represent the intended actions as a structured plan.

For example:

"Find overdue invoices → identify customers → prepare follow-ups → request approval → send → update records"

This representation gives us a point where we can inspect dependencies, permissions, approvals, and expected results before the actions reach the underlying application.

How we built it

The current implementation is based around co-op.

co-op is a desktop application built with a web frontend packaged through Tauri, with a Rust-based desktop layer and a backend used for services such as authentication and licensing.

The application is designed to remain local-first for business data while still allowing users to connect external services when required.

For AI, co-op follows a BYOK model. Users can connect their own supported model provider rather than depending on a single hosted model.

The early Praxis work focuses on exposing co-op operations as capabilities that an agent can reason about.

Instead of treating each function as an unrelated tool call, we are experimenting with describing what each capability requires, what it changes, and what should be true after it finishes.

From there, the next part is an intermediate representation for multi-step operations.

The intended flow is:

"Intent → Capabilities → Action Graph → Validation → Execution → Verification"

We are deliberately keeping planning and execution separate so the generated plan can be inspected before it changes business data.

Challenges we ran into

The main challenge came from deciding what an AI inside co-op should actually be allowed to do.

There is a large difference between allowing an assistant to answer:

"How much revenue did we make this month?"

and allowing it to execute:

"Find customers who have not paid, contact them, and update their records."

The second request crosses several operations and may have real consequences.

We also found that individual tool calls can look completely valid while their combination is not. An action may depend on another action completing first, require approval, or modify data that another step still needs.

This is what pushed us toward representing the complete action plan instead of validating isolated tool calls.

Accomplishments that we're proud of

co-op gave us a practical environment to explore these problems instead of designing an agent architecture around hypothetical workflows.

Because the application contains connected business entities, we can test AI interactions against operations where order, permissions, and side effects matter.

We are also happy with the local-first direction of co-op. Business data does not need to be moved into another AI product just to make the application useful, and the BYOK approach gives users control over which model provider they use.

Most importantly, building co-op exposed a problem that we think deserves to exist outside co-op itself.

That problem became Praxis.

What we learned

Our biggest learning was that adding more tools does not automatically make an agent more useful.

Once an agent can perform real operations, the important question changes from:

"Can the model call this tool?"

to:

"Should this sequence of actions be executed?"

We also learned that successful API or function execution is not necessarily the same as completing the user's goal.

A tool can return successfully while leaving the system in an unexpected state. This is why we want verification to eventually become part of the execution model rather than relying only on return values.

What's next for Praxis

Praxis is still early.

Our immediate goal is to continue using co-op as its first testing environment rather than trying to solve every agent platform at once.

We want to formalize the action representation, add dependency and permission checks, introduce approval boundaries for sensitive operations, and verify important state changes after execution.

Once that model works reliably inside co-op, we want to separate Praxis from the application and make the same approach usable with external capabilities such as MCP tools, Freshworks actions, and other APIs.

co-op is where we encountered the problem.

Praxis is where we are starting to work on the general solution.