Explanation

How Sonta AI fits together

Sonta is one model with several surfaces. Your business holds collections, collections hold entries, and entries point at each other. Your team, your agents, and your public site all work those same entries — nothing sits next to anything else.

Sonta is one model with several surfaces. Your business holds collections, collections hold entries, and entries point at each other. Your team, your agents, and your public site all work those same entries — nothing sits next to anything else.

Underneath, three layers stack in a fixed order, and each one only works because of the one below it.

The context

The bottom layer is everything your business knows, structured.

A business is the container — its own collections, its own team, its own agents. A collection is a kind of thing you keep. An entry is one of them. A field holds a value on that entry, and a reference points at an entry in another collection.

The vocabulary is the boring part. The part that matters is that you define it. Sonta does not hand you Leads, Contacts, and Opportunities and ask you to bend your work into them. If your firm runs on pursuits and retainers, those are the collections, with the relationships that actually hold between them.

Two things track the state of an entry, and they answer different questions:

  • Lifecycle stages say where an entry is in the work — a named, ordered, colour-coded set of stages on a collection, each classified as open, closed, or archived. "Inquiry → qualified → proposal → won" is a lifecycle. When a collection's stages are attached to a pipeline, those same stages carry forecasting on top — win probability, a forecast category — but the stage is the foundation and the pipeline is what builds on it.
  • Status — draft, published, unpublished — is a field on every entry. On its own it is just state. It becomes meaningful the moment a collection is connected to a website: the site can be granted read, write, or delete on that collection, and then status is what separates an entry the public sees from one it does not.

The two are independent: an entry can be published and still sit at an early lifecycle stage. Locations and departments live at this layer too, which is why a record can belong to an office and a practice rather than carrying the office name in a text field.

The agents

The middle layer does the work. An automation has two parts: a trigger, which says when it runs, and steps, which say what it does.

Triggers fire on things that happen in the layer below — an entry created, a field changed, a stage moved, a schedule arriving, an email landing. Steps act back on that same layer: send the email, update the entry, set the stage, call out to something else, branch, wait.

This is the mechanical answer to why the agents are not generic. They are not reading a summary of your business. They are reading the model itself — which listing, which candidate, which pursuit, and everything connected to it.

The processes

The top layer is how the work strings together: which stages exist, in what order, what happens on the way from one to the next, and where a person steps in.

A single automation is a reflex. The process is the shape of the whole motion — the thing that turns "a lead landed" into "a meeting is on the calendar and the record is current."

You own all three

The context, the agents, and the processes are yours as portable assets, not settings that live inside a vendor.

Model choice sits above all of it. Frontier models connect through MCP and equivalent open standards, each used where it is strongest, and the work keeps running on the same context when a better fit comes along. The layers are the durable part; the model is the swappable part. That order is the whole architectural bet.

One model, worked whatever way suits you

Everything that touches your business touches the same entries. What changes is the surface — and the surface is a convenience, not an obligation.

You, however you want to work. The same records are a table when you want a table, a board when you want to drag a deal along a pipeline, a calendar when you want to see the week, a form when you want to fill one in. Pick the view that suits the moment; it is the same data underneath.

Or you hand it to an agent. Anything you would do across those surfaces, an agent can do for you. There is a built-in AI interface in the CRM — you give an agent a task in the product and it carries it out, working the same records you would have. The human driving a UI is one option, not a requirement.

And it is the same over MCP. Sonta's whole surface is available through MCP — not just reading and writing entries, but building collections and fields, wiring references, composing automations and pipelines, configuring booking. This is how an agent operates the business the way a person does, and it is how your own tools connect. Same model, same operations, inside the same permissions a person has.

Your public site is a client too. It connects with its own access; you choose which collections it can reach and whether it can read, write, or delete each one. It reads what you publish — the catalog, the listings, the openings — and writes what it captures — leads, orders, booking requests. An order placed on your storefront is not imported later. It is created in the system, once.

Team, agent, MCP, public site: different ways in, one set of records. This is what "one context" means in practice, and it is why there is no sync step anywhere in it.

Why the order matters

Read the stack downward and it explains most of the product's decisions.

Processes need agents to execute them. Agents need context to act on. And context needs to be a real model — not a notes field — or everything above it degrades. A CRM that holds whatever someone remembered to type gives its agents thin, late data, and no amount of intelligence at the top compensates for that.

That is also why setup starts at the bottom. You describe what your business keeps, and the layers above have something to stand on.

Where to go next

To see what this is for, the page on what Sonta AI solves walks through the jobs it takes off a team. To check whether it fits your shape of work, there is a page on who Sonta AI is for. And if you would rather build the model than read about it, creating your first business takes about ten minutes.