What Is an Agentic Operating System? The Layers and the Handoffs

An agentic operating system is a business system where AI agents work next to people on the same records, with clear rules for what they may do alone and what needs a person. We describe it as five layers: records, communication, agents, permissions and an audit trail. The hard part is not the agent. It is the handoff between the agent and the person.

What does agentic mean here?

The Anthropic engineering team draws a useful line in its guide Building effective agents. Workflows are systems where models and tools are orchestrated through predefined code paths. Agents are systems where models dynamically direct their own processes and tool use. Agents suit open-ended problems where you cannot predict the number of steps, and the same guide says they should get ground truth from the environment at each step and can pause for human feedback at checkpoints.

An operating system adds the setting around the agent: who it works for, what it can see, who it can talk to and what happens when it is unsure. That setting is what makes an agent safe to leave running. On our comparison page we define an AI operating system as one place where a company records, communication and AI agents work together, so AI can do work across the CRM, email, documents and finances rather than inside one app at a time. OpenLazarus makes Lazarus, so read what follows with that in mind.

What are the five layers?

These are our working layers, a model we use to describe a system like Lazarus. They are not an industry standard.

• RecordsThe contacts, companies, deals, tasks, invoices and files of the business, in one place the company owns. Agents read and write these records instead of copies spread across other tools.
• CommunicationMail, messages and meetings. The OpenLazarus home page lists messages, mail, video meetings and scheduling among the modules, so people and agents can work from the same conversation.
• AgentsA named teammate with a job, a set of tools and a trigger. The trigger can be a schedule, an incoming email or a change in the records.
• PermissionsWhat each agent can see and do. As the OpenLazarus home page puts it, each AI sees only its own database. An agent gets only the access it was given.
• AuditA record of every agent run, so you can look back at what it read and what it changed. This is a layer to demand from any product, including ours.

How does work move between people and agents?

A handoff is the moment control passes from one to the other. Most failures in agent projects sit here: an agent acts when it should have asked, or asks about everything and turns into noise. A good system makes three things explicit: what the agent may do alone, what it must ask first and what it may never do.

Four mechanisms are worth looking for. First, a way to ask a person a short question with a few options, where the answer wakes the agent up again. Second, review before an action that cannot be undone, such as an outgoing email or a payment. Third, silence is never approval: if nobody answers, nothing happens. Fourth, a rule against loops, so that one agent reply cannot trigger another agent that triggers the first. This page does not describe how Lazarus implements each of them. Ask us, and ask any vendor, to show you.

What does a handoff look like step by step?

The table shows one handoff end to end. It is an illustration of how the layers fit together, not a description of a customer or of how a specific product works.

Notice what the person did: one decision, at the step where a price was involved. Everything else ran without them but left a trail. That ratio, few decisions at the right points and a full record of the rest, is what to look for in any system.

Why not just connect agents to the tools you already have?

You can, and for predictable steps a fixed workflow is the simpler choice: the path never changes, so it is easy to test. Agents suit the open-ended cases, where the next step depends on what the last one found. The cost of connecting an agent to many separate tools is that records, permissions and logs end up in many places. Each tool has its own copy of the customer, its own login and its own history. Then the person who has to answer the question what did the agent do last Tuesday has to look in several places. Putting the layers in one system is a way to answer that question once.

How do you evaluate an agentic operating system?

Ask these seven questions of any product, including ours. Write the answers down before you trust it with real customers.

• Where do the records live?And can you get them out in a form you can use?
• Can you see every agent run?What it read, what it changed, and when.
• Which actions need approval?And who is allowed to approve?
• What happens when nobody answers?The safe answer is nothing.
• Can one agent trigger another?If yes, how are loops prevented?
• What does each agent see?Scoped access is safer than shared access to everything.
• Who owns the system?The company running it, or the vendor.

If you want to see the layers applied to one job, the AI sales agent use case walks through it, and the agent library lists the ready-made teammates we describe today.

What changes for the people on the team?

This is our view, not a measured result. People spend less time doing each step and more time deciding at the checkpoints. That only works if the checkpoints are few and clear. A system that asks about every small action teaches people to approve without reading, which defeats the point of asking.

Where do you start?

Pick one job that a person does repeatedly and that has a clear approval point: sending quotes, chasing invoices or answering first-line support. Describe it to the designer in the OpenLazarus builder. It is free and needs no account, and the builder page says a first design takes about ten minutes, with a live preview beside the conversation.