From Copilots to Operators

How a fintech gave its engineering org a fleet of digital coworkers, and what building the platform taught us. Field notes from building Clarity, ClearTax's in-house AI agent platform.

TL;DR

ClearTax built Clarity, an internal platform that lets any team stand up production AI agents — "digital coworkers" that safely act inside real systems, not just suggest. It runs a few dozen today: a digital SRE that triages Sev1s in ~20 seconds, cross-team debugging agents, a security scanner that cut false positives (9 "HIGH" → 3 real), a data agent that turns change requests into merged PRs, and a plain-English metrics tool scoring 95%+.

The argument. The durable advantage in enterprise AI isn't the agent loop — that's a commodity you buy — it's the platform you wrap around it (governance, integration, durability, delivery). That layer is org-specific and can't be rented.
The shift. Copilot → operator. A copilot assists judgment; an operator executes delegated authority. Making that safe is a governance problem, not a modeling one.
The stack. A swappable Claude Agent SDK core loop · Temporal for durable orchestration · a Cedar policy engine (observe-before-enforce, fail-open behind a deterministic threat scanner) · per-user identity tokens · MCP into ~60 systems and 500+ tools · an org-written skill library (vibes, 67 skills) · and a self-maintaining runbook where usage is maintenance.
The surprise. A shared, governed platform became more than the sum of its agents: it made a large, siloed org legible to itself and built a commons that gets smarter every time it's used.
Kept honest. It's confidently wrong often enough that humans stay on the loop; governance coverage, cost controls, and the compounding loops are still maturing. A digital coworker is a force multiplier, not an engineer — and one that knows when to refuse.

Buy the primitives. Build the platform.

A few numbers to set the scene:

~20s — Sev1 first response, in-thread
9 → 3 — "HIGH" scan findings that were actually real
~19× smaller image after one fix (1.76 GB → 94 MB)
95%+ on a 176-case plain-English metrics eval

A Sunday morning that no human started

At 5 a.m. one Sunday, a production alert fired: one of our services had tipped past half its pods into CrashLoopBackOff. A Sev1. On most teams the next few minutes are a scramble. A phone buzzes, someone blinks awake, fumbles for a laptop, starts pulling up dashboards.

That is not what happened. About nineteen seconds after the page, a reply appeared in the incident thread. It had already pulled the incident record and cross-referenced the runbook for that failure class. By the time the on-call engineer acknowledged the page, a working hypothesis was waiting.

The responder was not a person. It was Clarity, the internal AI agent platform we have been building at ClearTax, and specifically the agent we treat as our digital SRE. It didn't summarize the alert. It acted: it reached into PagerDuty, our observability stack, and a shared library of runbooks, and ran the first pass of the investigation.

This post is about how we built that and what we learned. It makes one strategic claim, that the durable advantage in enterprise AI is not the agent loop, which is becoming a commodity, but the platform you wrap around it, and then it shows the work: the real architecture, the tradeoffs, and the things we got wrong. Take the argument, the blueprint, or both.

The real shift is copilot → operator

Most of the conversation about agents fixates on capability: can the model plan, use tools, write the code. Those questions are getting boring; the answer is increasingly yes. The question that reorganizes how you build is authority: what an agent may do on its own.

Ivan Peychev draws the line I find most useful. The shift that matters is from copilot to operator. "The copilot assists judgment. The operator executes delegated authority." A copilot sits beside a human who still clicks the button and merges the PR; an operator changes the system. And an operator without identity, scope, policy, evidence, the ability to refuse, and an audit trail is, in his phrase, "just a tool-connected model with borrowed credentials."

That reframes the job. A process needs a workflow; a role needs an identity, a scope of what it may touch, a way to escalate, and a record of what it did. Clarity is our attempt to staff roles and make staffing them safe. Almost everything hard about it turned out to be a governance problem, not a modeling one.

What Clarity is, in one paragraph

Clarity is an internal platform that lets any team at ClearTax stand up a production AI agent, a digital coworker that can safely act inside our systems. You reach one by mentioning it in Slack or opening its chat UI; it does the work and reports back, and it acts as the human who asked, with that person's identity and permissions, inside our own cloud boundary. Today it runs a few dozen such agents: a digital SRE that triages Sev1 incidents, a data-modelling agent that turns analysts' change requests into reviewed pull requests, debugging agents embedded in each product team's support channel, and more.

Under that surface, every agent shares one spine: a Claude Agent SDK core loop for reasoning and tool use, Temporal for durable orchestration, a Cedar policy engine for fine-grained authorization, an org-wide code graph that indexes every repository we have, and the Model Context Protocol (MCP) as the universal adapter into sixty internal systems, from observability and incident management to code, data warehouses, CRMs, and our own tax-filing and reconciliation platforms, exposing well over five hundred tools.

What it does across the org

It is easy to demo an agent; it is hard to make one busy engineers reach for under pressure. That is the test we care about, and the range of jobs Clarity has taken on is wider than we expected.

It runs incidents like an SRE and debugs across team lines. Alerts stream across eight or more service lines on a busy day; Clarity triages Sev1s in-thread, first response in the tens of seconds, running a first pass against the shared runbook library. Often its most useful output is that the problem is not ours: when a government tax portal we depend on starts failing, it says so with evidence, so nobody wakes a service owner for an upstream outage. In the product support channels it goes deeper. A ticket lands ("this return is throwing a duplicate-invoice error"), and the debugging agent traces it into that team's code, cites the file and line, checks git history, and delivers a verdict. Once it called a filing failure a portal-side rejection rather than our bug; days later the portal's own decrypted response matched.

It takes the noise out of security scanning. Static scanners flag too much, so Clarity runs a static pass and then a live, non-destructive probe against production that labels each finding real or false with HTTP evidence. On one service, nine "HIGH" findings collapsed to three; the rest were already blocked by the production auth layer. Confirmed findings become regression templates so a fixed hole cannot quietly reopen.

It turns change requests into pull requests: the analytics team's near-daily "add this column, change this logic" asks become reviewed PRs, most merged the same week. And it gives the whole company its numbers in plain English. Ask "what was the GST filing success rate in India last month?" and Clarity finds the right dbt model, runs a read-only query, and returns the number with the exact SQL it ran, so an analyst can check it, or pins it as a live, shareable dashboard rather than a throwaway answer. A 176-case benchmark for one domain scores above 95%, and when a question has no model yet, the gap routes to the data team, who add it, widening self-serve coverage for everyone: "every gap you raise makes the model smarter."

It also builds and teaches. Clarity wrote our internal security-scanning tooling end to end, root-causing its own CI build failures along the way, and it ships Terraform skills that catch drift and generate cloud resources pre-checked for least-privilege IAM. My favorite example is the most ordinary. A pod-init Sev1 turned out not to be a code bug at all: a 1.76 GB container image was cold-pulling for over nine minutes on a fresh node. Clarity explained why, then walked the team through multi-stage builds and standalone bundling. Weeks later they shipped it: the image dropped to 94 MB, nearly nineteen times smaller, and CI fell from three minutes to one. The agent had not closed a ticket; it had raised a team's baseline.

The reach is not only engineering. The same platform runs a Salesforce on-call agent, a customer-360 assistant, and CRM-enrichment agents, so sales, support, and operations draw on the same substrate as the SREs and the data team.

The capabilities were the point. The effect that surprised us showed up between teams.

The collaboration bridge

Every large engineering org has the same problem: teams are islands. The team behind authentication and internal comms knows those systems cold. Data Platform knows its warehouse models. The GST team knows its filing logic. Security knows the threat model. Support knows the customer's pain but not the code. The ferries between the islands, the threads and tickets and "can someone from X take a look," are slow and lossy.

Clarity became a ferry that speaks every dialect. The same agent identity shows up in all of those channels, each instance reading that team's repositories and wired to that team's tools. Because it reads code, it translates: support staff who do not write software file a ticket in plain language and get back a root cause with the file, the line, and a verdict on whether it is a bug, a data problem, or an upstream rejection. That is a clean hand-off to the owning engineer with nobody in the middle.

Teams have started putting it ahead of their own people. One team's on-call template now tells requesters to read Clarity's answer before paging the human rota; they slotted a digital coworker in as gated tier-0 in front of scarce senior engineers. We did not push that; a team reorganized its own escalation around it. And anyone can add one: a non-platform engineer installs a new agent from a template in a single click, no code deploy and no platform-team ticket. The platform team stopped building every agent and started paving the road.

The cumulative effect is quiet: the platform makes the organization legible to itself. A support person reaches into engineering's reality. An engineer gets a security verdict without booking a security engineer's hour. A co-founder asks the same agent, in the same thread, the same kind of question a first-week engineer would, and everyone reads the same grounded answer.

But a shared surface is only as good as the knowledge behind it, and knowledge left alone rots. Solving that turned out to matter more than any single agent.

The compounding commons: a skill library, and a runbook that maintains itself

Two contribution surfaces keep Clarity getting better without the platform team as a bottleneck. Both are things the whole org writes to.

The first is vibes, our shared library of Agent Skills: sixty-seven of them at last count, one per recurring job across every team's domain, from per-service debuggers and security scanners to metrics skills and meta-skills that improve other skills. The whole org contributes by pull request; skills ship through a small CLI and are versioned like any codebase, so when one team adds a skill, every other team's agents inherit it on the next sync. The platform team owns the road; the org co-builds what rides on it. Skills matter because that is where an organization's business logic lives, and business logic is what raw data and raw models lack. When we benchmarked the plain-English metrics tool, one query, a revenue figure that needs currency conversion, was accurate with the business-logic skill loaded and off by roughly 40% without it, because the data model has no currency column. Same question, same table; the skill carried the knowledge.

The second surface is the one I am proudest of, because it beats a problem every engineering org has lost to: the self-maintaining runbook. Every runbook, RCA, and knowledge base dies the same way. The cost of keeping it current outruns the value it returns, so the pages go stale and the real "we have seen this a hundred times, here is the fix" stays trapped in Slack threads and people's heads. Carving out doc-writing time never survives a busy quarter.

So we inverted it. Usage is maintenance: the runbook is built by using it.

Packaged as a framework in vibes and modeled on Andrej Karpathy's LLM-wiki pattern, it runs two loops. In the interactive loop you ask a question ("why are 502s spiking on my service?"). The agent reads your notes, the code, and live logs, answers with file:line citations, and asks whether to file what it just learned back into the runbook. In the autonomous loop, a scheduled "gardener" harvests the on-call channel's resolved threads twice a week, follows the linked ticket or PR to the real fix, redacts secrets and names, and opens a pull request a human reviews. It never merges.

The hard part is not generation. It is trust. An LLM that confidently writes a wrong runbook is worse than no runbook. What makes the auto-grown entries safe is that the trust gate is deterministic rather than another prompt: a fail-closed check requires every entry marked Verified to carry a verbatim quote from its source thread, and downgrades anything hedged or unquoted to Hypothesis. Code, not the model's judgment, is what stops the gardener from inventing specifics. Two more choices earned their keep. Runbooks are anchored to the on-call channel rather than the service, because at debug time all you have is a symptom and the channel it landed in, so the knowledge should live where you start looking. And the engine is global while the data is per-team, one plugin with each team's runbook in its own repo. The result is institutional memory that grows where it is used and gets smarter the more it is used.

The architecture

The principle underneath everything is a separation of concerns. Reasoning is a commodity we buy. Durability, governance, integration, and delivery are the platform we build.

The core loop, and why it is swappable. Every run executes through an executor. The default drives the Claude Agent SDK through its stateful client, so a permission callback fires on every tool call; that callback is where governance lives. A non-negotiable safety preamble is prepended to every agent's prompt. The important decision is that the loop sits behind a strategy seam: several executors run in production today (the Claude Agent SDK by default, an in-house executor, and a Gemini CLI executor), chosen per-agent by config, and open-model portability is real because the in-house executor carries a provider registry of roughly seventeen providers. Adding a model is a config row. That is the answer to "aren't you locked into one vendor": the reasoning layer is a replaceable part. A run can also fan out into parallel sub-agents; we have put the same question to a fast model and a strong one at once and compared depth against latency.

Temporal: durability without heroics. Agent runs are long, messy, and failure-prone, so every asynchronous run is a Temporal workflow with a deterministic ID derived from the Slack channel, thread, and event timestamp, which de-duplicates redelivered events for free. We wrap the entire non-deterministic run in a single activity, with a one-hour backstop and a self-healing ten-minute heartbeat, so Temporal's determinism never fights the SDK's messiness; the cost is coarser replay, which we accept. Delivery is decoupled from execution: the workflow writes events to Postgres, and the browser reads them over reconnectable SSE driven by LISTEN/NOTIFY, so a user can close the laptop mid-run and pick the stream back up later. Temporal owns durability; the database is the event bus.

Cedar: governance as code, shipped carefully. This is where the platform's real work lives. As Berkeley's California Management Review puts it, once agents become actors, "rather than asking whether agents are capable, the model asks whether they are governable." Authorization runs through the Cedar policy engine, assembled in three layers at load: a base policy for everyone, capability policies an agent opts into by name (bash-read-only, no-secret-exposure), and the agent's own grants and forbids. A detail worth stealing: the base layer is a blacklist, not a whitelist, allow-all plus platform-wide forbids, the key one scoping an agent to the channel and thread that triggered it. At runtime Cedar is the third check in the permission callback, behind a tool-name allowlist and a threat scanner, and it merges the server-trusted session context last so an agent cannot forge its own scope. Two choices define its posture. It observes before it enforces: by default it logs every allow and deny but blocks nothing, so you learn what agents actually do before enforcement risks breaking real work, the "earn autonomy against evidence" idea Google's SRE team calls progressive authorization. And it fails open: if the engine errors the call is allowed, acceptable only because the allowlist and threat scanner sit beneath it. A more paranoid org would choose differently; the point is to choose deliberately, and to audit daily what the policies did.

The threat scanner: a content-level guard. Cedar decides whether an agent is allowed to call a tool; the threat scanner, the layer in front of it, decides whether the call itself is dangerous. It is a deterministic, pattern-based inspector of tool-call arguments that fires before Cedar and blocks a call outright when the payload matches a known-dangerous pattern above a configurable risk threshold. It catches what identity-based authorization alone would wave through: filesystem destruction (an rm -rf on a system path, a dd onto a raw device, a Python shutil.rmtree), remote code execution (a curl piped into bash, an inline python -c), and secret exfiltration (reading an SSH private key, or posting a credential to an outside host). Two things make it more than a blocklist. It canonicalizes the command first, so obfuscation does not slip past a naive regex, and it parses the shell to separate executed code from inert data, so a dangerous-looking string that is only being echoed is not flagged. Cedar governs by identity and scope, the threat scanner by content, and together they are why observe-and-fail-open is a defensible default rather than a reckless one.

Agent identity, and its honest gap. When an agent calls an internal system, the platform mints a short-lived, per-user token so the call carries the requesting human's identity and least-privilege permissions, not a godmode service account. Attribution is clean and blast radius is bounded by a real person's real access. This works cleanly for MCP tools, where identity flows end to end and enforcement centralizes at a gateway. It works poorly for CLI tools like git and gh run through a shell, which authenticate with a baked-in token and carry no per-user identity; there, control drops to credential scoping and command allowlists, and the principled fix is to wrap CLI operations as MCP tools. We say so because a platform that hides its soft edges is not one you should trust.

MCP and self-serve. Clarity reaches sixty systems without sixty bespoke integrations because everything speaks MCP: you add a server as a Python class, a declarative YAML config, or a remote proxy, so "give the agents access to system X" becomes config, not a project. A few dozen agent templates ship in-repo, and installing one is a click that writes a record and auto-configures tools. The one place self-serve stops is Cedar: a genuinely novel agent needs a hand-written policy, and without one it falls back to the permissive base floor. That is a deliberate speed bump; we would rather a new agent's authorization get a human's eyes than let anyone mint an ungoverned operator.

Two pictures pull the pieces together: the shape of the platform, and what happens when you @mention an agent.

The shape of the platform, end to end. A trigger — a Slack @mention, a PagerDuty auto-ingest, or the chat UI — hits a webhook handler and becomes a Temporal workflow whose deterministic ID (channel + thread + event timestamp) dedupes redelivery. The workflow runs an executor (Claude Agent SDK by default), whose agent loop is assembled from a system prompt, a safety preamble, and skills pulled from the vibes skill library. Every tool call passes the permission callback — a tool-name allowlist, then the threat scanner (blocks by payload content), then Cedar (base + capabilities + agent policy; observe/enforce; fail-open), with a daily self-audit reading the decisions back. Once allowed, the call goes out under a per-user identity token through the MCP layer (~60 servers, 500+ tools) into observability (Grafana / Coralogix / Sentry), incidents (PagerDuty), the org-wide code graph, data (Athena / warehouses), CRM (Salesforce), and ClearTax domain systems (recon / GST / ingestion).

The path a single request takes, from an @mention to a reply:

The tradeoffs, and what we chose not to build

Every honest architecture post owes you the debits.

One durable activity versus fine-grained replay. We kept the workflow clean at the cost of coarse replay. Know your own failure modes.
Observe-before-enforce and fail-open. We optimized for shipping governance without breaking agents and lean on layered defenses to make fail-open acceptable. It is a real risk surface, and we accept it consciously.
A duck-typed executor seam, not a formal contract. Adding a runtime is cheap because there is no compile-time interface, and that looseness is debt we have a proposal to formalize.
Self-host over managed. We run the whole thing inside our own cloud boundary. For a fintech handling tax identifiers under Indian data-residency expectations, that was a requirement, and it costs us operational toil a managed product would absorb.

We were also disciplined about what not to build: we did not train our own model, did not hard-enforce authorization on day one, and did not give agents a shared superuser identity.

What we're still improving

Nothing here is finished. A few things we are actively working on, and would rather name than have you find:

It is confidently wrong often enough that you have to check it. This is the METR failure mode turned on ourselves. Clarity has produced file-and-line-cited analyses a human later disproved, and once assessed a security control at the application layer while missing that a network rule already covered it. The retraction protocol and human review catch these, but on a high-stakes call you cannot take its answer on faith.
Governance coverage is not uniform. Cedar governs MCP tools cleanly, but not every tool enforces authorization to the same standard yet, and shell CLIs still run outside per-user identity. The control plane is strong, not complete.
Cost governance is nascent. Agent runs are token-hungry; a single deep scan can burn a person's daily model quota, and we do not yet have mature per-team budgets or rate caps. At scale, spend becomes a governance surface of its own.
The compounding loops still bottleneck on humans. The runbook gardener never merges, roughly 40% of one recent week's policy flags were false positives, and the agent triages nearly everything but closes few hard tickets on its own. The flywheel is real but throttled by review bandwidth.
The long tail is brittle. Headless-browser automation flakes on some third-party portals, skill sync can overwrite a local patch, and the harness has occasionally answered a message twice or leaked internal scratchpad narration into a channel.

Two deeper questions sit underneath: how do you evaluate an agent whose surface area grows every week, and how do you weigh governance against capability when a security task legitimately needs the agent to do what the guardrails forbid. Neither is settled; the loops that keep them visible are how we make headway.

"Why build this? Just use a managed agent product."

Everyone asks this, and it deserves a straight answer.

The managed-agent market has matured. Anthropic runs a hosted harness with credential vaults and self-hosted sandboxes so tool execution can stay in your VPC; Cloudflare offers agents as durable objects at the edge; AWS Bedrock AgentCore, Google's Vertex Agent Engine, OpenAI's AgentKit, and LangGraph Platform each cover a layer. If you can buy this, why build?

Our answer is not "managed is bad." It is a distinction about what you buy and what you build: buy the commodity primitives, build the org-specific platform. Buy the inference. Buy or open-source the agent loop. But build the layer that is genuinely yours, because that layer is where the flexibility lives. Owning it means we can wire an agent into any of our sixty internal systems the week we need it, route a task to whichever model fits its cost and latency, and shape authorization to exactly how our org works, all on our own schedule instead of a vendor's roadmap. That control is the point, and you cannot rent it. It is also, not by coincidence, where the regulatory liability sits, which is the harder-nosed reason to own it: as one build-versus-buy analysis puts it, "there is no scenario where you transfer the regulatory liability." The clearest way to see where that line falls is against the two alternatives we weighed hardest: the agent loop itself, and the whole runtime.

The loop. "Buy or open-source the agent loop" was a real question for us, not a slogan. We tried adopting an open-source harness, pi.dev (the one PrimeIntellect's prime-agent builds on), in place of our Claude Agent SDK loop, and found enough gaps that we kept our default: it runs a different language stack with an embedded code-execution kernel, which adds an integration seam and a new prompt-injection surface, and its headline draw, open-model flexibility, we already have through our own provider registry. So we kept the seam and filed it as a deferred ADR.

The runtime: a Durable-Objects stack versus Clarity

The bigger question was the runtime, and Cloudflare's Agents are the strongest version of the "just buy it" case, so it is worth being specific about why we went another way. A sibling platform inside ClearTax ran the evaluation in depth against Cloudflare's "Think," a reasoning runtime built on Durable Objects.

A Durable-Objects design colocates state with compute: one durable actor per conversation, its own embedded SQLite, single-threaded execution that serializes turns. Clarity does the inverse and separates state from compute: durable orchestration in Temporal, stateless workers, and one shared store.

The actor model genuinely wins on several axes, and we concede them: per-conversation serialization for free, resumable token streaming, enormous concurrency with almost no operations work, and the fastest path to a chat product. But Clarity is an operator platform, not a chat product, and the things it is built on are the things the actor model makes hard:

A shared store, not a silo. One store lets us run multi-step task graphs, ask cross-conversation questions, and produce a regulator-grade audit trail, and stateless workers scale independently of any hot conversation. Per-actor SQLite silos all of that.
The control plane, owned. Durable Objects give you durable actors, not Cedar policies, per-user identity, a threat scanner, or observe-before-enforce. On a Durable-Objects stack we would have built the entire control plane anyway, and that, not the runtime, is the hard part we most needed to own.
Our boundary, not the edge. Durable-Object state and compute live on Cloudflare's edge in TypeScript; ours live inside our own cloud boundary, next to the sixty systems we integrate, behind a language- and model-agnostic seam.

The honest summary, borrowed from that evaluation: the actor model "buys serialization, locality, and cheap streaming," while separating state from compute "buys cross-conversation orchestration and compute that scales independently of state." For a fleet of governed operators, we wanted the second set. We do not reflexively build, and we do not reflexively adopt; we test the line against real alternatives before we commit.

The counter-arguments are real: managed is faster to start, someone else patches the injection holes, and managed harnesses track new frontier models automatically. That last is the sharpest, since a homegrown platform can fall behind. But Anthropic's own engineers argue that harnesses encode assumptions that go stale as models improve, which is why they built a managed one, and that supports our design: we buy the loop that keeps pace and build the layer that is ours. We drew the line rather than rejecting the vendor, and by shipping self-hosted sandboxes so execution stays in your boundary, the vendor is validating where the line belongs.

Buy the primitives. Build the platform.

How it raised the bar, and a necessary dose of humility

Step back from the architecture and the outcome is cultural. Governance-as-code became the default, and the platform grades itself daily, reading back its own authorization decisions and scoring its incident diagnoses against past runbooks. We grade the grader. Runbooks became living assets a digital coworker maintains, and the floor rose: code-grounded answers and tens-of-seconds incident response are the baseline now. The humans, meanwhile, moved up the abstraction ladder, from writing every line to, in Addy Osmani's phrasing, conducting one agent and then orchestrating a fleet. That ladder is not gated by title. With a capable platform beneath them, engineers earlier in their careers can operate with more context and confidence than their experience alone would give them, because the platform supplies the durability, the guardrails, and the institutional memory that seniority used to stand in for.

I want to be careful here, because this is where AI writing usually loses the plot. The evidence for autonomous engineering is mixed, and pretending otherwise would undercut everything else in this post. A controlled study by METR found that experienced open-source developers were 19% slower using early-2025 AI on large codebases they knew intimately, while believing they were faster. That perception-versus-reality gap is the most important humbling fact in the field. Independent trials of "autonomous engineer" products keep finding the same failure mode: plausible, well-structured code that does the wrong thing. The honest framing, borrowed from one such review, is that a digital coworker is not an engineer. It is a force multiplier.

That is how we treat Clarity. Humans stay on the loop: they set boundaries, review the PRs, approve escalations, and read the daily audit. It is telling that the same agent that beats a human to a Sev1 will also refuse. It has declined to bypass a live authentication control ("that's a control, not a bug"), declined to rewrite git history destructively, and retracted its own conclusion after re-reading the logs disproved it. A force multiplier that knows when to stop is worth far more than one that always says yes. Which returns us to that Sunday morning. The digital SRE did not replace the on-call engineer. It did the tedious first pass so the engineer arrived to a hypothesis instead of a blank dashboard.

The surprise was not that agents could do engineering work; everyone expected that. It was that a shared, governed, deeply integrated platform became more than the sum of its agents. It made a large, siloed organization legible to itself, and it built a commons that got a little smarter every time someone used it. We set out to build digital coworkers. We ended up building a bridge.

Clarity is ClearTax's internal AI agent platform. If you are building something similar and want to compare notes on governance, durable orchestration, the trust problem in self-growing documentation, or where to draw the build-versus-buy line, we would love to hear from you.