Agent OS
The runtime layer that plans work, routes models, calls tools, stores memory and records a run trace across voice, WhatsApp and email.
An Agent OS is the layer that plans work, routes models, calls tools, stores memory, enforces policy and records a run trace. LoopNow's Agent OS runs voice, WhatsApp, email, workflow and GEO on one runtime.
An Agent OS is the layer that plans work, routes models, calls tools, stores memory, enforces policy and records a run trace. LoopNow's Agent OS runs voice, WhatsApp, email, workflow and GEO on one runtime.
All glossary terms
The short version
- An Agent OS is the runtime that sits between a business process and a language model: it plans the work, routes each step to a model, calls tools, stores memory, enforces policy and records a trace.
- It is not a model. The model is a component the runtime chooses and can swap. It is not agentic AI either, which names a capability class rather than the machinery that makes the capability safe to operate.
- Four things separate a runtime from a prompt wrapper: durable state, typed tool contracts, policy enforced outside the prompt, and a per-run trace that survives the model vendor changing.
- Channels are adapters on one runtime: a voice call, a WhatsApp thread and an email sequence differ in latency budget and consent, not in architecture.
- For an Indian team the runtime is where DPDP duties become code: consent artefacts, purpose tags, retention sweeps and human gates for money-moving actions.
- Buying a runtime is a bet on operability. Price the trace, the policy layer and the escalation path before you price the tokens.
Agent OS, defined as a runtime
An Agent OS is the execution layer for AI work. It receives a goal, decomposes it into steps, decides which model or tool handles each step, executes those steps with retries and timeouts, writes state so the work can survive a restart, applies policy before any consequential action, and emits a record of what happened. The model is one dependency inside that loop. The runtime is the thing that makes the loop operable.
The name is an analogy, not a claim about operating systems in the kernel sense. There is no process scheduler in the Linux meaning and no memory protection ring. What the analogy points at is real though: a shared substrate that many agents run on, with common services for identity, permissions, logging and resource limits, so that each new agent does not reimplement them badly. When a team has five agents built as five unrelated scripts, the absence of that substrate becomes obvious the first time one of them has to be audited.
What an Agent OS is not: it is not a foundation model, it is not a chatbot builder, it is not a CRM, and it is not a synonym for agentic AI. Agentic AI describes what a system can do, namely act in a loop. An Agent OS describes where that loop runs and what constrains it. A team can have agentic behaviour without any runtime, and that is exactly the situation that produces demos which cannot be audited, retried or priced.
The six jobs a runtime has to do
Strip away the marketing and six jobs remain. Plan: turn an ambiguous goal into an ordered set of steps. Route: choose a model per step, because a classification call and a negotiation call should not cost the same. Call tools: invoke a CRM, a billing system, a calendar or a knowledge index through a typed interface. Remember: hold conversation state and durable facts without leaking them across contacts. Enforce policy: block, redact, require approval or refuse. Record: write a trace detailed enough to reconstruct the decision a week later.
Each job has a failure mode that a demo hides. Planning fails when the model loops on a subtask. Routing fails when a cheap model is asked to do something that needs reasoning, and the failure is silent because the output looks fluent. Tool calls fail on timeouts and partial writes. Memory fails on contamination between contacts. Policy fails when it lives only in a prompt and a user talks the model out of it. Tracing fails when logs contain the prompt but not the tool result.
The test of a runtime is not how well it performs on the happy path. It is what happens on step four when the CRM returns a 500, the caller hangs up, and the run has to resume in an hour without sending a duplicate message. Durable state and idempotent tools are unglamorous and they are most of the engineering.
Agent OS is not agentic AI, and not a framework
Three terms get used interchangeably in procurement documents and they should not be. Agentic AI is a capability description: the system can take actions and observe results rather than only producing text. An agent framework is a library, such as a graph runner or a tool-calling helper, that a developer imports. An Agent OS is the operated service around both: identity, scheduling, memory, policy, metering and audit, with an on-call rotation behind it.
The practical consequence is that buying a framework is not buying a runtime. A framework gives you code to write; a runtime gives you services to configure and a trace to read. Teams discover the gap when they need to answer a question from a regulator, an auditor or an angry customer: which model saw this record, what did it send, who approved it, and where is the log. A framework has no opinion. A runtime has an answer.
Nor is an Agent OS an AI SDR. An AI SDR is a job description implemented as an agent: research accounts, score fit, run sequences, book meetings. It may run on an Agent OS, and usually should, but the OS is the substrate and the SDR is one workload on it. Confusing the two leads to buying a point tool and then discovering that the same policy, consent and trace requirements apply to the next four use cases as well.
Lifecycle of a run, from request to trace
A run begins with an envelope: who is asking, on which channel, under which consent, for which purpose, with what budget. That envelope is the most important object in the system, because every later decision inherits from it. A WhatsApp message from a contact who opted in for order updates cannot be answered with a marketing offer, no matter how good the offer is. The runtime enforces that by reading the envelope, not by asking the model to remember.
The run then plans, executes, checks and records. Steps that touch a system of record are idempotent and carry an idempotency key derived from the envelope, so a retry after a timeout does not create two orders or send two messages. Steps that spend money or make a commitment pass through a gate, which may be automatic under a threshold and human above it. When the run ends, the trace records the plan, each tool call with its arguments and result, latency per step, token and rupee cost, policy decisions, and any approval.
Resumption is the part teams forget. A voice call can drop, a webhook can arrive twice, an approval can take two days. A runtime that cannot pause a run, persist it and resume it later is a request handler, not an operating layer. The difference shows up in production, never in a demo.
Tools, MCP and the integration contract
A tool is a function with a schema, a permission scope and an owner. The schema matters because a model that guesses argument names will fail unpredictably; typed arguments with enums and required fields fail loudly instead. The scope matters because the same CRM tool should not be able to delete a contact when the agent only needs to add a note. The owner matters because every tool eventually breaks and someone has to be paged.
The Model Context Protocol has become the common way to describe tools to a client. It gives a standard shape for discovery, invocation and results, which means one integration can serve several agent clients instead of one. It does not solve authorisation by itself. A scoped key per workspace, per agent and per environment is still the operator’s job, and the useful default is read-only until a specific write is justified.
Two integration rules prevent most incidents. First, never let a model construct a raw query or a free-form URL. Offer enumerated actions instead. Second, make every write return the created object so the trace can prove what happened, rather than a bare success flag that proves nothing.
Memory that is allowed to exist
Memory is where agent systems quietly become a data protection problem. There are three kinds and they should be stored separately. Conversation state is short-lived and belongs to one thread. Contact facts are durable and belong to one person, which means they must be findable and deletable on request. Organisational knowledge is shared, and belongs in a retrieval index with its own access rules. Mixing them into one vector store is convenient for a prototype and indefensible in an audit.
Retrieval-augmented generation handles the third kind: the model is given passages from a controlled corpus rather than relying on model memory. That works only if the corpus has an owner, a refresh cadence and a way to retire stale pages. A knowledge base seeded once and never updated will confidently answer last year’s price. The evaluation for retrieval should include questions whose answer has changed, because those catch staleness that generic accuracy tests miss.
The DPDP Act adds a hard requirement: a data principal can ask what you hold and ask for erasure. If an agent’s memory is a pile of embeddings keyed by nothing in particular, you cannot honour that request. Store a stable contact identifier alongside every memory record, and make the retention sweep cover the vector index, the trace store and the backups, not just the primary table.
Policy, human gates and the audit trail
A guardrail that lives in a system prompt is a suggestion. The model can be persuaded, the prompt can be edited by someone in a hurry, and neither event leaves a record. Policy that matters has to be enforced in code, before the tool call, with a decision that is written to the trace. The four useful primitives are block, redact, cap and gate. Block refuses an action. Redact removes fields before they reach a model. Cap limits spend, volume or attempts. Gate pauses for a named human.
Human gates are the control that makes aggressive automation tolerable. They should be risk-based rather than universal: a refund under a threshold can proceed, a refund above it waits for a manager, a change of bank details always waits. Each gate needs an owner, a timeout and a default action on timeout, because a gate that nobody checks is a queue that silently stops work. The approval itself must appear in the trace with the approver’s identity and the exact payload they approved.
The audit trail is not the application log. It is a structured record with a stable run identifier, the envelope, the plan, each decision with its reason code, the tool arguments and results, and the cost. Retention should be stated and enforced, and access to it should be role-limited, because the trace contains personal data by design.
Channels are adapters on one runtime
The strongest argument for a runtime is that the same agent logic can serve several channels without being rebuilt. The differences are real but they are adapter-level. Voice has a sub-second response budget, no rich text and a hard requirement to handle interruption. WhatsApp has approved templates, a twenty-four hour service window and button-driven replies. Email has no latency pressure at all and a much higher tolerance for length. Web chat sits in between.
If the runtime is sound, switching channels means changing the adapter, the prompt variant and the policy envelope, not rewriting the agent. If it is not, each channel becomes its own codebase with its own bugs, and the customer who starts on WhatsApp and calls in gets treated as two strangers. Continuity across channels is a runtime property: the same contact identifier, the same consent ledger, the same open commitments.
The cost of getting this wrong is invisible until scale. Three channels built three ways means three trace formats, three retry policies and three answers to the auditor’s question about who approved the refund. Consolidation later is a migration project, and migrations are where consent records get lost.
What a runtime costs, and how to read the bill
Agent costs arrive on four meters: tokens, voice minutes, messages and seats. Tokens vary by step because routing sends easy steps to cheap models and hard steps to expensive ones, which is the main reason a runtime can be cheaper than a single-model script. Voice is billed per connected minute with ring time excluded. Messages are billed per delivered unit, and in India the WhatsApp category matters because marketing and utility rates differ substantially.
Published LoopNow plans start at ₹2,999 a month for Starter, ₹7,999 for Growth and ₹24,999 for Scale, all exclusive of 18% GST, with allowances for contacts, email, WhatsApp, voice minutes, AI tokens, agents and seats. Overage is published rather than negotiated after the fact, and a spend cap is on by default. The cap is the feature that makes an agent deployment politically survivable, because it converts an open-ended risk into a number a finance team can approve.
What the bill does not tell you is cost per resolved task, which is the only figure that matters operationally. Compute it by dividing total run cost, including model, channel and human review time, by the number of tasks that reached a correct end state without rework. A cheap runtime that escalates half its runs is expensive. An expensive one that closes them is not.
Build, buy or assemble
The build decision usually turns on three questions. How many distinct agents will you run in the next year? How regulated is the action they take? And do you have someone on call at eleven at night when a webhook stops delivering? A single internal agent writing summaries can be built on a framework in a week. Ten agents touching customers, money and consent need services that a small team will not maintain well while also shipping product.
Assembling is a legitimate middle path: a managed runtime for orchestration, policy and trace, with your own code for the tools that are specific to your business. That keeps the differentiated part in-house and buys the undifferentiated part, which is the correct trade in most cases. The failure mode to avoid is buying a runtime and then rebuilding its policy layer inside prompts because the configuration felt slow.
Whichever path you choose, insist on export. The trace, the consent ledger and the contact memory should be portable in a documented format. A runtime that holds your audit history hostage is not a platform, it is a lock-in with better marketing.
Measuring whether the runtime is working
Four measurements tell you more than any model benchmark. Trace completeness: the share of runs where every step has a tool result and a policy decision recorded. Task success: the share of runs that reached the intended end state, verified against a system of record rather than the agent’s own claim. Escalation correctness: the share of escalations that a human agreed were necessary, sampled and reviewed. Cost per resolved task, with human review time included.
Add two reliability numbers: p95 latency per channel, and duplicate-action rate. The second is the one nobody tracks until a customer receives the same WhatsApp template four times. It should be zero by construction, through idempotency keys, and any non-zero value is an incident rather than a metric to optimise.
Review the numbers weekly for the first month and monthly after that. A runtime that degrades slowly looks fine on a dashboard that only shows volume. The trace is the ground truth, and reading twenty traces by hand every week is still the best quality control available.
Worked example: one runtime across three channels
A Mumbai D2C brand sells a subscription product and handles about four thousand conversations a month across WhatsApp, voice and email. Before the runtime, each channel had its own tool: a WhatsApp bot with no CRM write-back, a voice vendor with its own scripts, and a support inbox with macros. A customer who asked about a delayed order on WhatsApp and then called got asked for the order number twice.
On a single runtime, the agent resolves the contact once, loads the order from the commerce system, checks the delivery exception, and answers with the same facts on any channel. The envelope carries the consent state, so a marketing template is blocked outside opt-in while a service reply proceeds. Refunds under five hundred rupees auto-approve, above that a human gate holds the run, and every decision lands in one trace with the order identifier attached.
The measurable changes are modest and specific: fewer repeated identity checks, a duplicate-message rate that goes to zero, and a trace an auditor can read. The runtime did not make the model smarter. It made the same model dependable, which is the only claim worth making.
Frequently asked questions
Is an Agent OS the same as an LLM?
No. The model is a component that the runtime calls, and a well-built runtime can swap it per step or per tenant. The OS holds state, permissions, tools and traces, none of which live in the model. Confusing the two leads teams to think a model upgrade is a platform upgrade, which it is not.
How is this different from agentic AI?
Agentic AI describes a capability: the system plans, acts and observes results. An Agent OS is the operated layer that runs that behaviour with durable state, typed tools, policy and audit. You can build agentic behaviour without a runtime, but you will end up rebuilding the runtime badly once you need to prove what happened.
Do we need an Agent OS for a single agent?
Usually not. A framework and a small service are enough for one internal agent that writes summaries or drafts replies. The case for a runtime appears when agents touch customers, money or consent, when more than two channels are involved, or when someone outside engineering starts asking for the audit trail.
Does it replace our CRM?
No, and it should not try. The CRM remains the system of record for contacts, deals and activity. The runtime reads and writes through tools, keeps its own run state and trace, and can be replaced without migrating the customer database. A runtime that wants to become your CRM is a much larger commitment than the problem requires.
How does DPDP apply to a runtime?
The runtime is where consent, purpose, retention and erasure become enforceable. That means a consent artefact attached to the envelope, purpose tags on tools, a retention sweep across traces and vector memory, and a deletion path keyed by contact identifier. LoopNow acts as a data processor for customer marketing data under the Act.
What does a run trace contain?
The envelope, the plan, every tool call with arguments and result, model and version per step, latency, token and rupee cost, policy decisions with reason codes, approvals with approver identity, and the final outcome. It contains personal data by design, so access is role-limited and retention is stated and enforced.
Can we self-host the runtime?
On the Enterprise plan LoopNow runs in a private VPC with custom models, which covers most residency requirements Indian teams raise. Full self-hosting is a different commitment: you take on upgrades, on-call and model routing. Ask whether the differentiator is the runtime or the tools you build on it before choosing that path.
How is usage billed?
On four meters: AI tokens, connected voice minutes, delivered messages and seats. Plans start at ₹2,999 for Starter, ₹7,999 for Growth and ₹24,999 for Scale, all exclusive of 18% GST, with published overage rates and a spend cap enabled by default so a runaway loop cannot produce an unbounded invoice.
What happens when a tool call fails mid-run?
The run pauses with its state persisted and retries according to the tool’s policy, using an idempotency key derived from the run envelope. If the retry budget is exhausted, the run escalates to a human with the partial trace attached. A run that cannot be resumed is a request handler, not a runtime.