How Sema4.ai works

A few ideas carry the whole platform. Read this once and the rest of the documentation will make sense.

Audience: all personas

Start with chat

Before any of the ideas below: the fastest way to do almost anything on this platform is to describe it in a conversation.

That is not just true of the work itself. It is true of building the thing that does the work. Attaching a data source, writing a Workflow, drawing a custom view, saving a memory, authoring a Skill, adding an email template: each of these has a form somewhere, and each of them can instead be asked for in plain English. The Context tree puts a Create in chat action on nearly every section for exactly this reason, and it opens the composer already pointed at the right kind of thing.

Create a workflow for this project that takes an inbound vendor email, looks the invoice up, and drafts a reply.

The agent proposes the change and you review it before anything lands. So the cost of asking is low, and asking is usually faster than finding the right screen.

Projects: where your work happens

A Project is a place for a piece of work that has data, files, people, and a deadline. A quarterly close. An audit response. A market analysis. An AP help desk.

It is the container for everything that work needs:

• The context. Files, the Instructions that set your team's norms, memories, schemas.
• The tools. Integrations, MCP servers, Skills, verified logic.
• The data. The Data Collections and data sources the work reads.
• The conversations. Shared with the team, so the work is not trapped in one person's window.

Once those are in place, you just start working. You walk through the work in conversation and the AI pulls data, runs analyses, and drafts outputs, using the context and tools you gave it. The Project tracks where things got to, so you can pick up where you left off and so can a colleague.

Knowledge accumulates as you go. Corrections you make, memories you save, refinements to the Instructions: they stay with the Project. Next quarter it starts smarter than it did this quarter.

When the work turns out to repeat, make a Workflow

Some of what you do in a Project happens once. Some of it comes back every week, and you notice you are walking the AI through the same thing again.

That is the moment to make a Workflow. You take the routine you have been doing by hand and write it down inside the Project: the inputs it needs, the steps it runs, the tools it uses, and what starts it. From then on it runs on its own.

A Workflow is not a different kind of object from the Project. It lives inside it and inherits everything the Project has: the same context, the same tools, the same data. That is why it is worth getting the Project right first. A Workflow built on a Project that already knows your vocabulary and has your data attached is a short description; the same Workflow with nothing behind it is a specification you have to write from scratch.

You do not have to start in conversation. If you already know the routine, describe it and the agent will author the Workflow directly. But most teams find the first version by doing the work a few times and then saying "do that, every time."

Work items: where you stay in charge

Every run of a Workflow produces a Work item, which keeps its input, its result, and the trigger that started it.

Work items are where your team picks the work back up: read what the AI did, correct what is wrong, and send it on. The Workflow does the routine at volume. The Work item is the point where a person is still deciding.

Corrections you make on a Work item feed back into the Project, so the next batch needs less correcting than the last.

Operate and Build: two lenses on one Project

A Project that has grown context, Workflows, and views serves two people asking different questions, so it offers two lenses.

Data Collections: the data you trust

A Data Collection is a workspace built around a specific set of data. Your administrator connects the warehouse or system of record once; you decide what belongs in the collection.

Three things make it more than a database connection:

• Queries run live against the source. Zero-copy: the data is not duplicated into the platform.
• It speaks your vocabulary, not your warehouse's. You define what a Customer, an Invoice, a Vendor, or Days Payable Outstanding means, and questions get translated into SQL for you.
• Answers carry their lineage. Every result records what query ran, who ran it, and what came back. Auditors get the trail rather than a paragraph in a memo.

For the questions that matter most, verified queries pin the SQL your team approved, so everyone gets the same answer.

A Project attaches the Data Collections it needs. If you are describing something your team does, that is a Project; if you are describing data your team owns, that is a Data Collection.

Your data, in the tools you already use

People do not do all their thinking in one place. Every Data Collection publishes an MCP endpoint, so the work you did building it is available from wherever someone is already working.

The connected tool does not get a database login. It gets your vocabulary and your approved queries, so an answer somewhere else is the same answer it would have been here.

Sai: the assistant that travels with you

Sai is a side panel available on every page. It reads the page you are on, so you do not have to explain where you are, and it can answer, suggest, or make changes you review before they land.

How they fit together

A rough shape for the AP help desk example:

1. Your administrator connects the ERP and the mail tenant. See Connections.
2. A builder creates a Data Collection over the AP tables, describes the vocabulary, and publishes a few verified queries for the questions that come up constantly.
3. The builder creates a Project for the help desk and the team starts working in it, answering vendor questions in conversation. The Data Collection gets attached the first time someone needs it, and Instructions get written the first time the agent replies in a voice the team would not use.
4. After a few weeks the shape of the work is clear, so the builder turns it into a Workflow: take an inbound vendor email, look the invoice up, draft a reply, flag anything that does not add up. A mailbox trigger feeds it.
5. The team moves to Operate. Each inbound email now arrives as a Work item. They review what was drafted, correct what is wrong, and send.
6. Corrections become memories the Project keeps, so the next batch needs less correcting.
7. Finance analysts working in their own AI tool connect to the Data Collection over MCP, and get the same answers without opening the platform.