One runtime. Every channel. Every decision visible.
LoopNow is not a chatbot plus integrations. It is an agent runtime with a shared context graph, a consent ledger, evals and a human approval gate.
Five layers, one trace.
Voice, WhatsApp, email, web, API
Same agent, same memory, same consent record. Switch channel without restarting the conversation.
Planner · router · tools · memory
Model routing by language, cost and latency. Tool calls are typed and auditable.
One customer, every touch
Leads, conversations, orders, invoices and consent in one graph — not six silos.
Evals · guardrails · approval
Policy checks, PII redaction, human gates and an approval audit entry.
CRM, tickets, revenue
Every run ends in a typed outcome, not a chat transcript. Export it.
Managed · private VPC · on-prem
AWS Mumbai primary. DPDP data map and sub-processors published.
The audit trail is the product.
Most agent platforms show a chat. LoopNow shows the run: which model, which tool, what it cost, which policy fired, who approved it, and where the consent record lives.
- Model router by language and cost
- Typed tool calls and retries
- Evals with pass/review thresholds
- Consent and PII handling per workflow
- Exportable JSON trace for auditors
ap-south-1, INR, GST, UPI
Built for Indian procurement, not retrofitted.
The short version
- LoopNow is a runtime, not a workflow builder with a model bolted on: every request becomes a run with a plan, routed model calls, typed tools, policy checks and a typed outcome.
- The context graph holds contacts, conversations, orders, invoices, consent and tickets as one record, so a second channel continues the conversation instead of restarting it.
- Governance sits before the prompt: purpose binding, tool allowlists, PII redaction, approval gates and a policy version stamped on every run.
- Every run exports as JSON with the model, prompt version, retrieved context, tool arguments, latency and rupee cost, which is what an auditor actually asks for.
- Deployment is managed on AWS Mumbai by default, with private VPC and on-prem available on Enterprise; the feature set for each is scoped in the contract.
- The honest limits: no SOC 2 or ISO 27001 claim on this page, no uptime number, and agent definitions export as JSON but do not port to another vendor’s canvas.
What an Agent OS is, and what it is not
Strip the category language away and an agent platform is a set of primitives. LoopNow has five: a run, a step, a tool call, a policy check and an outcome. A run begins with a trigger and ends with a durable record. Steps are the units of work inside it. Tool calls are typed, versioned and retried. Policy checks decide whether a step may proceed, needs a human, or must be refused. The outcome is a structured value that another system can act on.
That is deliberately less magical than the demos. The reason to build the primitives this way is that each one is individually inspectable. You can ask which model ran a step and why it was chosen, what arguments a tool received, which policy version was in force, and how long the step took. A system that only exposes a conversation cannot answer any of those questions, which is why agent pilots so often stall at the point where someone asks for evidence.
It is not a model, and it is not an agency engagement. You can bring your own model through the router, and Enterprise deployments support custom models inside your own environment. It is also not a replacement for your CRM. The platform writes into the systems of record you already run, with the CRM, helpdesk and commerce integrations doing the last mile rather than asking you to migrate your pipeline.
The runtime: planner, router, tools, memory
A trigger arrives, and the planner decides whether the request needs one step or several. A refund enquiry might need identity verification, an order lookup, a policy check and a reply, in that order, with the reply blocked until the order is resolved. The plan is recorded before execution, so a failed run can be replayed from the same starting state rather than guessed at from a transcript.
The router is where cost and quality meet. It selects a model using language, task type, context length and a latency budget. A Tamil address confirmation and a contract clause comparison do not deserve the same model, and paying premium rates for the first is how agent programmes lose their budget in month two. Routing decisions are per step, so one workflow can use a small fast model for extraction and a stronger one for judgement.
Memory is not a vector store with a friendly name. It is the context graph filtered by the purpose recorded for the workflow, plus the run’s own working state. Tools are declared with a JSON schema, a timeout, a retry policy and an idempotency key, which is what stops a retried booking from creating two appointments. When a tool returns something unexpected, the run stops and hands the case to a person with the payload attached rather than improvising a plausible answer.
The context graph is the system of record
Most Indian teams do not have a data problem so much as a joining problem. The order sits in Shopify, the invoice in Zoho Books, the conversation in WhatsApp, the consent in a form tool and the ticket in Freshdesk. Each system is correct on its own and useless in combination. The context graph joins them on a stable identity, so the agent sees one customer rather than five fragments with the same phone number.
Identity resolution is the hard part and it is deliberately conservative. A phone number is a strong signal in India, an email less so, and a name almost worthless. When two records conflict, the graph keeps both and flags the ambiguity rather than silently merging them, because a wrong merge is worse than a visible duplicate. Your team can resolve conflicts in the console, and the resolution is recorded like any other action.
The graph is also where consent lives, which is why it cannot be a read-only view stitched together at query time. Consent has to be writable, auditable and authoritative, because a withdrawal must propagate to suppression lists and to the agent’s own memory. Once the graph holds that, a data-principal request becomes a query with a known scope instead of a scavenger hunt across six vendors.
Channels: one agent, five surfaces
The same agent definition can answer on voice, WhatsApp, email, web chat and your own API. What changes per channel is the adapter, not the brain: voice needs streaming audio, barge-in handling and a transcript; WhatsApp needs template rules and a 24-hour service window; email needs a subject line and a plain-text fallback; web chat needs typing indicators and a session token. The agent’s tools, policy and memory stay constant.
Channel switching is the feature that exposes whether the architecture is real. A customer who starts on WhatsApp and calls an hour later should not be asked for the order number again. On LoopNow the second conversation opens with the first one in context, and the agent can say what was already agreed. That sounds like a small thing until you are the customer repeating yourself to a machine at 9pm.
Each channel also carries its own compliance surface. Voice recording needs consent before it starts, and the transcript is retained on the schedule set for that workflow. WhatsApp templates pass Meta review, and the SMS side of a fallback flow uses DLT-compliant templates. Email needs a working unsubscribe and a lawful basis. The platform enforces these per channel because a rule that lives only in a prompt will eventually be edited away by someone in a hurry.
Governance before the prompt
Prompt engineering is not a control. A well-written instruction can still be overridden by a determined user or a bad retrieval, so the platform puts enforceable rules outside the model. Purpose binding limits which parts of the graph a workflow may read. Tool allowlists decide which actions exist at all. PII redaction strips identifiers before text leaves for a model provider. Approval gates stop a specific class of action until a named person signs off.
The design principle is that a model may propose but may not authorise. It can propose a refund, a discount, a booking or an escalation. Whether that proposal becomes an action depends on policy: amount thresholds, customer tier, channel, time of day, or the presence of a verified identity. When policy says no, the run records the refusal and the reason, and the customer gets a straight answer instead of a promise the business will not honour.
Policy is versioned like code. Each run records the policy version it evaluated against, so a change on Tuesday does not make last week’s behaviour unexplainable. This matters more than it sounds during an audit: the question is rarely what the rules are today, it is what they were when the decision was taken. A version stamp turns that from an interview into a lookup.
Evals: how you know it improved
An eval set is a list of real cases with an expected property. Not an expected sentence, because there are many correct ways to phrase a booking confirmation. The property might be that the correct order id appears, that no discount is offered, or that the call is transferred within two turns. Sets are built from your own transcripts, which is the only corpus that reflects how your customers actually write and speak.
Every change to a prompt, a tool schema or a model route runs against the set before it can be published. Results fall into pass, fail and review, and the review band is where most of the value sits: cases that are neither clearly right nor clearly wrong are the ones a human should look at. A change that improves the average but breaks the refund policy is a regression, and the gate should stop it.
Before a workflow takes full traffic, it can run in shadow mode against live inputs with its actions suppressed. You see what it would have done without anyone receiving a message. That is the cheapest way to find the edge cases that a curated eval set missed, and it is how a team builds the confidence to remove a human review step later. The numbers in the figure are illustrative sample data, not a benchmark of your workload.
The run trace and observability
A run record contains the trigger, the plan, every step, the model and prompt version used, the retrieved context references, each tool call with arguments and result, policy decisions, token counts, latency and rupee cost. It is written as the run executes, not reconstructed afterwards, which is why a failed step still leaves evidence. The console renders it as a timeline; the API returns the same thing as JSON.
The export is the point. Auditors, client security teams and internal risk functions do not want a dashboard screenshot, they want a machine-readable record they can sample. A JSON trace can be filtered, stored in your own data lake and compared across months. It can also be redacted according to your own rules before it leaves the platform, so the observability feature does not become a second data protection problem.
Retention is configurable per workflow rather than fixed globally, because a support transcript and a payment decision have different obligations. Old runs are swept on the schedule you set, and the sweep is itself logged. If you need traces retained for seven years for a regulated process, that is a conversation to have during design, not after the first audit request arrives.
Deployment models
The default is managed: your workspace runs on AWS Mumbai, ap-south-1, alongside the platform, with data residency in India and the operational work handled by us. Updates arrive continuously, the model catalogue is current, and there is nothing for your team to patch. This is the right default for almost every team below a few hundred seats, and it is what the 48-hour go-live estimate assumes.
Private VPC puts the runtime inside your own cloud account, with the platform managing the control plane and your team owning the network boundary, keys and egress rules. It is the common choice for BFSI and healthcare buyers whose security review will not pass a shared environment. On-prem goes further, running without outbound dependency on our infrastructure, and it brings its own model serving and upgrade cadence.
The honest caveat is feature parity. A private deployment does not automatically get every managed feature on the same day, and model access depends on what your environment allows. The contract scopes the feature set, the upgrade window and the support boundary, and we would rather write that down than let a sales deck imply that on-prem is identical. Ask for the deployment annexure before you assume.
Failure modes and the retry ladder
Tools fail in ordinary ways: a CRM returns a 500, a telephony provider drops a leg, an OTP expires. The runtime treats these as expected rather than exceptional. The first attempt runs immediately, the second backs off, the third backs off further, and only then does the case leave the automatic path. Retries carry an idempotency key so a duplicated booking is not the price of resilience.
Model failures are different. A timeout can be retried on the same route. A malformed tool argument means the model misunderstood the schema, which a retry will usually repeat, so the run falls back to a constrained prompt or a deterministic path instead. A refusal is recorded as a refusal, not retried until it complies. That distinction matters in regulated work, where an agent that changes its answer under pressure is a liability.
When the ladder is exhausted, the case lands in a human queue with the payload, the error and the trace attached. The customer is told something true, such as a person will call within the hour, rather than something plausible. The measure we care about is not the failure rate but the recovery rate: how many exhausted runs end with a correct outcome after a human touches them, and how quickly.
Integrations and the API surface
The integration surface is deliberately small: REST for writes and reads, signed webhooks for events, an MCP server for tools that live outside the platform, and SMTP for transactional mail. The OpenAPI description is published, SDKs wrap the common calls, and webhooks are signed so your endpoint can reject anything that did not come from us. If your stack is unusual, the API is the escape hatch rather than a services contract.
Native connectors cover the systems Indian teams actually run: Salesforce, HubSpot, Zoho and Freshsales for CRM; Shopify and WooCommerce for commerce; Razorpay and PayU for payments; Freshdesk and Zendesk for support. Each connector declares its scopes up front, so a security reviewer can see exactly what the agent may read and write before anything is switched on.
Webhooks are replayable, which is the detail that saves an afternoon. If your endpoint was down when an event fired, you can re-deliver it with the original signature and timestamp rather than asking us to fabricate a new event. That, plus the JSON trace, means the platform can be debugged from your side without a support ticket and a screen share.
Data residency, DPDP and the limits of our claims
Primary storage and processing are in AWS Mumbai, ap-south-1. Consent is captured at ingestion with the purpose, the wording and the timestamp, and a withdrawal propagates to suppression and memory. Retention is set per workflow, and a data-principal request has a defined path through the console rather than an email to support. A data map and a sub-processor list are published so that your review starts from facts instead of a questionnaire.
What we do not do is print certification logos we have not earned. This page makes no SOC 2 or ISO 27001 claim, and it quotes no uptime percentage, because those are specific attestations with a scope, an auditor and an expiry date. If your procurement needs them, ask for the current security pack and you will get the documents that exist, dated, with the gaps named honestly. That is a slower conversation and a more useful one.
The same discipline applies to language coverage and latency. The voice agent handles 14 Indian languages with a median response of 420ms in the India region, measured as p50. A median is not a worst case, and a language list is not a guarantee of equal quality across every dialect. Test with your own callers, in your own accent mix, before you commit to a volume that depends on it.
Lock-in, export and the exit path
Agent and workflow definitions export as JSON, along with prompts, tool schemas, policy versions, eval sets and the contact graph with consent state. That is a complete description of how your automation behaves, and it is enough for another team to re-implement the logic. It is not a file another vendor’s canvas can import, because no such interchange format exists, and claiming otherwise would be the sort of thing you discover at the worst moment.
The API is the same one we use internally for the managed console, which means nothing in the product is reachable only through a screen. Webhooks replay, traces export, contacts move with consent attached, and API keys are yours to rotate. If a feature is available in the interface but not in the API, that is a bug worth reporting rather than a deliberate lock-in strategy.
Exit is coordinated rather than abrupt. Access closes at the end of the notice period, a retention sweep runs on the agreed schedule, and records that tax law requires us to keep, such as invoices, stay where they must. Everything else is deleted or returned with written confirmation. A WhatsApp number takes about a week to release because Meta and the receiving provider are involved, so start that step first.
Frequently asked questions
What is the difference between an agent and a workflow?
A workflow is the container: a trigger, an ordered set of steps, and the rules about what happens when a step fails. An agent is the reasoning unit inside those steps, which decides which tool to call and how to phrase a response. You can run a workflow with no agent at all, using deterministic steps, and many production flows mix both so that the predictable parts stay predictable.
Which models does the router use, and can I pin one?
The router selects from the models available to your workspace using language, task type, context length and a latency budget, and it records the choice on every step. You can pin a model for a specific workflow when you have measured a reason to, and Enterprise deployments can bring custom models into their own environment. Pinning everything is usually slower and dearer.
How do you stop an agent doing something it should not?
Four layers, in order. Purpose binding limits what context it can read. Tool allowlists limit what actions exist. Policy checks decide whether an action may proceed, needs approval or is refused. The spend cap limits the financial damage of a loop. None of those depend on the model obeying an instruction, which is the point of putting them outside the prompt.
Is the run trace exportable, and in what format?
Yes. A run exports as JSON containing the trigger, plan, steps, model and prompt version, retrieved context references, tool arguments and results, policy decisions, token counts, latency and rupee cost. You can pull it through the API into your own store, and redaction rules can be applied before export so observability does not create a second data protection problem.
Where is data stored and processed?
Primary storage and processing are in AWS Mumbai, ap-south-1, for managed workspaces. A data map and sub-processor list are published so your review starts from documents rather than a questionnaire. Private VPC deployments keep the runtime in your own cloud account, and on-prem runs without an outbound dependency on our infrastructure. Data residency terms are set in the contract.
How fast is a voice turn, really?
The median is 420ms in the India region, measured as p50. A median is not a worst case: a bad network path, a long context or a model fallback will produce slower turns. Test with recordings of your own callers before you commit to a volume, and watch the p95 rather than the average when you review the trace after go-live.
Can we run this in our own VPC or on-premises?
Yes, on Enterprise. Private VPC puts the runtime in your cloud account with the platform managing the control plane, and on-prem removes the outbound dependency entirely. Both change the upgrade cadence and can narrow model access, so feature parity is scoped in the deployment annexure rather than assumed. Expect a security review before a pilot either way.
How does consent work technically, not just legally?
Consent is a record attached to a contact and a purpose, with the wording, channel and timestamp captured at ingestion. Workflows declare a purpose and can only read context covered by it. A withdrawal writes to the graph, propagates to suppression lists and reaches agent memory, so the next campaign and the next conversation both respect it. The whole chain is visible in the trace.
What happens when a tool call fails?
It retries with backoff and an idempotency key, up to three attempts, so a duplicate booking is not the cost of resilience. Malformed arguments are not retried blindly, because the model will usually repeat the mistake; the run falls back to a constrained path instead. After the ladder is exhausted, the case goes to a human queue with the payload and trace attached.
Are you SOC 2 or ISO 27001 certified?
We do not claim either certification on this page, and we do not quote an uptime figure, because those are attestations with a scope, an auditor and an expiry date. What we can evidence today is data residency in Mumbai, consent records, retention controls, audit exports and a published sub-processor list. Ask for the current security pack and the gaps will be named.