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.

That conversation does not have to happen here. With Bring your own builder, you can do the same building from Claude Cowork, Microsoft Copilot Cowork, or another AI tool you already work in, and Sema4.ai runs what you build.

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 sources the work reads, queried live where they live.
• 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, here or from your own AI tool. 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.

Your role decides what you see

Builders and admins change the Project: they see the Context rail, with everything the Project is made of. Members work the Project: they see its Views and its Work items, and so does everyone else who can open it. See Who sees what.

Build from the tools you already use

People do not do all their thinking in one place. Every workspace publishes an MCP server, so you can connect Claude Cowork, Microsoft Copilot Cowork, or any other MCP client and build from there: create Projects, write Workflows and their triggers, and handle the Work items waiting for you. What you build lands in the workspace, where your team can see it and Sema4.ai runs it.

The connection acts as you: it sees the teams you allowed when you approved it (all of your current and future teams, unless you chose specific ones), and only what your own permissions allow.

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 Project for the help desk and attaches the AP tables as a data source.
3. The team starts working in the Project, answering vendor questions in conversation. 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, in the Project or from their own AI tool through Bring your own builder: 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 works the Project from the Work items rail. 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.