Salesforce, NetSuite and HubSpot were built for humans to enter and read data. Their AI features are bolt-ons. We build the modules, the agents and the command center as one product, agent-first — humans supervise.
Every agent run is a closed loop. Context assembles from git, organizational memory and a semantic layer over your data sources. The agent reasons, calls typed tools, and produces artifacts that land in an approval inbox where humans supervise — approving, rejecting, editing, gating every outcome before it commits. Outcomes — state, learnings, artifacts, third-party actions, role refinements — feed the next cycle's context.
Most agent frameworks ship open-ended chains. Ours closes the loop — memory compounds run over run, and product iteration is a PR to a role definition, not a code change.
Agents work the same way whether the data lives in our shared database or in the tools you already use. Native modules give you a single-tenant schema, lightweight and built for agent traversal. MCP connectors expose your existing SaaS to agents as the same typed-tool API — no migration required. Mix both.
Built-in modules in your single-tenant database. Agents read and write directly through typed views — no integration layer, no ETL.
erp facturas · AR/AP · cash · bank reconciliation · periods live crm leads · pipeline · conversations · contacts wip operations deadlines · compliance · recurring filings · tasks planned Connect what you already use through Model Context Protocol servers. Agents see Salesforce, NetSuite, Stripe and the rest as the same typed-tool API as native modules.
salesforcehubspotnetsuitequickbooksstripegmailslacknotiondrivegithublinearasana + any MCP server Every artifact renders through one UI primitive: a versioned widget the agent emits as a tool call — the same primitive the approval inbox uses to show you what's waiting to be gated. Data fetch and render are separate, so the agent's reasoning stays visible — it chose what to render — and the same data tool can feed text replies, multiple widgets, or a subagent.
The agent calls a typed data tool, e.g. erp.list_overdue_facturas(days_overdue: 30), and gets back a clean dict of rows.
The agent emits a tool_use block for a widget — e.g. invoice_table_v0 — with those rows as input. The frontend has a React component per widget name and renders it inline in chat.
A widget is a React component the agent invokes by tool name. Here's what four of them look like rendered inline.
invoice_table_v0 shipped | Folio | Party | Amount | Days |
|---|---|---|---|
| 4523 | ACME Mining SpA | $850.000 | 45 |
| 4711 | Andes Logistics | $1.240.000 | 38 |
| 4801 | Norte Trading | $230.000 | 31 |
approval_card_v0 next ask_user_input_v0 next cash_position_chart_v0 planned
Every widget is suffixed _v0, _v1, and so on. When a widget's input schema changes, we add a new version — we never edit the old one. Old conversations keep working. New widgets are additive.
This is on-prem, local-first agentic enterprise software. Not multi-tenant SaaS. Customers deploy the stack into their own environment — their Mac, their server, their cloud. Whoever runs the deployment owns the data and the keys.
When customers want hosted-by-us, we run a dedicated per-customer stack. There is no shared infrastructure across customers, no shared schema, no row-level multi-tenancy. A breach of customer A has zero reach into customer B.
Tell us which work you want agents on. We'll go through your workflows with you and identify which are specific and checkable enough to hand to agents.
Talk to us