Most enterprise AI systems reset to zero after every interaction. They repeat the same mistakes indefinitely, because nothing they learn in one session survives into the next. The frontier trend in 2026 is the fix for exactly that: AI persistent memory — systems that record what happened, verify it into durable facts, distil those facts into reusable rules, and consult that knowledge the next time round.

This is self-improvement, and the crucial thing to understand about it is that it’s a property of the system, not the model.

Self-learning is not self-improvement

The two terms get used interchangeably, and the confusion is expensive. Self-learning means updating the model weights: retraining or fine-tuning so the underlying network changes. That’s slow, costly, hard to govern, and rarely what an enterprise actually needs. It also doesn’t explain how a system gets better between two runs of the same fixed model.

Self-improvement is different. Here the model stays constant, and the system around it compounds. The intelligence doesn’t live only in the weights; it lives in what the system has accumulated, written down, and can read back. A frozen model paired with a growing body of verified knowledge outperforms the same model working from a blank slate every time. The lesson for AI leaders is direct: you don’t have to touch the model to make the system smarter. You have to give it a memory.

The memory progression: from failure to rule

Persistent memory isn’t a transcript log. A dump of past conversations is noise, and feeding it back verbatim degrades performance rather than improving it. What compounds is a disciplined progression that turns raw experience into knowledge the system can trust.

The progression looks like this. First, the system records a failure or a notable event — something didn’t work, or worked in a surprising way. Second, it investigates the cause rather than reacting to the symptom. Third, it verifies the finding into a fact, confirming the cause is real and reproducible rather than a one-off coincidence. Fourth, it distils that fact into a rule — a compact, general statement of what to do or avoid. Fifth, and most important, it consults that rule the next time a similar situation arises.

Each stage filters signal from noise. A single failure is an anecdote. A verified fact is evidence. A distilled rule is reusable judgement. By the time knowledge reaches the rule stage, it’s small, general and safe to apply — which is exactly what keeps the accumulated memory from bloating into an unusable pile.

Durable state: read at the start, written at the end

For any of this to work, the system needs somewhere to keep what it knows between sessions, and a discipline for using it. We call this durable state: a persistent record of facts, rules and context that survives across runs.

The operating pattern is simple and strict. Durable state is read at the start of every task, so the system begins already knowing what it learned before, and it’s written at the end, so anything new is captured before the session closes. Without the read step, the system is amnesiac by default. Without the write step, hard-won lessons evaporate the moment the interaction ends. Getting both halves right is what separates a system that compounds from one that merely appears busy.

Durable state also needs structure and hygiene. It should be curated, deduplicated and pruned, because stale or contradictory entries actively mislead. Good memory isn’t the largest memory. It’s the most trustworthy.

Reusable procedures and independent verification

Facts and rules are the passive layer of memory. The active layer is reusable procedures: encoded, repeatable ways of doing recurring work, refined every time they run. When a system encounters a task it has solved well before, it shouldn’t reinvent the approach. It should retrieve the proven procedure, apply it, and improve it if the outcome suggests a better path. Over time the system builds a library of methods that get sharper with use — compounding in its most tangible form.

None of this is safe without independent verification. Memory that writes itself unchecked will confidently preserve its own mistakes, and a wrong rule consulted repeatedly is worse than no rule at all. So the promotion of a finding into a durable fact, and a fact into a rule, must be gated by a verification step separate from the step that produced it. The component that checks is not the component that acts. That separation is what keeps a self-improving system honest, and it’s the difference between compounding knowledge and compounding error.

Put these pieces together and the headline holds: self-improvement is a property of the system, not the model. The weights never changed. The system got better because it remembered, verified and reused.

How Wohlig helps

Wohlig Transformations is a Google Cloud transformation and AI partner. We design and build agentic AI systems that carry durable state across sessions, capture verified facts and rules, encode reusable procedures, and gate every promotion with independent verification — all engineered on Google Cloud so the system genuinely improves the longer it runs.

If your AI initiatives reset to zero after every interaction, we can help you build systems that remember and compound instead. Talk to Wohlig about engineering persistent memory and self-improving AI on Google Cloud.

For years, the promise of DevOps was that developers would own their software from commit to production. In practice, many teams landed somewhere else: engineers who wanted to launch a service still filed tickets for a cluster, a database, a certificate, a network rule and a set of credentials, then waited days or weeks for each one. Every team reinvented its own pipelines, and the cognitive load moved onto developers rather than away from them.

Platform engineering is the response to that friction. Instead of expecting every engineer to become an infrastructure expert, a small platform team builds and operates an internal developer platform (IDP): a curated, opinionated layer of self-service capabilities the rest of the organisation consumes. The guiding metaphor is the paved road. You’re free to go off-road when you have a genuine reason, but the paved road is fast, well-lit and safe, so most teams choose it most of the time. That choice, made willingly and repeatedly, is what turns scattered best practices into consistent outcomes.

What a paved road actually looks like

An internal developer platform isn’t a single product you install. It’s a set of capabilities that work together to remove decisions and delays from the everyday path to production.

• Golden-path templates. A developer starting a new service selects a template and gets a working, opinionated starting point: a service scaffold, a pipeline, health checks, logging and sensible defaults already wired in. The blank page disappears, and so do dozens of small, inconsistent decisions.

• Self-service, not ticket-service. Provisioning an environment, a database or a message queue happens through a portal or a command, governed by policy rather than by a human approver in the loop. The platform encodes what’s allowed, so approval is built in.

• One identity through single sign-on. Developers authenticate once, and that identity flows through the tools, environments and cloud resources they’re entitled to. Access is tied to roles and groups, which makes both onboarding and offboarding fast and auditable.

• Declarative desired state, reconciled automatically. Teams describe the state they want in version-controlled configuration, and the platform continuously reconciles the running system toward that state. The desired state is the source of truth, changes are reviewed like any other change, and drift is corrected without manual intervention.

• Quality gates. Automated checks for tests, code quality, vulnerabilities and policy compliance run on every change. Progression to production is earned by passing gates, not by informal sign-off.

• Zero-code observability. Logs, metrics and traces are collected by default, so a new service is observable the moment it runs, with no manual instrumentation required first.

• Security by default. Least-privilege access, managed secrets, encrypted data and hardened baselines are part of the template, not an afterthought bolted on before launch. Doing the secure thing is also the easy thing.

The point of these capabilities isn’t control for its own sake. It’s to let a developer go from an idea to a running, observable, secure service in production without stopping to file a request or make a decision someone else has already made well.

The developer experience, from idea to production

Consider the difference in practice. Without a platform, launching a new service means requesting compute, negotiating network access, standing up a database, wiring credentials, building a pipeline and adding monitoring — each step often owned by a different team. With an internal developer platform, the same developer chooses a golden-path template, commits code, and the platform takes over: it builds and tests the artifact, runs it through quality and security gates, provisions the declared dependencies, deploys to the target environment, and turns on observability. The developer reviews a merge request and watches the change flow to production.

The experience is fast because the slow parts are automated, and safe because the guardrails are always on. Crucially, it’s self-service without being a free-for-all. The platform team decides what good looks like once, encodes it into templates and policy, and every team inherits it. When standards change, they change in one place and propagate outward. This is how platform engineering delivers speed and governance at once, rather than trading one for the other.

How Wohlig builds internal developer platforms on Google Cloud

Wohlig maps each capability to a managed Google Cloud service, so the platform team spends its time on developer experience rather than on undifferentiated operations.

• Managed Kubernetes provides the runtime for containerised workloads, with autoscaling, hardened defaults and a consistent target for every golden-path template.

• Managed databases and managed secrets give teams production-grade data stores and a secure home for credentials, provisioned declaratively and accessed through identity rather than through shared passwords.

• CI/CD turns every change into a repeatable, gated journey from commit to deploy, so releases are routine rather than events.

• GitOps-style continuous delivery treats version-controlled declarative desired state as the single source of truth. The platform continuously reconciles the live environment toward that state, which makes deployments reviewable, repeatable and easy to roll back.

• Single sign-on and least-privilege access unify identity across the platform, and built-in observability makes every workload measurable from its first deployment.

We start by understanding how your teams work today, where the friction and the ticket queues live, and what your compliance and security requirements demand. From there we design the golden paths, encode your standards into templates and policy, and build the platform incrementally — proving value on a first set of services before scaling across the organisation. The result is a paved road that reflects your context rather than a generic blueprint.

If your engineers are still waiting on infrastructure tickets, and your leaders are still choosing between speed and governance, an internal developer platform can give you both. Talk to Wohlig about designing and building a paved road that helps your teams ship faster and more safely on Google Cloud.

Most enterprise AI initiatives don’t fail because the model was too weak. They fail because the data feeding the model was never ready. A frontier model can reason brilliantly and still produce confident nonsense when the underlying tables are stale, duplicated, undocumented, or scattered across systems no one fully trusts.

This is why the conversation has shifted. Through 2026, Google Cloud and other industry leaders have consistently named data readiness and orchestration — not model choice — as the real competitive differentiator in enterprise AI. Models are increasingly commoditised and interchangeable. Your data estate is not. It’s the one asset your competitors can’t copy, and it’s also the one most likely to quietly sabotage your AI ambitions.

For CTOs and data leaders, the strategic question is no longer “which model should we use.” It’s “is our data ready to be used at all.”

What enterprise data readiness actually means

Data readiness isn’t a single dashboard or a one-time cleanup project. It’s a set of durable properties your data estate needs to hold, continuously, for AI and analytics to be trustworthy. Five of them matter most.

Clean, layered models. Raw data should never be consumed directly by analytics or agents. A disciplined warehouse separates concerns into layers: a raw zone that preserves source data exactly as it arrived, a staging zone where data is cleaned, typed and standardised, and a curated marts layer that exposes business-ready tables with clear definitions. Layering makes transformations transparent, testable and reproducible.

Freshness and quality checks. Ready data is data you can date. Every consumer should know how current a table is and whether it passed validation. Automated checks for nulls, duplicates, referential integrity and value ranges catch problems before they reach a model or an executive report.

Governance and access control. Readiness includes knowing who can see what. Sensitive fields need to be protected at a granular level, and access needs to follow the principle of least privilege rather than blanket table permissions.

Discoverability. If people can’t find a trusted dataset, they’ll rebuild it, badly. A catalogue with clear ownership, descriptions and business definitions turns a warehouse from a dumping ground into a usable product.

Lineage. When a number looks wrong, you need to trace it back to its source. Lineage that maps how data flows from ingestion through every transformation is what makes debugging, auditing and compliance possible.

Why readiness is the precondition for agents and analytics

Agentic AI raises the stakes on all of this. A dashboard shows a human a number, and a thoughtful analyst can sanity-check it. An agent acts. It queries your data, reasons over it, and takes steps: drafting responses, triggering workflows, updating records. If the data it reads is wrong or the access it holds is too broad, the mistake propagates at machine speed.

That means the qualities above stop being nice-to-haves. Freshness determines whether an agent is acting on today’s reality or last quarter’s. Quality checks determine whether it inherits your data errors as facts. Access control determines whether an agent can be trusted with a query at all, or whether it might surface data a user was never permitted to see. Lineage determines whether you can explain and defend what the agent did after the fact.

In short, agents inherit every weakness in your data foundation and amplify it. Readiness is what keeps that amplification working in your favour.

Common pitfalls that derail data readiness

A few patterns show up again and again in enterprises that struggle:

• Treating readiness as a project, not a practice. Teams do a heroic cleanup, declare victory, and watch quality decay because nothing enforces it going forward.

• Skipping the layered model. Pointing reports and agents straight at raw or lightly processed data feels faster but creates fragile, unexplainable pipelines.

• Governance bolted on last. Retrofitting access control and column-level security after data is already widely exposed is far harder than designing it in from the start.

• No single source of truth. When every team maintains its own definition of “active customer” or “revenue,” AI outputs become impossible to reconcile.

• Invisible data. Without a catalogue and lineage, institutional knowledge lives in a few people’s heads, and every new use case starts from zero.

None of these are exotic. They’re the default state of a data estate that grew organically without a foundation designed for it.

How Wohlig builds a foundation that makes AI work

Wohlig Transformations is a Google Cloud transformation and AI partner. We treat data readiness as the groundwork for everything else we build — from agentic AI to analytics to internal developer platforms.

On Google Cloud, that foundation centers on BigQuery. We design a layered warehouse with a clear raw, staging and marts structure, so that source data is preserved, transformations are transparent, and business teams consume trusted, well-defined tables rather than raw feeds. We embed automated data quality checks into the pipeline so freshness and validation are continuous rather than occasional.

Governance is designed in from the beginning. We use IAM to enforce least-privilege access and column-level security to protect sensitive fields, so the right people and the right agents see only what they should. We build for discoverability and lineage, so datasets have clear owners and definitions and every number can be traced back to its source.

The result is a data estate where AI isn’t a gamble. When the foundation is clean, layered, governed and observable, agents and analytics have something solid to stand on, and the model finally becomes the easy part.

If your AI roadmap is outpacing your data foundation, that gap is where projects quietly stall. Talk to Wohlig about assessing your enterprise data readiness and building the foundation your AI strategy actually depends on.

Ask any security operations leader what keeps their team up at night and, before they mention nation-state actors, they’ll mention volume. A modern enterprise security operations center (SOC) ingests signals from cloud workloads, endpoints, identity providers, network telemetry and dozens of SaaS tools. The result is a firehose of alerts, most of which are benign, duplicated or low priority.

In 2026, AI agents are starting to absorb the most repetitive part of that work — alert triage, enrichment and first-pass investigation — so human analysts can focus on the judgement calls that matter. But the model only works with strict guardrails: least-privilege read access, human approval for any response action, and a full audit trail.

The alert fatigue problem is a people problem

Alert fatigue is the predictable outcome of that firehose. When analysts triage hundreds of alerts a shift, attention degrades, real threats get buried in the noise, and the genuinely dangerous signal is more likely to be closed as routine. The cost isn’t only missed detections. It’s also burnout, high turnover in a role that’s already hard to hire for, and slower response when speed matters most.

The traditional answer was more tooling and more headcount. Neither scales cleanly. Tuning rules reduces some noise but introduces blind spots. Adding people is expensive and slow, and it still leaves skilled analysts doing work that’s beneath their expertise. This is the gap that AI security operations is built to close.

What AI agents actually do in the SOC

The useful framing isn’t that agents replace analysts. It’s that agents take the first, most repetitive pass so analysts start their work already informed. In practice, that breaks into three jobs.

Triage. When an alert fires, an agent can classify it against context the analyst would otherwise gather by hand. Is this asset internet-facing? Is the identity involved privileged? Has this pattern fired a hundred times this week and always resolved as benign? The agent groups related alerts, deduplicates, and assigns a preliminary severity so the queue arrives sorted rather than raw.

Enrichment. A raw alert is rarely enough to make a decision. An agent can pull the surrounding context automatically: recent activity for the user or service account, the reputation of an external IP, the configuration of the affected resource, and related events across other tools. What used to be twenty minutes of tab-switching becomes a structured summary attached to the alert.

First-pass investigation. For well-understood alert types, an agent can follow the same investigative playbook a junior analyst would — querying logs, correlating timelines, and forming a hypothesis about whether the activity is malicious. It then hands the analyst a narrative: here’s what happened, here’s the evidence, here’s what I think, and here’s what I’m not sure about.

The through line is that the agent does the reading, gathering and drafting. The human does the deciding.

Guardrails are not optional

An AI agent with broad access to security systems is itself a serious risk. The value of AI security operations depends entirely on the guardrails around it. Four are mandatory.

Least-privilege, read-only by default. Investigation requires reading logs and telemetry, not changing them. Agents should operate with narrowly scoped, governed read access to exactly the data sources their task needs, and nothing more. Access is granted per use case, reviewed, and revocable.

Human approval for every response action. Reading is one thing. Acting is another. Isolating a host, disabling an account, or blocking an address can disrupt the business as much as an attacker can. Any response action must be proposed by the agent and approved by a human. The agent recommends, the analyst authorises, and that boundary is enforced by design, not by policy alone.

Full audit and explainability. Every query an agent runs, every conclusion it reaches, and every action a human approves must be logged in a tamper-resistant record. When a decision is questioned later — whether in an incident review or a compliance audit — the team needs to reconstruct exactly what the agent saw and why it acted. An agent that can’t show its work doesn’t belong in the SOC.

Bounded scope and continuous evaluation. Agents should be scoped to specific, well-defined tasks with clear success criteria, and their performance should be measured over time. False negatives and overconfident conclusions are tracked and corrected, and humans retain oversight of where and how agents are deployed.

Treat these as the price of admission. An agent that triages fast but can’t be governed is a liability, not an asset.

Keeping humans in the loop, on purpose

“Human in the loop” is easy to say and easy to hollow out. If analysts rubber-stamp every agent recommendation because the queue is still overwhelming, the guardrail is theatre. The design goal is to raise the quality of human attention, not just its speed.

That means agents should surface uncertainty honestly, flag the cases they’re least confident about, and escalate anything ambiguous rather than forcing a verdict. It means the most consequential decisions — confirming a breach, taking a production system offline, notifying stakeholders — always sit with a person who has the context and the authority. The agent compresses the routine so the human has room for the exceptional.

How Wohlig helps

Wohlig Transformations is a Google Cloud transformation and AI partner, and we build security operations automation the same way we build the rest of our agentic AI work: governed, auditable and human-directed.

On Google Cloud, we help enterprises bring together posture management, threat detection and vulnerability scanning, then layer agentic workflows on top for triage, enrichment and first-pass investigation. We design least-privilege access models so agents read only what they need, wire in mandatory human approval for response actions, and make the full audit trail a first-class part of the system rather than an afterthought. The outcome is a SOC where analysts spend their time on the calls that require judgement, and the repetitive work runs itself under a watchful eye.

If you’re a CISO or security leader looking to reduce alert fatigue without giving up control, talk to Wohlig about building AI security operations on Google Cloud, with humans firmly in the loop.

In most enterprises, a business question travels a long road before it becomes an answer. A stakeholder asks something, an analyst joins a backlog, a dashboard gets scoped, and a week later a report lands that answers a question the business has already moved past. The friction isn’t the data warehouse itself — BigQuery scales beautifully. The friction is the queue of humans and tools that sit between the question and the query.

Conversational analytics removes most of that queue. Instead of standing up heavy BI infrastructure for every new line of inquiry, a person types a question the way they’d ask a colleague. An AI assistant interprets the intent, writes the SQL, runs it against BigQuery through a governed connector, and returns a live chart, table or interactive widget the person can read immediately. Follow-up questions refine the same thread, so exploration feels like a conversation rather than a series of tickets — and because the assistant queries through your existing IAM, column-level security and audit logging, you get the speed without loosening control.

How conversational BI on BigQuery actually works

The pattern has a few moving parts, and none of them ask you to move your data off Google Cloud.

At the front is a natural-language interface. Someone asks, “What was revenue by region last quarter, and how did that compare to the quarter before?” The assistant doesn’t guess at an answer. It translates the question into SQL grounded in your actual schema, table descriptions and business definitions.

Behind that sits a connector to BigQuery. The generated query runs as a real BigQuery job, using the caller’s identity and permissions. The assistant then takes the returned rows and renders them: a bar chart when a comparison is implied, a table when detail matters, or an interactive widget when someone will want to filter and drill down. Because everything happens in one turn, the person can immediately ask the next question, and the assistant carries the context forward.

The key design principle is that the AI writes and executes queries, but it doesn’t become a new, ungoverned door into your data. It queries through the same controls you already trust.

Governance is the feature, not an afterthought

For a CTO or data leader, the first question isn’t “Can it answer?” It’s “Can it answer safely?” Conversational analytics done properly leans on the governance primitives Google Cloud already provides, rather than inventing a parallel security model.

Identity and access management decides what each person can query. When the assistant runs a query, it runs under a governed identity mapped to the requester, so someone who can’t see a dataset in BigQuery can’t see it through the assistant either. Access doesn’t widen simply because the interface changed.

Column-level security and data masking mean sensitive fields stay protected regardless of how a question is phrased. If a column is restricted, the assistant can’t surface it, and no clever prompt reroutes around the policy — because the policy lives in BigQuery, not in the chat layer.

Auditability closes the loop. Every query the assistant runs is a logged BigQuery job, visible in Cloud Audit Logs like any other. You can review what was asked, what SQL ran, who it ran as, and what it touched. That record is what turns a convenient tool into one your security and compliance teams can sign off on.

The layered data model that makes answers trustworthy

Conversational answers are only as good as the data model underneath them. Pointing an AI assistant at raw, inconsistent tables produces fast answers that are quietly wrong. A layered model prevents that.

The raw layer holds source data as ingested, unchanged, so you always have fidelity to the system of record. The staging layer cleans and standardises: consistent types, deduplicated records, normalised keys and shared naming. The marts layer, or curated layer, shapes data into business-ready models where metrics like revenue, active users or margin are defined once and defined consistently.

Conversational analytics should query the curated layer by default. When “revenue” has a single agreed definition in a mart, every question that mentions revenue resolves to the same logic, whoever asks. This is what keeps two people from getting two different numbers for the same question — the fastest way to lose trust in any analytics tool. The layered model also gives the assistant clean, well-described tables to reason over, which improves the accuracy of the SQL it generates.

Why this collapses time-to-insight

The gain isn’t only speed, though the speed is real. When a self-serve question no longer needs an analyst in the loop, the analyst is freed for the deeper work that genuinely needs a human: modelling, investigation, and building the curated layer everything else depends on. Routine questions get answered in the moment, and complex ones get better attention.

Adoption widens too. People who would never open a SQL console will ask a question in plain language. That pulls more of the organisation into evidence-based decisions without adding headcount to the data team. And because every answer is governed and audited, broader access doesn’t translate into broader risk.

How Wohlig helps

Wohlig Transformations is a Google Cloud transformation and AI partner. We design and build conversational analytics on BigQuery end to end: the layered data model from raw to staging to marts, the governed connector that respects your IAM and column-level security, the audit trail your compliance team needs, and the agentic AI layer that turns plain-language questions into trustworthy, live results.

If your teams are waiting in report queues while your data warehouse sits underused, let us show you what conversational BI on BigQuery looks like in your environment. Reach out to Wohlig to scope a path from question to insight that your data leaders can stand behind.

For most of the last two years, the story of enterprise AI has been a story of stalled pilots — impressive demos that never survived contact with a security review, a compliance question, or a production incident. The prototypes were never the problem. The path to production was.

What changed in 2026 is that governance and security tooling saw the biggest usage uptick across the AI stack, and it’s no coincidence that organisations with strong governance get many times more AI projects into production. Governance isn’t a brake on delivery — it’s the guardrail system that lets teams move fast without fear.

The counterintuitive truth: governance ships more AI

Leading teams stopped treating governance as the thing you bolt on after the model works. They treat it as the thing that makes shipping possible at all. When every AI action is identity-aware, auditable and bounded by clear guardrails, the risk conversation moves from “should we allow this” to “here’s exactly what it can and cannot do.” That shift is what unblocks approvals. Governed teams don’t ask for permission to experiment — they’ve already answered the questions that used to freeze a project for months.

The moat isn’t the model. Frontier models are increasingly a commodity available to everyone. The durable advantage belongs to the organisations that can safely put those models to work on real data, in real workflows, at scale. Governance is what turns a capable model into a trustworthy system, and trust is what production requires.

What governance actually looks like in practice

Governance is often discussed as an abstraction. In a working AI platform it’s a set of concrete, engineered controls.

Identity and least-privilege access. Every agent, service and workflow runs as a known identity with the narrowest permissions it needs, and nothing more. An AI assistant that reads support tickets shouldn’t hold the credentials to modify billing records. Scoping access by identity is the single most effective way to contain the blast radius of a mistake or a compromised prompt.

Human-in-the-loop for high-risk actions. Not every action should be autonomous. Governance defines which operations require a human to review and approve before execution: issuing a refund, sending an external communication, changing a production configuration. The system proposes, a person disposes, and the boundary between the two is explicit rather than accidental.

Guardrails on destructive operations. Certain actions are irreversible or costly, and a governed system treats them differently. Deletes, bulk updates and spend-incurring calls sit behind policy checks, rate limits and confirmation steps. The goal isn’t to prevent the AI from acting, but to ensure it can’t act catastrophically.

Audit trails. Every decision, input, tool call and output is logged in a way that can be reconstructed later. When a regulator, an auditor or an incident reviewer asks what happened and why, a governed system can answer with evidence rather than speculation.

Evaluations and observability. Governance extends to quality. Systematic evaluations measure whether an AI system is accurate, safe and on-task before and after it ships. Observability then tracks quality, latency and cost in production, so degradation is caught early rather than discovered through a customer complaint.

Each of these controls does double duty. It reduces risk, and it produces the evidence that shortens every future approval.

Why guardrails make teams faster, not slower

The intuition that governance slows delivery comes from a world where controls were manual, inconsistent and applied late. In that world, governance really was friction: a spreadsheet of open questions, a security review that started from zero every time, a compliance sign-off no one could predict.

Engineered governance inverts that. When least-privilege access, human-in-the-loop checkpoints and audit logging are built into the platform, they apply automatically to every new use case. A team launching its fifth AI workflow inherits the controls that were proven on the first four. The approval that took three months for the pilot takes days for the next project, because the hard questions have standard answers.

This is the same lesson the industry learned with continuous integration and automated testing. Teams that invested in the harness shipped more, not less, because they could change things confidently. Governance is that harness for AI. It converts one-off anxiety into repeatable process, and repeatable process is what lets an organisation say yes to the next idea instead of stalling on it.

Governance is non-negotiable in regulated industries

For enterprises in financial services, healthcare, insurance and the public sector, the case is even sharper. These organisations don’t have the option of shipping AI they can’t explain, audit or control. Data residency, access controls and record-keeping aren’t preferences — they’re legal obligations.

For these teams, governance is the difference between an AI program that reaches production and one that never leaves the lab. The controls that skeptics see as overhead are precisely what allow a bank or a hospital to deploy AI at all. Built well, governance doesn’t just satisfy the auditor. It gives the business the confidence to use AI where it matters most — on the sensitive workflows that create the most value.

How Wohlig helps

Wohlig Transformations is a Google Cloud transformation and AI partner. We build cloud platforms, agentic AI, data and BI systems, and internal developer platforms for enterprises on GCP — and we build them to be governed from day one.

That means identity-aware, least-privilege access for every agent and service, human-in-the-loop approval for high-risk actions, guardrails around destructive and costly operations, complete audit trails, structured evaluations, and production observability of AI quality and cost. We design these controls as part of the platform, not as an afterthought, so your teams inherit governance automatically and ship faster with each new use case.

If you want to move from stalled pilots to AI that runs confidently in production — especially in a regulated environment — we’d like to help. Talk to Wohlig about building governed AI on Google Cloud, and turn governance into your durable advantage.

Something changed when enterprises moved from single-prompt AI features to genuine agents. A chatbot answers once. An agent reasons, calls tools, reflects on the result, calls more tools, and loops until it reaches a goal. Each of those steps is a model invocation, and each invocation carries the full weight of accumulated context. A task that looks like one user request can quietly become dozens of model calls.

Through 2026 this produced a recognisable pattern that engineers started calling “tokenmaxxing”: teams shipping agents that worked beautifully in a demo, then watching monthly spend climb far past forecast once real traffic arrived. The culprit was rarely a single expensive call. It was volume, redundancy, and the habit of routing every step — however trivial — to the most capable and most expensive model available.

The good news is that AI cost optimisation is now a well-understood engineering problem. Costs don’t spiral because agents are inherently expensive; they spiral because most systems are built without the controls that make cost predictable. The fix is engineering, not restraint. Here’s how we design those controls.

Tiered model routing: match the model to the job

The single largest lever is refusing to use one model for everything. Agentic workflows contain a mix of tasks with wildly different difficulty, and paying premium rates for easy work is where budgets quietly bleed.

A well-architected agent uses a tiered approach. A heavyweight model acts as the orchestrator: it handles planning, decomposition, and the hard reasoning that genuinely needs frontier capability. Lighter, faster models act as workers, executing the well-defined subtasks the orchestrator hands down — extraction, summarisation, formatting, or straightforward tool calls. And small, inexpensive models act as graders and routers, classifying intent, checking whether an answer meets a bar, or deciding which path a request should take.

This isn’t a compromise on quality. Most subtasks in a real workflow don’t require the strongest model, and using a smaller one often makes them faster as well as cheaper. The orchestrator spends its budget where reasoning is scarce, and the rest of the system runs lean. On Google Cloud, the Vertex AI model families make this practical: you can select the right Gemini tier per task and keep them behind a consistent interface.

An AI gateway: quotas, budgets and a single control point

You can’t govern what every service calls independently. When each team wires its own model calls directly, there’s no place to enforce a limit, no shared view of spend, and no way to react when something goes wrong.

An AI gateway solves this by routing all model traffic through one managed layer, and that layer becomes where policy lives. It enforces per-team and per-application quotas so a single misbehaving loop can’t consume a quarter’s budget overnight. It applies budget thresholds that trigger alerts, throttling or graceful degradation before an invoice becomes a crisis. And it centralises authentication and model selection, so upgrading or swapping a model is a configuration change rather than a code migration across dozens of services.

On Google Cloud, we build these gateways using Apigee and Cloud Run, integrated with Vertex AI, so that governance, rate limiting and budget enforcement sit in front of every agent. The gateway also becomes the natural home for the next two practices: caching and observability.

Caching and right-sizing: stop paying twice

A large share of agentic token spend is pure repetition. Agents re-send the same system instructions, the same tool definitions and the same reference context on every call in a loop, and they regenerate answers to questions that were answered minutes ago.

Two techniques address this directly. Prompt and context caching lets the model reuse the stable portion of a prompt instead of reprocessing it every time, which cuts both cost and latency on the long, unchanging preamble that dominates many agent calls. Response caching, keyed on semantically similar requests, means common queries are served without a model call at all.

Right-sizing is the discipline that surrounds this. It means trimming context to what a step actually needs rather than passing the entire history forward, setting sensible output limits so the model doesn’t ramble, and capping the number of reasoning iterations an agent may take before it must return or escalate. Much of the worst spend comes from unbounded loops and bloated context windows, and both are preventable with deliberate limits.

Observe cost per feature, not just per month

The invoice at the end of the month tells you that you spent too much. It doesn’t tell you where, why, or whether the spend was worth it. Without granular attribution, every optimisation is guesswork.

Cost-efficient AI requires observability that ties spend to meaning. That means instrumenting every model call with the feature it served, the team that owns it, the model tier it used, and the token counts it consumed. With that data flowing into your telemetry, cost becomes a first-class metric alongside latency and error rate. You can see cost per feature, cost per user session and cost per completed task — and watch those numbers move as you tune the system.

On Google Cloud, we route this telemetry into Cloud Logging and BigQuery, then surface it in dashboards that engineering and finance can read together. That shared view turns AI cost optimisation from an occasional fire drill into a continuous practice, and it lets leaders make honest decisions about which agentic features earn their keep.

How Wohlig helps

Wohlig Transformations is a Google Cloud transformation and AI partner. We build agentic AI, cloud platforms, data and BI systems, and internal developer platforms for enterprises — and we design them to be economically sustainable from the start. That means tiered model routing on Vertex AI, an AI gateway built on Apigee and Cloud Run for quotas and budgets, caching and right-sizing baked into the architecture, and cost observability wired into BigQuery so you always know what your agents cost and why.

If your agent bills are outrunning your forecasts, or you want to launch agentic capabilities without that risk, we can help you engineer for both capability and cost. Reach out to Wohlig to design cost-efficient agentic AI on Google Cloud that stays viable as you scale.

For most of the last few years, connecting an AI model to a real system meant writing a custom integration. Every data warehouse, ticketing tool and internal API needed its own glue code, its own auth handling and its own quirks. That work didn’t compose: a connector built for one model or agent framework rarely transferred to the next.

The Model Context Protocol (MCP) changes the shape of that problem. It’s a standard interface that lets AI models talk to your tools, data and systems without bespoke integration for each one. In 2026 it’s emerging as the default plumbing for enterprise agents — and the organisations getting value from it treat it as a governed capability, not a science project.

What the Model Context Protocol actually is

At its simplest, MCP is a standard interface between models and tools. Instead of hand-wiring each model to each system, you expose your systems as MCP servers that describe what they can do in a consistent way. Any MCP-aware client — an assistant, an agent, or an orchestration layer — can then discover those capabilities and use them through the same protocol.

Think of it as a common port that every tool can plug into. The model doesn’t need to know the internals of your data warehouse or your infrastructure APIs. It only needs to know that a tool exists, what it accepts and what it returns. That separation is why MCP has moved so quickly from an interesting idea to something enterprise teams now ask for by name.

Why standardisation matters more than any single tool

Standards are rarely exciting on their own, but they’re what turn scattered capability into leverage. Before a common protocol, every new AI use case carried an integration tax. Teams rebuilt the same connections in slightly different ways, and each rebuild added surface area to maintain and secure.

A shared protocol collapses that cost. When your systems speak MCP, a tool you expose once becomes available to every agent and assistant that follows the standard. You build a connection to your data warehouse a single time, and it works across use cases you haven’t even scoped yet.

For engineering leaders, the practical benefit is reuse: your investment in connecting a system compounds instead of resetting with each new model or framework. For CTOs, the strategic benefit is optionality. Standardised interfaces reduce the cost of switching models or adding new agent capabilities, which keeps you from being locked into a single vendor’s roadmap.

Governance and least-privilege scoping

The moment an AI agent can call real tools, it can also take real actions — and that raises the questions your security and compliance teams will ask first. What can this agent see? What can it change? And how do you prove it later?

MCP makes those questions answerable because it gives you a clear boundary to govern. Every tool an agent can reach passes through a defined interface, which is exactly the place to apply controls. The right posture is least privilege: an agent should have access only to the specific tools and scopes its task requires, and nothing more. A support agent that files tickets doesn’t need write access to production infrastructure. A reporting agent that reads the data warehouse doesn’t need permission to delete anything.

Practical governance of an MCP estate rests on a few disciplines. Curate a catalogue of approved tools rather than letting connections proliferate ad hoc. Scope credentials tightly and tie them to identity, so actions are attributable. Log every tool call for audit. And separate read-only capabilities from those that mutate state, so the higher-risk actions carry stronger controls and, where appropriate, human approval. These are the same principles that govern any privileged system, applied to a new kind of caller.

Real enterprise use cases

The value of MCP becomes concrete in the everyday work it unlocks. A few patterns show up repeatedly across enterprises.

Talk to the data warehouse. Instead of routing every analytical question through a queue of analysts, teams can ask in natural language and let a governed agent translate that into queries against approved datasets. The agent reads through a scoped, read-only interface and never touches data it shouldn’t see.

Inspect infrastructure. Engineers can ask an agent to check the health of a service, summarise recent changes, or surface the state of a deployment. The agent reads from monitoring and infrastructure systems through MCP tools deliberately limited to observation, keeping diagnosis fast and safe.

File and update tasks. When an agent identifies an issue or completes a step, it can create a ticket, update a task, or notify the right channel — closing the loop between insight and action without a human retyping what the agent already knows.

What ties these together is that the model provides the reasoning while MCP provides the reach. The intelligence decides what to do, and the protocol gives it a safe, standard way to do it inside your systems.

How Wohlig wires governed MCP on Google Cloud

Getting to this outcome is less about the protocol itself and more about the discipline around it — and that’s the work Wohlig does. We help enterprises design and operate governed MCP tool catalogues on Google Cloud, so your agents can act across your systems with the controls your organisation requires.

In practice, that means identifying the tools worth exposing, wrapping your data platforms, infrastructure and operational systems as well-scoped MCP servers, and building the identity, permissioning and audit layers around them. We enforce least privilege by default and make every action observable. Because we build natively on Google Cloud, this fits alongside the data platforms, security posture and developer tooling you already run there.

If you’re ready to move from AI demos to agents that do useful, governed work, a governed MCP tool catalogue is the foundation. Talk to Wohlig about designing yours on Google Cloud.

For a while, the answer to every hard AI problem was the same: use a bigger model with a longer context window and put everything into a single prompt. It’s an appealing idea, because it’s simple. In practice, it runs into ceilings that no amount of extra tokens fully removes — attention degrades, reasoning drifts, and failures are hard to isolate.

Multi-agent systems take a different approach. They split the work across specialised agents coordinated by an orchestration layer known as an agent harness. In 2026, that harness — rather than the model itself — is becoming the center of gravity in agentic AI, because it’s what turns a promising demo into a system you can actually operate, monitor and defend.

The limits of one big context window

Cramming an entire enterprise workflow into one model and one giant prompt hits three ceilings, and no amount of extra context fully removes them.

The first is attention. As you fill a context window with instructions, documents, tool outputs and prior conversation, the model’s ability to weigh the right details reliably tends to degrade. Important facts get buried, and the model can anchor on the wrong ones.

The second is role confusion. A single agent asked to plan, research, write code, check its own work and format the output is switching cognitive modes constantly, and quality suffers at the seams.

The third is observability. When one monolithic prompt produces a wrong answer, it’s genuinely hard to say which part of its reasoning failed — which makes the system difficult to debug and even harder to trust in production.

None of this means large models are the problem. It means a single model instance is the wrong unit of composition for a complex, multi-step business process. The better unit is a team.

What an agent harness actually is

An agent harness is the coordinating software that turns a collection of model calls into a working system. It’s the layer that decides which agent runs, what context each one receives, how their outputs are combined, and what happens when something fails. If a single agent is one worker, the harness is the operating model of the whole team: task assignment, hand-offs, quality control and escalation.

Concretely, a harness manages a few things a raw prompt cannot. It scopes context so each agent sees only what it needs, which keeps reasoning sharp and reduces cost. It enforces structure on inputs and outputs so agents can pass work to each other predictably. It handles retries, timeouts and fallbacks so a single flaky step doesn’t sink the run. And it produces a trace of what each agent did, which is what makes the system auditable. This coordination layer, rather than the model itself, is where much of the real engineering effort in agentic AI now sits.

Patterns that make multi-agent systems work

Multi-agent systems aren’t one architecture — they’re a small set of composable patterns. A few carry most of the weight in enterprise settings.

Orchestrator, workers and verifiers. An orchestrator agent breaks a goal into subtasks and delegates them to worker agents, each specialised for a narrow job such as retrieval, drafting, calculation, or calling a specific system. A separate verifier agent then checks the workers’ output against the original requirements. The key insight is that the agent producing work shouldn’t be the only agent judging it. Independent verification catches the confident mistakes that self-review misses.

Fan-out and synthesise. For research and analysis, the orchestrator fans a question out to several agents that work in parallel, each exploring a different source, angle or hypothesis. A synthesis agent then reconciles their findings into a single coherent answer, resolving contradictions and noting where evidence is thin. Because the parallel agents run at the same time, this pattern is often faster than a single agent working sequentially, and it covers more ground.

Scoped context per agent. Underlying both patterns is a discipline: give each agent a tight, purpose-built context rather than the whole history. A worker fetching a policy document doesn’t need the full conversation, and a verifier needs the requirements plus the output, not the messy reasoning in between. Scoped context is what lets a team of smaller, cheaper model calls outperform one enormous prompt.

These patterns compose. A production system might fan out to a set of workers, run each worker’s result past a verifier, and have an orchestrator decide whether to accept, retry, or escalate to a human. The harness is what holds that whole shape together.

Why teams beat one big model in production

The advantage of multi-agent systems isn’t that they’re clever — it’s that they’re governable. Specialised agents are easier to evaluate, because each one has a narrow job with a clear definition of done. Failures are easier to isolate, because a trace shows exactly which agent went wrong. Costs are easier to control, because you can route simple subtasks to smaller models and reserve the most capable model for the steps that truly need it. And behaviour is easier to improve incrementally, because you can upgrade one agent or one prompt without rewriting the entire system.

For enterprise leaders, this maps directly onto the things that actually block AI from reaching production: reliability, auditability and cost predictability. A single giant prompt optimises for a good demo. An orchestrated team optimises for a system you can operate, monitor and defend to a risk committee. That difference is why the center of gravity in agentic AI has shifted from picking the biggest model to designing the harness around it.

How Wohlig helps

Wohlig Transformations is a Google Cloud transformation and AI partner. We design and build orchestrated multi-agent systems on Google Cloud — from the orchestration and verification layer down to the data platforms, developer tooling and BI that agents depend on. That means we help you choose the right patterns for your workflows, wire agents to your real systems securely, and put the observability and guardrails in place that make agentic AI safe to run at scale.

If you’re moving from single-prompt experiments toward production multi-agent systems, we can help you get the harness right. Reach out to Wohlig to scope an agentic AI initiative on Google Cloud, and turn a promising demo into a system your teams can rely on.

For the past few years, AI at work has mostly meant a copilot sitting beside a person: it drafts an email, suggests a code change, summarises a ticket, and waits for a human to accept or reject. The human is still the engine of the workflow. The AI is a very capable passenger.

In 2026, that relationship is inverting. Enterprise AI is crossing what Google Cloud calls the agent leap — the shift from copilots that suggest next steps to agents that carry entire workflows to completion with light human oversight. The opportunity is real, but so is the operational risk. The teams that win start with bounded, high-volume processes, wrap their agents in strong governance, and build on a platform designed for autonomy from day one.

What actually changes at the agent leap

Autonomous AI workflows invert the copilot relationship. Instead of suggesting a single next step, an agent is given a goal, a set of tools, and a boundary — and it plans and executes the steps needed to reach an outcome. It can call APIs, query systems of record, chain multiple actions together, react to what it finds, and hand back a finished result rather than a suggestion. The human moves from operator to supervisor, reviewing outcomes and handling the exceptions the agent escalates.

That’s the leap. It matters because the value of AI stops being measured in keystrokes saved and starts being measured in whole processes owned. A copilot makes one person faster. An agentic workflow can absorb the routine 80 percent of a process, so your people spend their time on the judgement-heavy remainder.

Where the real value shows up

The change is most visible in workflows that are repetitive, rule-heavy, and spread across multiple systems. A few patterns recur across enterprises:

• Customer operations, where an agent triages an incoming request, gathers context from your CRM and knowledge base, drafts a resolution, and escalates only the genuinely ambiguous cases.

• Data and reporting, where an agent pulls from multiple sources, reconciles the numbers, and assembles a draft report that an analyst reviews rather than builds from scratch.

• Engineering and platform tasks, where an agent handles routine provisioning, dependency updates, or first-pass diagnostics inside guardrails set by the team.

• Back-office processing, such as invoice matching, document intake, and compliance checks that today consume large amounts of manual effort.

The common thread isn’t glamour. It’s volume and structure. The best first candidates are processes your team already understands well enough to describe as a set of steps — with clear inputs, clear success criteria, and a tolerance for the occasional handoff to a human.

What to automate first

Choosing the first workflow is where most programs succeed or stall. A practical filter has four parts.

First, pick something with high frequency and clear economics, so the effort pays back quickly and gives you a real signal. Second, favour workflows with well-defined boundaries, where you can state precisely what the agent may and may not touch. Third, make sure a ground truth exists, so you can measure whether the agent’s output is correct rather than merely plausible. Fourth, keep a human in the loop at the start, reviewing outcomes before they take effect, and widen the agent’s autonomy only as its track record earns it.

Resist the temptation to begin with your most complex, highest-stakes process. Start where a mistake is recoverable, prove the pattern, and expand from a position of evidence.

The risks you have to design for

Autonomy raises the stakes, because an agent that takes actions can also take wrong actions at scale. The failure modes are different from those of a copilot, and they deserve deliberate design.

The first is unbounded action. An agent with broad permissions and a vague goal can do more damage faster than any single person. The answer is least-privilege access, scoped tools, and hard limits on what any workflow can reach.

The second is silent error. Because the human is no longer watching every step, mistakes can accumulate unseen. This is why observability isn’t optional: every decision, tool call, and output should be logged and traceable, so you can audit what happened and why.

The third is drift and ambiguity. Real workflows contain edge cases, and an agent that improvises when it should escalate is a liability. Clear escalation paths, confidence thresholds, and human review for consequential decisions keep autonomy accountable.

The fourth is governance and data protection. Agents touch sensitive systems and data, so identity, access control, and compliance need to be built into the platform rather than bolted on afterward. Treat an agent as a first-class actor in your security model, not an exception to it.

Handled well, these aren’t reasons to wait. They’re the design requirements that separate a pilot that survives contact with production from one that doesn’t.

How Wohlig helps

Wohlig Transformations is a Google Cloud transformation and AI partner that designs and ships autonomous AI workflows built for the enterprise. We help you identify the right first workflows, ground your agents in your own data through robust data and BI foundations, and build on Google Cloud with security, observability and governance designed in from the start. Because we also build cloud platforms and internal developer platforms, the agents we ship land on infrastructure your teams can operate and trust.

If your organisation is ready to move from copilots that suggest to workflows that execute, talk to Wohlig. We’ll help you pick a first workflow, prove the value, and scale autonomy safely on Google Cloud.

Most engineering organisations run their software the way they did a decade ago: a scatter of disconnected tools, a human wired into every decision, and a platform that quietly decays the moment nobody is watching it. Planning lives in one tool, code in another, CI somewhere else, deployment somewhere else again, dashboards in a fourth place, cost in a spreadsheet, security in an inbox, and the AI experiments in a browser tab nobody governs. Every one of those seams is a place where work stalls, context is lost, and access has to be granted by hand.

At Wohlig we’ve built a different model: a single governed platform that takes an idea all the way from a tracked task to a running service in production, to a dashboard that proves it works, to a suggestion for what to improve next. The part that makes it feel alive is the loop — not a cron job that does the same thing forever, but an intelligent, continuously running cycle that observes real usage, telemetry, cost and security signals, decides what matters, acts, and then measures whether the action actually moved the number.

We call the discipline of designing and operating those cycles Loop Engineering. It’s only now becoming genuinely practical, because frontier models such as Fable 5 can reason over many steps, use real tools, and run unattended without falling apart.

The problem: a human in every loop

Ask an engineering leader where their software lifecycle actually lives and you’ll get a list, not a place. And all of it depends on a person choosing to look. Someone has to remember to check the cost report, notice the latency creeping up, spot the feature nobody uses, catch the vulnerability that keeps recurring, or find the idle environment burning money over the weekend. When that person is busy, on leave, or simply overwhelmed, the platform stops improving. It doesn’t fail loudly. It just slowly gets worse.

The traditional answer is automation, and automation helps — but classic automation is static. A script does exactly what it was written to do, forever, whether or not that’s still the right thing. It can’t read a dashboard and conclude the real problem is somewhere else. It can’t weigh impact against effort, or write the follow-up task. The judgement stays with the human, and so the bottleneck stays with the human.

That’s the gap we set out to close.

One governed surface for the whole lifecycle

The foundation is an internal developer platform: a single, opinionated surface where a team can plan, build, test, release, operate and improve everything, spanning DevOps, applications, business intelligence and AI. Three ideas hold it together.

One paved road. There’s a sensible, well-lit default path for the common case, with escape hatches for the exceptions. A new service can go from a fresh idea to production without a single manual infrastructure ticket. Developers don’t assemble their own pipeline every time — they follow the road, and the road is fast.

One identity. Every tool authenticates through the same corporate identity, and access is decided by group membership rather than a separate user list in each tool. Grant someone the right group and they can do the right things everywhere; remove them, and access is revoked everywhere at once. No per-tool cleanup, no forgotten account left behind.

Desired state is declared, not clicked. The intended configuration of the platform lives as reviewed, version-controlled declarations rather than ad-hoc changes made by hand in a console. Changes are proposed, reviewed like code, and reconciled automatically. The whole platform stays auditable and reversible: you can always see who changed what, why, and roll back to a known-good state.

The lifecycle, stage by stage

Plan. An idea becomes a tracked task on a board, and larger bets land on a roadmap. Nothing gets built that isn’t visible, owned and prioritised.

Build. A new project is scaffolded from a golden template that already has the pipeline, packaging and deployment wiring in place. Secrets never live in code; they’re pulled at runtime from a managed secret store. Conventions are baked in, so every project looks and behaves the same way.

Test. Quality is enforced by the pipeline, not by hope. Unit, integration and end-to-end tests, plus load testing and security scanning, run as gates. A change that fails a gate cannot merge or promote. There’s no “we’ll test it later.”

Release. Promotion from development to staging to production is one-way and driven entirely by the declared desired state. Each promotion has explicit gates: green tests, a load test within the performance budget, a clean soak period, and an approval. Production rollouts are progressive, using canary or blue-green strategies that abort automatically if the service breaches its reliability targets.

Operate. Every workload becomes observable without a single line of instrumentation code. A modern, low-level agent captures traces, metrics and logs automatically and streams them into a single observability layer, so there’s one pane of glass for the health of every service. Security posture, threat detection and vulnerability status sit in a parallel set of views. On-call has runbooks, not guesswork.

Improve. This is where the platform stops being a static toolchain and starts being a system that gets better on its own. Real usage data and live telemetry feed a standing improvement cycle that continuously proposes concrete technical work, feeds it back into planning, and closes the loop.

Data and AI as first-class operating surfaces

Two capabilities are what let the platform be operated conversationally rather than through a dozen consoles.

Talk to your data. Instead of standing up heavy BI infrastructure and waiting on a report queue, analysts ask questions in plain language. The AI assistant writes and runs the query against the warehouse through a governed connector, and returns the answer as a live chart, table or interactive widget in the same turn. Access is scoped by the same group membership that governs everything else, sensitive columns are protected, and every query is audited. The distance from question to insight collapses from days to seconds, without giving up governance.

AI as an operator, not just a chatbot. The assistant is wired into the platform through a catalogue of governed tool connectors. Through them it can query the warehouse, inspect running infrastructure, read logs and traces, look at product usage, and read or update planning documents — all with least-privilege scopes and confirmation required for anything destructive. Every action is audited. The output isn’t a wall of text; it’s an artifact — a dashboard, a report, a calculator, a widget — something a human can actually use and share. A gateway sits in front of the models to manage keys, quotas, budgets and routing, and an observability layer tracks the cost, latency and quality of every AI call.

Put those together and you have a platform a person can operate by describing what they want, while the system keeps the guardrails on.

The big idea: the continuous improvement loop

Here’s the cycle that makes the platform self-improving. It runs continuously, and every turn feeds the next.

1. Observe. Pull in the live signals: how features are actually used, how services actually perform, what things actually cost, and what the security posture actually looks like.

2. Detect. Find what matters in that noise — an anomaly, a reliability budget burning too fast, a slow code path, a feature nobody touches, waste, a recurring risk.

3. Suggest. Turn the finding into a concrete, written improvement — not a vague concern, but a specific proposal.

4. Prioritise. Weigh impact against effort and pick what to do next.

5. Execute. The chosen improvement becomes a real, tracked task and ships through the same paved road as everything else.

6. Measure. Check whether the signal actually moved. Did the change do what it promised? Confirm it, then go back to observing.

For years, every one of those steps except the last needed a person. Someone had to read the dashboards, connect the dots, write the proposal, make the call, and later come back to verify. The loop existed on a whiteboard, but in practice it ran only as often as a human had the time and attention to run it. That’s the constraint that has now lifted.

Loop Engineering: the discipline that runs the loop

Loop Engineering is the practice of designing, deploying, governing and observing intelligent loops that run continuously and improve the thing they are watching.

A loop, in this sense, is not a script. It’s an AI agent given a job, a cadence or trigger, a set of governed tools, and a definition of done. On each turn it gathers fresh context, reasons about it, decides what to do, does it, and verifies the result before it moves on. The loop is the unit of engineering. You compose loops, chain them, put guardrails around them, and watch them the way you’d watch any other production system.

It sits one level above both DevOps and classic automation:

• Automation repeats a fixed action.

• DevOps gives humans a fast, safe path to ship changes.

• Loop Engineering gives the platform itself the ability to observe, decide and act on a cadence, with humans supervising rather than driving.

Why now: what Fable 5 changes

Loop Engineering has been the dream for a long time. What was missing was a model reliable enough to trust with the loop. An agent that has to run for ten or twenty steps — or for hours — unattended, calling real tools against real systems, cannot afford to lose the thread halfway through, invent a command, or quietly do the wrong thing.

Frontier models in the current Claude generation, and Fable 5 in particular, are what make the loop dependable enough to run without a babysitter. Fable 5 is built for long, autonomous work: it can sustain a multi-stage task over an extended session, verify its own output, and carry out ambitious code and knowledge work with minimal oversight. The qualities that matter for Loop Engineering are:

• Long-horizon autonomy. The model can hold a multi-step task in mind, plan across it, and carry context from the observation at the start of a run all the way to the verification at the end.

• Real tool use. It doesn’t just talk about the systems — it operates them through governed connectors: querying the warehouse, reading telemetry, inspecting infrastructure, filing tasks.

• Unattended reliability. It can run a full cycle end to end without a human prompting each step, which is the entire point of a loop.

• Self-verification. It can check its own work, compare a result against the goal, even read a screenshot of a rendered interface and judge it against the design, and decide whether the loop succeeded or needs another pass.

• Structured, auditable output. Its actions come out as clean artifacts and structured results that downstream steps, and humans, can rely on.

Put simply: the loop was always a good idea. Fable 5 is the first-class engine that makes it safe to leave running.

Self-improving is not self-learning

A point worth being precise about, because it’s where most people get the idea wrong. Self-learning would mean the model rewrites its own weights as it goes. That’s not what’s happening, and it’s not what you want in a governed production system. What Loop Engineering delivers is self-improvement, which is a property of the system, not the model.

The model stays constant. The environment around it sharpens. Every run writes down what it learned, verified facts accumulate, the procedures the loops follow get refined by real edge cases, and the next run starts smarter than the last because it inherits that memory. Nothing about the model changed — the system compounded. Self-improvement is a property of the system, not the model, so you build the system. That’s exactly what Loop Engineering is.

What actually makes a loop get better

Three patterns separate a loop that compounds from one that just repeats. We build all three in.

Independent verifiers, not self-critique. A model grading its own work has skin in the game: it tends to bless conclusions consistent with its own reasoning. So the maker and the checker are kept separate. One agent produces the work; a second, independent agent sees only the finished artifact and the rubric — with no exposure to how it was made — and returns a verdict. If the verdict fails, the loop iterates. It exits only when an impartial checker passes it. This single design choice is the biggest driver of trustworthy autonomous loops.

Memory that compounds. A loop that forgets everything between runs can’t improve. So each loop follows a memory progression: it records a failure, investigates why it happened, verifies the diagnosis into a checked fact, distils that fact into a general rule, and then consults the rule on the next run instead of re-deriving it. Verified facts and hard-won rules live in durable state that every future run reads at the start and updates before it finishes. Recurring know-how gets promoted into reusable procedures, so a lesson learned once is applied everywhere. Two weeks of disciplined writing produces a system that materially outperforms starting fresh each time.

Tiered routing for economy. Not every step needs the most powerful model. A well-engineered loop uses a heavyweight model like Fable 5 as the orchestrator for the long, hard, multi-day work, delegates bounded sub-tasks and high-volume worker jobs to lighter, cheaper models, and uses the smallest, fastest models for simple grading. Matching model power to task difficulty keeps a continuously running fleet of loops economical rather than extravagant.

The anatomy of a well-engineered loop

Every loop we build shares the same skeleton — and this is where the “engineering” in Loop Engineering lives:

• A trigger — a schedule, such as every weekday evening, or an event, such as a deploy or an alert.

• An objective — a crisp statement of what the loop is for, narrow enough to be verifiable.

• Scoped tools — only the governed connectors this loop needs, at least privilege. A cost loop can’t touch production; a reporting loop can’t delete anything.

• An independent verifier — a separate checker that grades the output against the objective before the loop is allowed to finish.

• Persistent memory — durable state the loop reads at the start and updates at the end, so each run inherits what the last one learned.

• Guardrails — destructive actions require confirmation, high-risk changes stop and ask a human, and everything is logged.

• A definition of done — the signal the loop is supposed to move, so success is measurable rather than assumed.

• Observability on the loop itself — cost, latency and quality of the loop’s own runs are tracked, because a loop is a production workload.

That last point is the discipline that separates Loop Engineering from “we let an AI run overnight.” Loops are supervised, budgeted, audited and measured. They aren’t magic — they’re operated.

Loops already running

The improvement cycle isn’t the only loop. The platform runs a family of scheduled AI agents that each own a slice of operational health — and, crucially, prepare the ground for the humans:

• A weekly cost review loop pulls spend from the warehouse, finds the waste and the spikes, and produces the report leadership reads on Monday morning.

• A usage-to-improvement loop rolls up product analytics every week and turns real behaviour into candidate improvements, so the improvement log is never empty.

• An access-drift loop compares who should have access against who does, and flags the difference before it becomes an audit finding.

• A security-findings loop digests the day’s posture and threat signals into a briefing instead of a flood of alerts.

• A reliability loop rolls up service-level performance and error budgets, and surfaces the services trending the wrong way.

Notice the pattern. Each loop does the gathering, the reading and the first draft of the thinking, then hands a human a decision that’s already framed with the data attached. The meetings that used to start with “let me pull the numbers” now start with the numbers already on the table. The humans spend their time deciding, not fetching.

What the experience feels like

For a developer. You have an idea. You open a task, scaffold a project from a template that already has everything wired, and push your code. The pipeline runs your tests, load tests and security scans as gates, so you find out immediately if something is wrong — not in a review three days later. When it’s green, promotion to production happens through the paved road with no infrastructure ticket. The moment it’s live, it’s already observable, already secured, already on the dashboards. You didn’t configure any of that. You followed the road, and the road did the rest.

For an SRE. You’re not staring at ten consoles hoping to catch a problem. The loops watch continuously. Reliability trends, error budgets and anomalies come to you, framed and prioritised. When something breaks, production rollouts abort themselves on a reliability breach before you even reach for the runbook — and when you do need to act, the runbook is right there. Your standup and your ops review open with a pre-read a loop already prepared. You spend your attention on the hard calls, not on assembling the picture.

For an analyst. You don’t file a report request and wait. You ask your question in plain language, and the answer comes back as a live chart or interactive widget you can share, in the same conversation. The warehouse is serverless, access is governed by your group membership, and every query is audited. Insight is a sentence away, and governance was never traded for speed.

For a platform admin. Day-to-day operation happens conversationally. You ask the AI assistant to inspect a cluster, check a budget, or summarise the week, and it does the work through governed tools and hands you an artifact. Access is a matter of group membership, so onboarding and offboarding are clean and instant. The recurring reviews — cost, security, access, reliability — all arrive pre-built by loops. You supervise a system that largely runs itself, and you can prove, at any moment, exactly what it did and why.

For leadership. The platform is legible. Every service is visible in one place, every cost is attributable, every access grant is traceable, and the list of proposed improvements is never empty. The organisation isn’t depending on any single person remembering to look. The looking is engineered in.

How it functions under the hood

Strip away the narrative and the mechanics are straightforward — which is the point.

Cadence and triggers. Loops fire on schedules or on events. Scheduled loops handle the rhythm of operations: the nightly, weekly and monthly reviews. Event-driven loops react to deploys, alerts and threshold breaches. Between them, the platform is always either watching or acting.

Governed tool access. Every loop reaches the systems it needs through a catalogue of connectors, each scoped to least privilege. The loop that reviews cost can’t change infrastructure; the loop that reports on usage can’t touch secrets. Scope is the safety mechanism, and it’s declared, not assumed.

Observe, act, measure. Each loop follows the same arc: gather fresh signal, reason, take a bounded action or produce an artifact, and verify against a defined outcome. The verification step is what makes a loop trustworthy, because a loop that can’t tell whether it succeeded is just noise on a timer.

Governance and audit. Destructive operations require confirmation. High-risk decisions escalate to a human. Every action — by a human or a loop — is logged and reviewable. A gateway in front of the models enforces budgets and quotas, and an observability layer tracks the cost and quality of every AI call, so the loops themselves stay within their means.

The human half. None of this removes people; it repositions them. Short, timeboxed reviews turn the loops’ outputs into decisions, and decisions into owned work. The loops do the gathering and the first-draft thinking. The humans do the judgement, the trade-offs and the accountability. That division is deliberate, and it’s what keeps the whole system both fast and safe.

Why it matters

Engineering the loops in, rather than leaving them to human attention, produces a platform with a different set of properties:

• It doesn’t decay when nobody is looking, because the looking is continuous and automated.

• It surfaces work instead of hiding it. The backlog of improvements is generated from real signal, so the team is always working on what actually matters.

• It compresses the distance from signal to action. A cost spike, a reliability regression or an unused feature becomes a framed, prioritised, trackable piece of work in hours, not quarters.

• It stays governed at speed. Everything runs behind one identity, with least-privilege access and a full audit trail, so moving fast doesn’t mean losing control.

• It scales the team’s judgement, not its toil. People spend their time deciding and building, while the loops handle the watching, the gathering and the measuring.

This is the shift we’re putting a name to. DevOps gave us a fast, safe way to ship. Loop Engineering gives the platform the ability to run and improve itself on a cadence, with people supervising rather than driving every step. And it’s available with today’s technology, not a someday promise — because the models are finally reliable enough to trust with the loop.

Work with Wohlig

Wohlig designs and builds self-improving internal platforms end to end: the paved road from idea to production, the single governed identity layer, the observability and security backbone, the conversational data and AI surfaces, and — above all — the engineered loops that keep the whole thing getting better on its own.

If your engineering organisation is carrying the cost of a scattered toolchain and a platform that only improves when someone finds the time, this is the model that changes the equation. Talk to Wohlig about bringing Loop Engineering to your platform.

Apollo Hospitals partnered with Wohlig Transformations to deliver four AI use cases on top of its existing Salesforce CRM — combining Gemini Enterprise conversational analytics, a five-agent Vertex AI ADK geospatial intelligence system, web-search doctor mining, and a custom content-generation agent using Gemini LLM, Nano Banana Pro, and Veo 3.1 — distributed through Salesforce’s existing email + WhatsApp APIs.

Project Overview

Apollo Hospitals runs its field representative operations — doctor networks, referral partnerships, sales performance, and marketing collateral — on Salesforce CRM, the centralised system of record for everything its reps do in the field. In a PSF-funded, three-week engagement, Wohlig Transformations delivered four AI use cases on top of that existing Salesforce instance: Salesforce Efficiency Analytics via Gemini Enterprise, Geospatial Intelligence on a five-agent Vertex AI ADK system, Doctor Data Mining, and AI-Powered Content Generation. The governing constraint shaped every design decision: Salesforce itself is never modified. Wohlig consumes CRM data through REST APIs and invokes Apollo’s pre-configured email and WhatsApp APIs only — Salesforce stays the source of truth, and AI becomes the productivity layer on top.

The Challenge

Manual Oversight on Rich Data: Apollo’s Salesforce holds operational data across doctors, referrals, and field performance, but resource allocation, growth-zone identification, and content creation all relied on manual analysis rather than the data itself.

Geographic Blindspots: Field reps had no unified geospatial view of their territory — clusters, opportunity zones, visit recency, and route optimisation sat in spreadsheets and in territory managers’ heads.

Generic Marketing Collateral: Newsletters and brochures were one-size-fits-all rather than region- or specialty-specific, dampening engagement across Apollo’s doctor network.

Untapped Doctor Universe: Public healthcare directories such as Practo and Lybrate contain doctor records absent from Apollo’s CRM, but mining them by hand does not scale.

RBAC at Scale: Any AI-on-CRM solution had to mirror Salesforce’s existing role hierarchy — field reps must not see territory-manager data, and territory managers must not see leadership-only data.

Key Objectives

• Conversational Analytics on Salesforce Data: Field reps, territory managers, and leadership query their authorised data in plain English via Gemini Enterprise.

• Geospatial Intelligence on BigQuery + Google Maps: Salesforce ingested into BigQuery with a geospatial schema; doctors geocoded; opportunity zones and routes computed by a multi-agent ADK system.

• Doctor Network Expansion: A Gemini Enterprise web-search agent mines public healthcare directories with structured output.

• AI-Generated Region- and Specialty-Specific Content: A custom ADK agent uses Gemini LLM, Nano Banana Pro, and Veo 3.1 to produce newsletters, brochures, and marketing assets at the regional and specialty granularity Apollo’s territory teams need.

• Same-Surface Distribution: Distribution runs through Salesforce’s existing email and WhatsApp APIs — no new tools for field reps to learn.

• RBAC End-to-End: The Salesforce role hierarchy is mirrored into Gemini Enterprise permissions; each user sees only what their Salesforce role allows.

The Solution: Four AI Use Cases on a Single Salesforce Backbone

Use Case 1A — Salesforce Efficiency Analytics via Gemini Enterprise: A Gemini Enterprise environment was configured with the Salesforce connection as a data source. Salesforce RBAC was mirrored into GE permissions so field reps, territory managers, and leadership each query only their authorised data through the same conversational interface. Delivery included role-based query restrictions, user guides, and UAT validation.

Use Case 1B — Geospatial Intelligence (the technical centerpiece): Salesforce CRM data is ingested into BigQuery under a geospatial schema, then enriched through Google Maps Platform — Geocoding, Routes, and Places Insights. A five-agent Vertex AI ADK system does the reasoning: Data Preparation cleans and structures the CRM data; Geospatial Analysis runs spatial clustering, aggregating doctors by geographic proximity and computing performance metrics at cluster and territory levels; Route Optimization plans efficient field-rep travel; Communication triggers outreach via Salesforce email and WhatsApp; and Visualization renders the outputs. Those outputs are an interactive heatmap on the Google Maps JavaScript API — with multi-layer toggles for specialty, opportunity score, visit recency, and territory, and a mobile-responsive UI for field reps — alongside Looker Studio dashboards tuned for executive, territory-manager, and field-rep personas. Per the SOW success criteria, ≥95% of doctor addresses are geocoded with valid coordinates.

Use Case 1C — Doctor Data Mining via Gemini Enterprise: Web-search agents mine Practo, Lybrate, and similar public healthcare directories for doctor data, returning structured records that expand Apollo’s referral network — on demand and on schedule.

Use Case 2 — AI-Powered Content Generation & Distribution: A custom Vertex AI ADK agent generates region- and specialty-specific newsletters, brochures, and marketing collateral using three Google AI models — Gemini LLM for text, Nano Banana Pro for images, and Veo 3.1 for video — transforming Apollo’s existing brand assets. It then distributes through Apollo’s pre-configured Salesforce email and WhatsApp APIs, with targeted filtering by specialty, territory, and engagement criteria.

Technology Stack — Gemini Enterprise, Vertex AI (Agent Builder + ADK), Gemini LLM, Nano Banana Pro, Veo 3.1, BigQuery, Cloud Run + Docker, Google Maps Platform, Google Maps JavaScript API, Looker Studio, GCP IAM + Service Accounts + Secret Manager, and Salesforce REST APIs.

Key Benefits & Results

• Previous: Manual analysis of Salesforce data. Our Solution: Conversational analytics via Gemini Enterprise with Salesforce-mirrored RBAC. Result: Each user queries their authorised data in plain English — no SQL, no spreadsheets, no per-role bespoke reports.

• Previous: Geographic blindspots. Our Solution: A five-agent Vertex AI ADK geospatial system on BigQuery + Google Maps Platform. Result: Opportunity zones, hot/cold clusters, route-optimised daily visit plans, and territory-level performance aggregation.

• Previous: No interactive map. Our Solution: A web-based interactive heatmap on the Google Maps JavaScript API with multi-layer toggles and a mobile-responsive UI. Result: Field reps explore their territory on their phone.

• Previous: Generic marketing collateral. Our Solution: A custom ADK agent generating region- and specialty-specific newsletters, brochures, images (Nano Banana Pro), and videos (Veo 3.1). Result: Doctor engagement tailored to specialty and territory.

• Previous: Manual referral-network expansion. Our Solution: A Gemini Enterprise web-search agent mining public healthcare directories. Result: Structured doctor records, on demand and scheduled.

• Previous: Hand-crafted bulk emails. Our Solution: Salesforce email + WhatsApp API distribution invoked by the agent. Result: Same-surface distribution, with no new tools for field reps.

Technical Innovation

Five-Agent ADK System for Geospatial Intelligence: Data Preparation, Geospatial Analysis, Route Optimization, Communication, and Visualization — each agent owns a clear responsibility, and the orchestration is deterministic.

Salesforce RBAC Mirrored into Gemini Enterprise: Field rep, territory manager, and leadership roles map cleanly across the analytics surface — the same chat UI, role-different results.

Multi-Model Content Generation: Gemini LLM, Nano Banana Pro, and Veo 3.1, orchestrated by a single ADK agent, produce region- and specialty-tailored newsletters, brochures, images, and videos.

Zero Salesforce Modification: The solution consumes Salesforce data and invokes pre-configured Salesforce APIs — no CRM customisations, no schema changes — a clean separation that respects Apollo’s CRM ownership.

Same-Surface Distribution: Distribution runs through the email and WhatsApp APIs Apollo already has configured; field reps interact with the system they already use, and AI fades into the background.

Wohlig’s Approach

1. Discovery & CRM analysis — workshops with Apollo’s marketing and field operations stakeholders; review of the Salesforce data structure.

2. GCP foundation — BigQuery (geospatial schema), Cloud Run, and IAM + Secret Manager.

3. Salesforce ↔ Gemini Enterprise — connection setup, RBAC mirroring, and conversational-analytics validation.

4. Geospatial data foundation — ETL pipelines for daily Salesforce sync; geocoding via Google Maps Platform; spatial clustering; territory aggregation.

5. Multi-agent ADK build — five agents for Use Case 1B (Data Prep, Geospatial Analysis, Route Optimization, Communication, Visualization); the web-search agent for Use Case 1C; the content-generation agent for Use Case 2.

6. Heatmap + dashboards + distribution — Google Maps JavaScript API heatmap, Looker Studio dashboards, and Salesforce email + WhatsApp distribution; UAT; documentation and knowledge transfer.

About Apollo Hospitals

Apollo Hospitals Enterprise Limited is India’s premier integrated healthcare platform, headquartered in Hyderabad. Apollo operates a large network of hospitals, clinics, and specialist services across India, supported by a field representative organisation that manages doctor networks, referral partnerships, and sales performance across territories. The organisation uses Salesforce CRM as the centralised system of record for all field force activity.

About Wohlig Transformations Pvt. Ltd.

Founded in 2015, Wohlig Transformations specialises in GenAI and DevOps, with 160+ professionals across India and the UK.

Detailed Case Study Presentation : https://youtu.be/V_PP37zfEI8

Hero MotoCorp partnered with Wohlig Transformations to build an ADK agent on Vertex AI Agent Engine, surfaced through Gemini Enterprise, that answers natural-language questions over the Hero Wisdom Sphere (HWS) knowledge repository — with per-user RBAC enforced inside the agent itself, verified by an independent 101-case evaluation: 0 real RBAC leaks, 100% tool selection, ~90% accuracy.

Project Overview

The Hero Wisdom Sphere (HWS) is Hero’s institutional knowledge repository — R&D, manufacturing, and quality documents — running on a customised DSpace instance backed by PostgreSQL (cdl_prod) on-premises. A single architectural constraint shaped the entire engagement: the on-prem MCP server that fronts the database is client-owned and out of scope for modification, and it exposes one all-powerful tool, query_database, capable of running any read-only SELECT with full read access. Rather than trust the model with that surface, Wohlig made the defining design decision to reconstruct per-user access control inside the agent — the LLM is restricted to four safe tools and never sees raw SQL, while deterministic Python resolves verified identity, applies the HWS L1-L5 access model, and builds an access-clamped query before anything reaches the MCP. Employees ask in plain English through Gemini Enterprise (Workspace SSO); the answer is grounded, cited, and scoped to their entitlements. An independent 101-case evaluation on the deployed agent confirmed the approach: zero real RBAC leaks, perfect tool selection, and roughly 90% accuracy.

The Challenge

Single All-Powerful MCP Tool: The on-prem MCP server exposes one tool — query_database — that runs any read-only SELECT with full database read access. Anything attached to the model would inherit that blast radius.

Client-Owned, Out of Scope: The MCP server and the DSpace instance itself are client-owned; modifying them was explicitly out of scope per the SOW. The fix had to live entirely in the agent layer.

Native DSpace Permissions Don’t Isolate: DSpace’s native resourcepolicy group 8 (”Read”) grants every user READ on every item — there is no built-in gate to lean on for per-user isolation.

Hidden Multi-Level Access Model: The real control is HWS’s level-driven access model (L1-L5), documented in the client’s MCP reference — but it had to be reconstructed in the agent, not inherited from the database.

Identity at Production Grade: Verified Workspace identity must flow end-to-end from Gemini Enterprise → ADK → tool calls, and must never be read from model output.

Key Objectives

• Surface Through Gemini Enterprise: Employees ask in plain English; the answer is grounded, cited, and respects their entitlements.

• Never Expose Raw SQL to the LLM: Restrict the LLM to a small set of safe tools; deterministic code builds the access-clamped query.

• Enforce L1-L5 In-Agent: Reconstruct the access model from the client’s MCP reference; fail-closed for unknown users and conflicting items.

• Independent Evaluation: Prove the design with a 101-case suite using ground truth verified independently from the database.

• Production-Grade Concurrency: Cache clients per event loop; scale via instances, not in-process concurrency.

• Secure On-Prem Connectivity: Cloud HA VPN + Shared VPC + PSC interface; read-only end to end.

The Solution: ADK Agent with RBAC Reconstructed in the Agent

• Four Safe Tools — search_documents, get_document, browse_documents, and list_knowledge_scope. The raw query_database tool is never attached to the LLM; the model can only ever choose among these four narrow capabilities.

• The L1-L5 Access Model — L1 Public / L2 R&D-wide (R&D departments) / L3 Department (owning department) / L4-L5 explicit per-item grants only / Admin bypass (DSpace group 1, directly or via group2groupcache). Most-restrictive level wins on conflicts. Fail-closed throughout.

• Identity Propagation — Gemini Enterprise passes the verified Workspace email to the agent as the ADK user_id (empirically confirmed via probe before being relied upon). identity.py reads it from the runtime context; the model is never trusted to provide identity.

• sql_guard (sqlglot AST validation) — single statement, SELECT-only, no CTE, table allow-list, and denial of eperson secret columns (password / salt / digest_algorithm). All literals are escaped, so a malicious keyword becomes an inert string literal.

• End-to-End Connectivity — Cloud HA VPN + Shared VPC + PSC interface → on-prem MCP server → PostgreSQL cdl_prod. A read-only DB user (hws_mcp) and a SELECT-only MCP keep the path read-only end to end.

• Technology Stack — Gemini Enterprise, Vertex AI Agent Engine, Gemini 3 Flash Preview (Vertex AI global endpoint), Vertex text-embedding-005, Google Agent Development Kit (ADK), MCP client, sqlglot, Cloud VPN HA, Shared VPC, PSC interface, Cloud IAM, Secret Manager, and Cloud Logging + Monitoring.

Key Benefits & Results

• Previous: All-powerful single MCP tool. Our Solution: 4 safe tools with raw SQL never exposed to the LLM. Result: An architectural ceiling on blast radius — injection or misinstruction cannot widen access.

• Previous: DSpace native permissions ineffective (group 8 reads everything). Our Solution: L1-L5 model reconstructed in entitlements.py from the client’s MCP reference. Result: Per-user access correctly enforced at the agent layer.

• Previous: Model-provided identity is unsafe. Our Solution: Verified Workspace email from the ADK runtime context (empirically confirmed). Result: Identity never trusted from model output; fail-closed for unknown users.

• Previous: Free-form SQL generation risk. Our Solution: sqlglot AST guard + escaped literals + read-only end to end. Result: A malicious keyword becomes an inert string literal; a missing filter cannot occur.

• Previous: No production evidence. Our Solution: 101-case eval with ground truth from an independent read-only introspection engine. Result: 0 real RBAC leaks, 100% tool selection, ~90% accuracy (94% single-turn, 69% multi-turn).

• Previous: Concurrency pitfalls (single-global clients raise “Future attached to a different loop”). Our Solution: Per-event-loop client caching + scaling via instances. Result: A production-stable runtime.

Technical Innovation

RBAC Reconstructed in the Agent: The on-prem MCP server is client-owned and out of scope. The LLM is restricted to 4 safe tools; deterministic Python resolves verified identity, entitlements, and the access predicate before any query reaches the MCP.

Defence in Depth: No raw-SQL tool on the model; sqlglot AST validation; escaped literals; read-only end to end; PSC + HA VPN. Five orthogonal layers — an injected instruction cannot widen scope, and an omitted filter cannot occur.

Independent Eval Harness: A 101-case suite plus 10 client-acceptance questions, with ground truth from an independent read-only introspection engine — not LLM-as-judge. Cross-department L3 and unknown-user requests were correctly denied.

Per-Event-Loop Client Caching: The genai client and MCP toolset are cached per event loop (a single global raises concurrency errors in this runtime). Scaling is via instances and container_concurrency=9, not in-process concurrency.

Transparent Data-Quality Flagging: Three records with conflicting auth-levels (HWS-DOC-279/0, 371/0) and one corrupted record (HWS-DOC-225/0) were surfaced to Hero’s HWS team — production hygiene, not silent papering-over.

Wohlig’s Approach

1. Discovery & connectivity design — workshops with Hero stakeholders; review of the GCP landing zone, IAM policies, and network topology; site-to-site VPN + Shared VPC + PSC design.

2. RBAC + safe-tools architecture — reconstruct the L1-L5 access model from the client’s MCP reference; design the 4 safe tools; design the sql_guard validator.

3. ADK agent build — implement identity, entitlements, search, sql_guard, and mcp_client; integrate Vertex text-embedding-005 for in-agent rerank; cache genai + MCP per event loop.

4. Independent eval harness — a 101-case suite plus 10 client-acceptance questions; ground truth from a read-only introspection engine; RBAC, tool-selection, and accuracy judges.

5. Deployment to Vertex AI Agent Engine — extra_packages=[app], PSC network attachment, container_concurrency=9, min/max instances, and resource limits.

6. Gemini Enterprise registration + handover — import into Gemini Enterprise; validate end-to-end invocation; deliver an architecture document, implementation guide, runbook, and knowledge transfer.

About Hero MotoCorp

Hero MotoCorp Limited is the world’s largest manufacturer of motorcycles and scooters by volume, headquartered in New Delhi with a presence across more than 40 countries. Hero has built a strong reputation for innovation, manufacturing excellence, and customer-centric product design, and is embedding generative + agentic AI into internal workflows as part of its digital transformation programme.

About Wohlig Transformations Pvt. Ltd.

Founded in 2015, Wohlig Transformations specialises in GenAI and DevOps, with 160+ professionals across India and the UK.

Detailed Case Study Presentation : https://youtu.be/8b9zKWYUc_Q

Vivriti Capital partnered with Wohlig Transformations for a production Gemini Enterprise rollout across 425 licensed users in five business departments — combining a multi-app GE tenant with strict department data segregation, 10 no-code agents, 3 custom ADK agents on Vertex AI Agent Engine, and a structured change-management programme targeting 50%+ weekly active usage by Project End + 4 weeks.

Project Overview

Vivriti Capital is a diversified financial-services group whose work spans Treasury Operations, Finance, Operations, Credit & Risk, Distribution, and AIF Operations — each with its own data, its own controls, and its own regulatory weight. Vivriti licensed Gemini Enterprise for 425 users and brought in Wohlig to do the part a licence purchase can’t: stand up Google’s AI workspace so it is genuinely adopted, not merely deployed. The anchor decision was a multi-app GE tenant — a separate GE app per business department — layered over Vivriti’s existing Microsoft 365 productivity stack. Across a focused 4-week engagement plus ongoing office hours, the brief was framed around one number that deployment alone never guarantees: weekly active usage.

The Challenge

Strict Department Data Segregation: Operations users must not retrieve Treasury data through chat; Finance must not surface Credit & Risk content. For a regulated financial-services organisation, segregation has to be architectural — enforced by how the platform is built, not by a policy memo or a post-query filter.

Microsoft 365 as the System of Record: Vivriti’s collaboration runs on OneDrive, SharePoint, and Outlook. The rollout had to integrate cleanly with Microsoft 365 — federated for user-specific content, ingested for shared content — rather than asking the organisation to move its working files.

Fintech-Specific Use Cases: Generic GE templates don’t fit a fintech operating model. Trade reconciliation (RupeeVest + NSDL; BSE + NSE), KYC document chat, regulatory document analysis, and mailbox-monitored market intelligence all need purpose-built agents to be useful on day one.

Self-Sufficiency by Handover: Vivriti’s non-technical users needed to build their own no-code agents, and its technical spokes needed to build custom ADK agents and custom connectors — without Wohlig in the room.

Licence-to-Usage Gap: 425 licences are worthless if usage never reaches a meaningful threshold. The brief was explicit — 50%+ weekly active usage (~213 users) by Project End + 4 weeks.

Key Objectives

• Production GE Tenant, Architecturally Segregated: A separate GE app per business department, each with its own Microsoft 365 connector and isolated Cloud Storage bucket.

• Microsoft 365 First-Class: SharePoint (federated + ingestion), OneDrive, and Outlook connectors configured per department.

• Fintech No-Code Library: 10 no-code agents covering the fintech operating patterns Vivriti users actually need.

• 3 Priority Custom ADK Agents: RupeeVest/NSDL Mapping, BSE/NSE Trades, and Regulatory & Market Intelligence — built on Vertex AI Agent Engine.

• Custom Connector Reference: One demonstration custom connector to show Vivriti’s technical spokes how to extend the platform themselves.

• 50%+ Weekly Active Usage: A structured enablement and change-management programme aimed at the adoption number, not just the deployment milestone.

The Solution: Multi-App Gemini Enterprise Tenant + Custom Agents + Adoption Programme

• Multi-App GE Tenant — Roughly 5 separate GE app instances, one per business department (Treasury Operations, Finance, Operations, Credit & Risk, Distribution; more as identified during kickoff). Each app has its own department-level Microsoft 365 connector, authenticated via distribution-list-level tenant configuration, and its own isolated Cloud Storage bucket. Segregation is enforced by tenant architecture — not by an application-layer filter.

• Microsoft 365 Connectors — SharePoint runs in federated mode for user-specific sites and in data-ingestion mode for shared sites (legal templates, KYC repositories, report templates). Outlook handles inbound email access and designated mailbox monitoring. OneDrive covers personal files across every department app.

• 10 No-Code Agent Demo Library — Document summarisation, email triage, simple reconciliation, report generation, regulatory document analysis, KYC document chat, expense queries, calendar management, meeting summaries, and internal policy Q&A. The library is documented in a Vivriti SharePoint knowledge base for users to reference, copy, and adapt.

• 3 Custom ADK Agents on Vertex AI Agent Engine — RupeeVest and NSDL Mapping; BSE and NSE Trades (with Vivriti Invest 2.0 read-only access for distributor master and commission-rule lookups); and Regulatory and Market Intelligence (designated mailbox monitoring via the Outlook connector).

• One Demonstration Custom Connector — A Microsoft Graph API integration built during the technical training stream as the reference pattern Vivriti’s technical spokes can replicate indefinitely.

• Enablement & Change Management — Non-technical training (online, org-wide); technical training (ADK + custom connectors); customer enablement and change management; named champions per cohort; weekly adoption metric review with corrective action; and three-weekly post-engagement office hours.

• Technology Stack — Gemini Enterprise (multi-app), Vertex AI Agent Engine, Google Agent Development Kit (ADK) for Python, Google Cloud Identity (SSO), Cloud Storage, Cloud IAM, Microsoft 365 (OneDrive + SharePoint + Outlook), Microsoft Graph API (custom connector), and Vivriti Invest 2.0 (read-only).

Key Benefits & Results

• Previous: A single shared tenant risks cross-department exposure. Our Solution: A multi-app GE tenant with department-isolated apps, Cloud Storage buckets, and Microsoft 365 connectors. Result: Architectural segregation — Operations cannot reach Treasury data; Finance cannot reach Credit & Risk content.

• Previous: Generic GE templates with no fintech relevance. Our Solution: 10 fintech-specific no-code agents plus 3 custom ADK agents on Vertex AI Agent Engine. Result: Day-one relevance for Vivriti’s operating model.

• Previous: Off-the-shelf connectors only. Our Solution: SharePoint federated + ingestion modes, Outlook mailbox monitoring, and a demonstration custom connector via Microsoft Graph API. Result: Microsoft 365 treated as first-class, with a clear path to extend.

• Previous: “We hope users open it.” Our Solution: Structured non-technical + technical training, named champions per cohort, weekly adoption metric review, and three-weekly office hours. Result: 50%+ weekly active usage as the explicit success criterion.

• Previous: Dependency on an external partner after deployment. Our Solution: Self-sufficiency by handover — non-technical users build no-code agents; technical spokes build custom ADK agents and custom connectors. Result: Vivriti owns the platform’s growth post-engagement.

Technical Innovation

Multi-App GE Tenant for Department Data Segregation: A separate GE app per business department, each with its own department-level Microsoft 365 connector authenticated via distribution-list-level tenant configuration. Segregation by tenant architecture — not by an application-layer filter or a post-query check.

Microsoft 365 in Two Connector Modes: SharePoint federated for user-specific content, plus SharePoint data ingestion for shared content (legal templates, KYC repositories). Outlook for both inbound access and designated mailbox monitoring.

Custom Connector as a Training Artefact: Rather than building every custom connector Vivriti might ever want, Wohlig built one demonstration custom connector during the technical training stream as the reference — Vivriti’s technical spokes can replicate the pattern indefinitely.

Adoption as a Success Criterion: The engagement is scored on weekly active usage, not on deployment. Named champions per cohort, weekly metric review, corrective action, and post-engagement office hours operationalise that commitment.

Transparent Phased Identity Plan: Workforce Identity Federation with Microsoft Entra ID is deferred to a subsequent phase — this engagement uses Google Cloud Identity for SSO. Planned, not omitted.

Wohlig’s Approach

1. Kickoff & discovery — Sponsorship engagement; department workshops (Asset Management, AIF Operations, Treasury, Distribution, and others); use-case discovery.

2. Multi-app architecture design — Roughly 5 GE app instances; department-level Microsoft 365 connector configuration; isolated Cloud Storage buckets.

3. Implementation — Multi-app tenant + Microsoft 365 connectors + 10 no-code agents + 3 ADK agents + 1 demonstration custom connector.

4. Enablement — Non-technical training (online, org-wide); technical training (ADK + custom connectors); customer enablement + change management.

5. Adoption operations — Named champions per cohort; weekly adoption metric review; corrective action where any cohort lags.

6. Project closeout + ongoing office hours — Handover; documentation; three-weekly post-engagement office hours to sustain adoption.

About Vivriti Capital

Vivriti Capital is a diversified financial-services group with functions spanning asset management, AIF Operations, Treasury, Distribution, Credit & Risk, and Finance. Vivriti operates on Microsoft 365 for collaboration and on Vivriti Invest 2.0 for its internal investment platform.

About Wohlig Transformations Pvt. Ltd.

Founded in 2015, Wohlig Transformations specialises in GenAI and DevOps, with 160+ professionals across India and the UK.

Detailed Case Study Presentation : https://youtu.be/lGSE-zqW6QY

IKS Health partnered with Wohlig Transformations to optimize the Stacks AI ML Engine — its AI-powered healthcare document-processing platform — across the OCR, Search, and LLM layers on Google Cloud, achieving $0.00557 per page (5.4× better than the SOW’s <3¢/page target) and a 15-percentage-point gain in multi-page document matching accuracy in a 3-week sprint.

Project Overview

As part of a wider cloud modernization initiative, IKS Health moved its Stacks AI ML Engine — the document-intelligence platform that processes patient records, dates of service, providers, medical images, and multi-page clinical reports — from a multi-vendor Azure AI Search + Azure OCR + OpenAI GPT-4o stack to a unified Google Cloud AI stack built on Vertex AI Search, Document AI, and Gemini 2.5 Flash. IKS Health had rebuilt the codebase on a five-service Cloud Run architecture before engaging Wohlig; our mandate was to tune the OCR, Search, and LLM layers and hand back a production-ready cutover plan. The work ran as a three-week optimization sprint (Apr 6 – Apr 24, 2026) plus cutover preparation into early May, with every artefact delivered to IKS Health’s ML and Server teams.

The Challenge

Multi-Vendor Complexity. AI workflows were split across Azure AI Search, Azure OCR, and OpenAI GPT-4o — three vendors, three SLAs, three cost models sitting in front of a single clinical workflow.

Healthcare Document Complexity. Production traffic includes multi-page clinical reports, MRI / X-ray imaging, mixed document types per batch, and multiple patients per submission — healthcare-grade accuracy is required on both single-page and multi-page workflows.

Large-File Processing Failures. High-resolution or high-page-count documents failed inside the initial pipeline even when on-disk file size was modest — a system-capacity issue, not a simple size threshold.

Cost-per-Page Target. The SOW set a hard ceiling of under 3 cents per page across the combined OCR + Search + LLM pipeline — end-to-end optimization, not single-component tuning.

Production-Grade Cutover. First-time go-live with no prior production to roll back to — every Go/No-Go gate had to be defensible.

Key Objectives

• Unified Cloud AI Stack: Migrate from Azure + OpenAI to Vertex AI Search + Document AI + Gemini 2.5 Flash without regressing on accuracy or relevance.

• Sub-3¢-per-Page Pipeline: Hit the SOW’s cost target across OCR + Search + LLM combined, on real benchmarked workloads.

• Multi-Page Accuracy Lift: Improve document grouping and field-level extraction on multi-page healthcare reports.

• Reusable AI Agent: Package the optimized engine as a self-contained, modular service IKS Health can drop into future projects.

• Production Cutover Plan: Go/No-Go gates, runbook, acceptance tests, and live-monitoring checks so first-time go-live behaves like a controlled deploy.

The Solution: Optimized Five-Service Cloud Run Pipeline

Five-Service Cloud Run Architecture. The engine runs as five independently-scaled Cloud Run services — chunk-coordinator → conversion-service (small + large) → ai-processing → status-notifier. CPU, memory, concurrency, timeout, and gunicorn workers are configured per service to match the workload.

The conv-large Split (Wohlig-introduced). We split conversion-service into two pools. Small jobs stay at 4 CPU / 16 GiB / concurrency 8. A new conversion-service-large runs at 8 CPU / 32 GiB, concurrency 1, timeout 3600s — a dedicated worker for high-resolution and high-page-count documents that isolates the long-tail without slowing the hot path.

OCRTEXT Pipeline Mode. We switched LLM_INPUT_TYPE from IMAGE to OCRTEXT — Gemini 2.5 Flash now consumes Document AI‘s clean OCR text instead of raw PNG buffers from every page. Smaller payloads, faster prompts, fewer hallucinations on tables and dates — the single change that lifted both accuracy and cost together.

Gemini 2.5 Flash (fine-tuned). Replaces OpenAI GPT-4o at the LLM stage. Cross-model benchmarking across GPT-4o, Gemini Pro, and Gemini 2.5 Flash drove the selection on unit cost, latency, and field-level accuracy; Gemini Pro stays available as a fallback for harder document classes.

Technology Stack. Vertex AI Search, Document AI, Gemini 2.5 Flash, Cloud Run, GKE, BigQuery, Cloud Storage, Cloud Build, Terraform, Cloud Monitoring, Cloud IAM, Secret Manager.

Key Benefits & Results

• Previous: $0.00689 per page on the Azure + OpenAI baseline. Our Solution: OCRTEXT mode + fine-tuned Gemini 2.5 Flash + per-service Cloud Run sizing. Result: $0.00557 per page — 5.4× better than the SOW’s <3¢ target; total run cost $7.736 → $6.223 on the same 1,118-page benchmark (−19.56%).

• Previous: Multi-page document matching at 65%. Our Solution: conv-large split + chunking + OCRTEXT pipeline. Result: 80% multi-page matching (+15 percentage points).

• Previous: Files Fully Matched at 67.60%. Our Solution: Optimized end-to-end pipeline. Result: 78.10% (+10.50 pp).

• Previous: Field-level accuracy on the Azure baseline. Our Solution: Field-specific prompts + OCRTEXT mode. Result: PatientDOB 82.09% → 89.94% (+7.85 pp), PatientName 95.06% → 97.69%, DateOfService 66.10% → 70.00%, Provider 55.75% → 58.78%.

• Previous: Large-file processing failures on high-resolution / high-page-count documents. Our Solution: New conversion-service-large (8 CPU / 32 GiB / concurrency 1 / 3600s). Result: Mitigated and tracked through cutover gate G5.

• Previous: No production cutover discipline. Our Solution: 11 Go/No-Go gates + 14-step runbook + 6 acceptance tests + 8 live-monitoring checks. Result: Production-grade first-time go-live readiness, handed to the ML and Server teams.

Technical Innovation

OCRTEXT Pipeline Mode. Switching Gemini’s input from raw PNG buffers to Document AI OCR text simultaneously lifted accuracy and dropped cost — a single change with two-axis impact.

conv-large Service Split. A dedicated Cloud Run service for high-resolution and high-page-count documents (8 CPU / 32 GiB / concurrency 1), without sacrificing throughput on the small / fast documents that route to conv-small.

Tuned Per-Service Sizing. Each of the five Cloud Run services is configured independently — CPU, memory, concurrency, timeout, gunicorn workers and threads — for the workload it actually handles.

Production Cutover Discipline. 11 Go/No-Go gates, a 14-step runbook, 6 acceptance tests, and 8 live-monitoring checks. Open production-readiness items (large-file, high-page-count, bulk-load) are tracked transparently as gates G5–G7.

Reusable AI Agent Packaging. The optimized stack ships as a self-contained, modular agent that IKS Health can drop into future document-intelligence workflows without re-architecting the OCR / Search / LLM layer.

Wohlig’s Approach

1. Discovery & migration assessment — audit existing Azure AI Search, Azure OCR, and OpenAI GPT-4o integrations; document baselines, token usage, and the per-page cost scoreboard.

2. Vertex AI Search optimization — tune data stores, schemas, and ingestion pipelines; validate content and embedding parity with the Azure baseline.

3. Document AI OCR integration — configure processors for IKS Health’s document types; switch the pipeline to OCRTEXT mode.

4. Gemini LLM optimization & prompt re-engineering — re-engineer prompts for Gemini’s instruction format and 1M-token context window; fine-tune Gemini 2.5 Flash for stable field-level extraction.

5. Code refactoring & reusable agent packaging — factor the orchestration into a modular, agent-based service IKS Health can reuse across future projects.

6. Cross-model benchmarking, system testing, cutover plan — GPT-4o vs Gemini Pro vs Gemini Flash on the same workload; an 11-scenario test pass (single-page, multi-page grouping, improper sequence, mixed document types, missing fields, fuzzy matching, exact-match DOB / DOS, case insensitivity, MRI / X-ray imaging, low-quality OCR, multi-patient batches); production cutover plan with 11 Go/No-Go gates, 14-step runbook, 6 acceptance tests, and 8 live-monitoring checks.

About IKS Health

IKS Health is a leading US-focused healthcare solutions company providing revenue cycle management, clinical documentation improvement, and IT services to hospitals and physician groups. By combining clinical expertise with intelligent automation, IKS Health reduces administrative burdens so clinicians can focus on delivering quality patient care.

About Wohlig Transformations Pvt. Ltd.

Founded in 2015, Wohlig Transformations specialises in GenAI and DevOps, with 160+ professionals across India and the UK.

Detailed Case Study : https://youtu.be/Su_aMgb5o5Q

Mahindra & Mahindra partnered with Wohlig Transformations to build an AI-powered Vehicle Development, Benchmarking, and Product Planning Platform on Google Agent Development Kit (ADK) + Gemini 3 Flash, evolving from a 90-spec MVP into a production platform analysing 207 specs per car across three integrated functions.

Project Overview

Mahindra & Mahindra‘s R&D, product-planning, and competitive-intelligence teams partnered with Wohlig Transformations to put AI at the centre of how vehicle decisions get made. The engagement began in February 2026 with a focused 3-week SOW: an ADK-powered automotive benchmarking agent covering 90 car specs, car-only competitor analysis, and integration with Mahindra’s existing ChatAI on Google Cloud. The MVP proved the approach quickly — and on the strength of that impact, Mahindra expanded the scope substantially. The production platform now covers 207 specs per car across three integrated functions — Vehicle Development, Benchmarking, and Product Planning — with a custom React.js UI/UX, ADK exposed as the REST API backend, user RBAC (admin / analyst / viewer), custom views per spec or spec group, chat history across sessions, and multi-file upload for document intelligence. A multi-source data layer — Google Custom Search API, web scraping, YouTube Data API v3, and PDF document intelligence — feeds Gemini 3 Flash agents, all deployed on Google Cloud.

The Challenge

Single-Function Bottleneck: The original ChatAI integration only supported competitor benchmarking — but Mahindra’s R&D teams needed an AI workstation spanning vehicle development, benchmarking, and product planning, not a point tool.

Limited Spec Coverage: 90 car specs was the right scope to validate an MVP, but production decisions across SUVs, pickups, commercial vehicles, and tractors demand far richer analytical depth.

Multi-Source Data Sprawl: Vehicle insights live across official automotive sites, expert review portals, YouTube channels, and OEM PDF brochures — no single source covers it all, and stitching them together manually doesn’t scale.

RBAC + Custom Views: Admins, analysts, and viewers each need different surfaces — and analysts often need bespoke spec groupings that a default schema can’t anticipate.

Conversational Continuity: One-off queries weren’t enough; teams needed chat history that preserved investigation context across multi-day workflows.

Key Objectives

• Expand Spec Coverage: Grow from 90 to 207 specs per car to support deep R&D decisions.

• Three Integrated Functions: Unify Vehicle Development + Benchmarking + Product Planning in one platform.

• Custom React UI/UX: Replace the existing-ChatAI integration with a purpose-built frontend driven by ADK as a REST API.

• RBAC + Custom Views: Admin / analyst / viewer tiers plus per-user custom views of individual specs or spec groups.

• Multi-Source Data Integration: Combine web scraping, Google Custom Search API, YouTube Data API v3, and PDF document intelligence with RAG.

• Production Security: Cloud IAM, Secret Manager, API Gateway, end-to-end encryption, and VPC isolation.

The Solution: AI-Powered Vehicle Development + Benchmarking + Product Planning Platform

V1 — The 3-Week MVP (Feb–Mar 2026): An ADK-powered benchmarking agent covering 90 car specs and car-only competitor analysis, integrated with Mahindra’s existing ChatAI. A Python backend on Google Cloud, with RBAC, interactive dashboards, and exportable reports (PDF / Excel / PPT) — delivered in three weeks.

V2 — The Expanded Production Platform: 207 specs per car across three integrated functions — Vehicle Development, Benchmarking, and Product Planning. A custom React.js UI/UX with ADK as the REST API backend, RBAC plus custom views per spec or spec group, chat history across sessions, and multi-file upload with document intelligence (OCR + RAG).

Multi-Source Data Layer: Google Custom Search API (domain-whitelisted to curated automotive sources) + web-scraping pipelines + YouTube Data API v3 (video reviews, expert opinions, sentiment) + PDF brochure ingestion → OCR → vector embeddings → RAG corpus.

AI Core: Vertex AI Gemini 3 Flash agents orchestrated by ADK in a multi-agent pipeline — competitor data extraction → spec normalisation → RAG → comparative insights → report drafting.

Technology Stack: Vertex AI, Gemini 3 Flash, Agent Development Kit (ADK), React.js, Python, FastAPI, Google Custom Search API, YouTube Data API v3, Cloud Run, Cloud Storage, BigQuery, Cloud IAM, Secret Manager, API Gateway, and Cloud Operations Suite.

Key Benefits & Results

• Previous: 90 specs, car-only benchmarking. Our Solution: 207-spec, 3-function platform (Vehicle Development + Benchmarking + Product Planning). Result: 2.3× analytical depth and coverage of the full R&D decision lifecycle.

• Previous: Integration with existing ChatAI (limited UX flexibility). Our Solution: Custom React.js UI/UX with ADK as REST API. Result: Frontend and backend evolve independently — a future-proofed architecture.

• Previous: RBAC tiers only. Our Solution: RBAC + per-user custom views per spec or spec group. Result: Analysts and product planners get bespoke surfaces without admin intervention.

• Previous: Stateless queries. Our Solution: Chat history across sessions. Result: Investigation context preserved across multi-day workflows.

• Previous: Single PDF upload. Our Solution: Multi-file upload. Result: Document intelligence across multiple brochures and reports in one session.

• Previous: Single-source competitor data. Our Solution: Multi-source integration (Custom Search + Web Scraping + YouTube + Document RAG). Result: Richer, cross-validated insights for product decisions.

• Previous: Manual report drafting. Our Solution: AI-generated comparative reports. Result: Exportable PDF / Excel / PPT outputs ready for stakeholder review.

Technical Innovation

ADK as REST API + React Frontend: A modular architecture where Google’s Agent Development Kit is exposed as a backend microservice and the frontend is a custom React.js application. Frontend and backend evolve independently — Mahindra can change UX patterns without touching agent logic, and Wohlig can swap models or pipelines without touching the UI.

207-Spec Schema with Custom Views: A full automotive specification schema (engine, safety, comfort, infotainment, dimensions, performance, and more) at 207 fields per car, with user-defined custom views that let analysts pivot on any combination of specs or spec groups.

Multi-Source AI Pipeline: Google Custom Search API (domain-whitelisted to curated automotive sources) + web scraping + YouTube Data API v3 + PDF document intelligence with OCR + RAG — four orthogonal data streams unified by ADK orchestration and Gemini 3 Flash insight generation.

RBAC + Chat History + Multi-File Upload: Production-grade experience features — admin / analyst / viewer tiers, persistent chat history, and multi-document upload with RAG — layered on top of the agent, and uncommon in MVP-stage automotive AI tools.

Continuous Scope Expansion: A 3-week SOW MVP that grew into a sustained production engagement. The V1 → V2 jump — 90 → 207 specs, single → three functions, integration → custom UI — demonstrates Wohlig’s ability to evolve a product alongside client adoption.

Wohlig’s Approach

1. Architecture & setup — GCP project setup, access finalization, and platform integration scoping.

2. AI & data pipeline development — Web scraping + Google Custom Search API + YouTube Data API v3 integrations, Gemini 3 Flash workflows, and ADK orchestration.

3. Visualization & reporting — Interactive dashboards, report templates, and multi-format export (PDF / Excel / PPT).

4. V1 deployment & UAT — Cloud Run deployment, Cloud IAM + RBAC, monitoring, and Mahindra UAT.

5. V2 scope expansion — 207-spec schema; three functions (Vehicle Development + Benchmarking + Product Planning); React.js UI/UX rebuild; ADK as REST API; custom views; chat history; multi-file upload.

6. Continuous iteration — Documentation, training, knowledge transfer, and ongoing optimization with Mahindra’s R&D and product-planning teams.

About Mahindra & Mahindra

Mahindra & Mahindra Ltd. is one of India’s largest multinational automotive corporations, headquartered in Mumbai. Part of the globally diversified Mahindra Group, its portfolio spans SUVs, pickup trucks, commercial vehicles, tractors, and emerging mobility solutions across India, South Africa, Australia, and Latin America. Mahindra’s R&D and product-planning functions are leading AI adoption to accelerate vehicle development and competitive intelligence.

About Wohlig Transformations Pvt. Ltd.

Founded in 2015, Wohlig Transformations specialises in GenAI and DevOps, with 160+ professionals across India and the UK.

Detailed Case Study : https://youtu.be/EQiKatjFpKI

Project Overview

Dr. Reddy’s Laboratories (DRL) partnered with Wohlig Transformations in a two-phase engagement — starting with a 1-week Google Cloud GenAI workshop and continuing into an ongoing engineering engagement building Project Cognito, DRL’s AI-powered drug prioritization platform. The first production pillar shipped is the IP (Intellectual Property) Pillar — a multi-model patent-landscape analysis pipeline (Gemini extracts, Claude judges) running across four analytical dimensions.

DRL’s R&D, Manufacturing, Quality, and Biologics functions — led by Nishit Mittal as Data Science Lead — engaged Wohlig to accelerate GenAI adoption across drug-development decision-making. The work followed a deliberate Workshop → Production arc: a 1-week capability demonstration first, then a continuous production-engineering relationship. In that second phase, Wohlig is building Project Cognito, DRL’s umbrella platform for drug prioritization and research automation, delivered as discrete production pillars. The first to ship is the IP Pillar, a multi-model pipeline that pairs Gemini for extraction with Claude as a judge across four analytical dimensions, runs on 10 parallel Cloud Run instances, retrieves from a ChromaDB vector store, and refreshes automatically on a bi-weekly schedule.

The Challenge

Capability Demonstration

Before committing to a long-term AI engineering engagement, DRL’s R&D leadership needed to see Wohlig build production-grade patterns end-to-end on real pharma use cases — not slideware.

Patent Landscape Complexity

A drug’s IP exposure spans composition-of-matter, formulation, device, and process patents — each with different inclusion logic, jurisdictional nuances, and litigation history.

Multi-Source Data Sprawl

Patent data lives across Espacenet, Google Patents, and the Indian Patent Database (IPD); clinical evidence spans 6+ international registries. Each source has its own schema, latency, and gaps.

LLM Fragility

Single-model patent analysis hallucinates classifications, misses contextual Tier-3 matches, and produces malformed JSON — none of which is acceptable in a system informing real drug-investment decisions.

Production Scale

A bi-weekly refresh across hundreds of drugs requires parallel compute, retry strategies, incremental processing, and cost discipline — far beyond what a notebook prototype provides.

Key Objectives

• Workshop-First Demonstration: Build all three workshop modules end-to-end on Google Cloud (ADK + Vertex AI + Document AI + Vector Search + Cloud Run).

• Multi-Model Verification: Use Gemini for extraction and Claude as judge to catch hallucinations on every field.

• Tiered Patent Inclusion: Codify a Tier 1 / Tier 2 / Tier 3 taxonomy that surfaces every relevant patent, including non-obvious contextual matches.

• Multi-Source Coverage: Index every relevant patent and clinical-trial source (Espacenet, Google Patents, IPD, ClinicalTrials.gov, PubMed, ChiCTR, EU CTR, CTRI India, JRCT Japan).

• Production Compute: Parallel Cloud Run pipelines, Cloud Scheduler refresh, BigQuery storage, and an AlloyDB migration path.

• Continuous Optimization: Cost monitoring, per-dimension evaluation metrics, and knowledge transfer to DRL.

The Solution: Two-Phase GenAI Engagement

Phase 1: 1-Week Workshop

A Google Cloud GenAI workshop delivered three hands-on modules end-to-end.

Module 1 was a multi-agent Intelligent Chatbot built on four ADK agents (Structured Data, Unstructured Data, Web Search, and a Response Aggregator) with custom RAG on Vertex AI Vector Search.

Module 2 was a Document Intelligence pipeline for FDA Complete Response Letter (CRL) analysis using Document AI plus four specialized agents (Checklist, Summary, Metadata, Cross-Reference).

Module 3 was an MCP (Model Context Protocol) server giving a natural-language interface to BigQuery and Cloud SQL, containerised on Cloud Run.

Phase 2: Project Cognito

In the ongoing engagement, Wohlig built Project Cognito’s IP Pillar end-to-end, scaling the workshop’s proven patterns into a production system.

IP Pillar Architecture

Gemini extracts, Claude judges; 10 parallel Cloud Run instances per run; a ChromaDB vector store with k=12 KNN cosine similarity; sliding-window overlap with section-aware chunking; a metadata pre-filter (year, jurisdiction, patent type, assignee); Cloud Scheduler bi-weekly refresh; and all evaluation fields stored in BigQuery.

Tier 1 / Tier 2 / Tier 3 Patent Inclusion

Drug-name, brand, and Orange Book references resolve to Tier 1; chemical-structure matches to Tier 2; and assignee plus device, formulation, and process signals with a product-specific link to Tier 3.

Multi-Source Data Integration

Espacenet and Google Patents are pre-fetched in parallel, a reverse-engineered IPD fetcher fills the Indian Patent Database gap, and six clinical trial registries are indexed.

Technology Stack

Vertex AI, Gemini, Claude, Agent Development Kit (ADK), Document AI, Vertex AI Vector Search, BigQuery, Cloud Run, Cloud Scheduler, Firestore, Cloud Storage, Secret Manager, ChromaDB (→ AlloyDB planned), FastAPI, and Python.

Key Benefits & Results

Previous: One-shot single-model LLM patent analysis with high hallucination risk.

Our Solution: Gemini extracts and Claude judges with parallel verification.

Result: Every field is cross-checked; failed checks trigger correction with confidence recalculation.

Previous: Tier-1-only patent search that misses contextual matches.

Our Solution: Tier 1 / Tier 2 / Tier 3 taxonomy.

Result: Captures composition-of-matter, formulation, device, process, and dosing patents that assignee-only or direct-mention search misses.

Previous: Single patent source coverage gaps.

Our Solution: Parallel Espacenet + Google Patents pre-fetch plus a reverse-engineered IPD fetcher.

Result: Patent data normally requiring millions in third-party fees, now in-house.

Previous: Tavily API cost for web search.

Our Solution: Migrated to the Vertex AI Google Search tool with domain restriction and keyword match.

Result: Lower cost, better coverage.

Previous: Sequential pipeline runs and slow refresh.

Our Solution: 10 parallel Cloud Run instances with CLOUD_RUN_TASK_INDEX work distribution and Cloud Scheduler automation.

Result: Production-ready bi-weekly refresh across hundreds of drugs.

Previous: Notebook prototypes only (Phase 1).

Our Solution: Production deployment on Cloud Run with BigQuery storage and monitoring.

Result: Workshop patterns scaled into a real production system in Phase 2.

Technical Innovation

Gemini + Claude Multi-Model Judging

Gemini extracts patent data; Claude evaluates and verifies every field in batches of 10 across 8 parallel API calls. Failed checks trigger correction with confidence recalculation — removing single-model hallucination risk entirely.

Tier 1 / Tier 2 / Tier 3 Patent Inclusion Logic

An explicit, codified taxonomy for direct drug, brand, and code mentions, chemical-structure matches, and contextual assignee plus product-type matches. It catches the Tier 3 patents most pipelines miss.

Mandatory Blocking Category Classification

Every patent receives a non-empty classification (composition_of_matter, formulation, device, and more), read directly from the patent claims rather than the title or abstract. This drives downstream dimension routing.

Reverse-Engineered IPD Fetcher

Replaces a third-party service that charges millions for Indian Patent Database fields. Built in-house, it was immediately cost-positive in operation.

Parallel Cloud Run Compute

10 instances per pipeline run with CLOUD_RUN_TASK_INDEX work distribution, exponential-backoff retries for Gemini and Claude rate limits, and incremental processing (insert new, skip unchanged) — production scale, not POC scale.

Wohlig’s Approach

1. Workshop & capability demonstration — a 1-week hands-on build of three modules covering the agentic chatbot, document intelligence, and MCP-server data-lake access.

2. Kickoff & architectural design — defining the multi-pillar Project Cognito architecture, with the IP Pillar selected as Pillar 1.

3. Multi-model pipeline engineering — Gemini + Claude judge integration, ChromaDB retrieval, tiered inclusion logic, and Blocking Category Classification.

4. Multi-source data integration — Espacenet, Google Patents, and the reverse-engineered IPD fetcher; plus ClinicalTrials.gov, PubMed, ChiCTR, EU CTR, CTRI India, and JRCT Japan.

5. Production compute engineering — 10 parallel Cloud Run instances, Cloud Scheduler bi-weekly refresh, and BigQuery evaluation storage.

6. Evaluation framework & continuous iteration — per-dimension metrics (faithfulness, context precision, answer relevancy, cross-dimension coherence), knowledge transfer, the planned AlloyDB migration for production scale, and the upcoming Medical Potential, API Complexity, and Complexity Pillars.

About Dr. Reddy’s Laboratories

Dr. Reddy’s Laboratories Limited (DRL) is a Hyderabad-headquartered global pharmaceutical company specialising in generics, biosimilars, and proprietary products. Its R&D, Manufacturing, Quality, and Biologics functions are leading AI adoption across drug-development decision-making, regulatory document processing, and patent-landscape analysis.

About Wohlig Transformations Pvt. Ltd.

Founded in 2015, Wohlig Transformations specialises in GenAI and DevOps, with 160+ professionals across India and the UK.

Detailed Case Study : https://youtu.be/i1rsUJcgeow

Project Overview

KreditBee partnered with Wohlig Transformations to validate a Google Cloud migration path for its AWS-native application stack — using an AI-assisted development workflow to compress the core migration into 2–3 days and dedicate the remaining engagement to end-to-end testing and standards definition.

KreditBee runs its core application stack on AWS — Lambda (Go), API Gateway, SNS/SQS, S3, and RDS MySQL. As part of its cloud strategy, KreditBee engaged Wohlig to evaluate Google Cloud Platform as a potential migration target. This Google Cloud DAF-funded proof-of-concept migrated the application development environment to GCP, validated the technical feasibility of the equivalent GCP stack, and established the standards that will drive the eventual production migration.

Using an AI-first approach, the engagement delivered 18 Cloud Run Functions, 11 Dockerfiles, 7 Apigee API proxies, and more than 50 Pub/Sub topics while documenting reusable patterns for future production rollout.

The Challenge

Multi-Service AWS Footprint

A core stack spanning Lambda, API Gateway, SNS/SQS, S3, RDS MySQL, Fargate crons, and Secrets Manager required credible Google Cloud equivalents rather than a simple lift-and-shift approach.

Compressed POC Window

The project had a 10-day implementation budget to validate migration feasibility without sacrificing quality, governance, or testing rigor.

Terraform Provider Switch

Existing AWS Terraform configurations needed to be translated to the Google Cloud provider across modules, resources, variables, and deployment workflows.

Delayed Messaging Semantics

AWS SQS delayed-message patterns do not map directly to Pub/Sub and required a different architectural approach to preserve business behavior.

Production-Path Standards

The proof of concept needed to establish reusable naming conventions, infrastructure standards, containerization patterns, and API governance models suitable for production scale.

Key Objectives

• AI-First Migration: Accelerate conversion using AI-assisted development while maintaining human review and testing.

• End-to-End Equivalence: Validate every AWS-to-GCP service mapping through integration testing.

• Terraform-Managed Infrastructure: Deploy all resources as code with no manually configured infrastructure.

• Delayed Messaging Support: Recreate SQS delayed-message behavior using native Google Cloud services.

• Production Standards: Define scalable architecture, deployment, and governance patterns for future migrations.

The Solution: AI-Assisted AWS to GCP Migration

Service Mapping

AWS ServiceGoogle Cloud EquivalentAPI GatewayApigeeLambda (Go)Cloud Run FunctionsSNS / SQSPub/SubS3Cloud Storage (GCS)RDS MySQLSelf-managed MySQL on Compute EngineFargate (Cron Jobs)GKE Pilot / Cloud Run JobsCloudWatch / EventBridgeCloud SchedulerSecrets ManagerSecret ManagerDelayed SQS MessagesCloud Tasks

AI-Assisted Migration Workflow

The migration leveraged AI across three complementary approaches.

Inline IDE Assistance

Used for bulk Lambda-to-Cloud Run Function conversion, replacing AWS SDK integrations with Google Cloud client libraries and generating boilerplate code.

Agentic Migration

Handled Terraform provider translation, complex stateful functions, and messaging pattern conversions from SNS/SQS to Pub/Sub.

Model-Level Pattern Review

Provided reusable migration templates, architecture consistency checks, and QA reviews for AI-generated outputs.

Every workload followed a structured process:

Analyse → Generate → Human Review → Test → Commit

No function was deployed without human validation.

Landing Zone

A production-aligned Google Cloud foundation was established consisting of:

• 1 Organization

• 1 Folder

• 3 Projects (Network Host, Application, Shared Services)

• Shared VPC

• IAM controls

• Organization Policies

• Billing integration

Application Architecture

Apigee serves as the API gateway layer in front of Cloud Run Functions developed in Go.

Pub/Sub and Cloud Tasks manage asynchronous messaging workloads.

Cloud Storage handles object storage requirements.

MySQL runs on Compute Engine behind a bastion host.

Cloud Scheduler orchestrates cron-based processes, while Secret Manager stores application credentials.

CI/CD

Existing GitHub Actions pipelines were migrated to Google Cloud using Workload Identity Federation (WIF) for keyless authentication and Terraform-managed deployments.

Technology Stack

Cloud Run Functions, Apigee, Pub/Sub, Cloud Tasks, Cloud Storage, Cloud Scheduler, Secret Manager, Compute Engine, MySQL, Workload Identity Federation (WIF), Terraform, and GitHub Actions.

Key Benefits & Results

Faster Function Migration

Previous: Multi-week Lambda-by-Lambda migration.

Solution: AI-assisted conversion pipeline with engineering oversight.

Result: 18 Lambda functions migrated to Cloud Run Functions in 2–3 days.

Infrastructure-as-Code Modernization

Previous: AWS-specific Terraform dependencies.

Solution: AI-assisted Terraform provider conversion.

Result: Complete GCP Terraform module suite covering networking, databases, identity, storage, scheduling, messaging, and API management.

API Modernization

Previous: AWS-native API routing.

Solution: Apigee implementation.

Result: 7 API proxies supporting custom domains, CORS policies, and load balancing.

Messaging Modernization

Previous: SNS/SQS architecture.

Solution: Pub/Sub combined with Cloud Tasks.

Result: More than 50 Pub/Sub topics with preserved delayed-message functionality.

Repeatable Deployments

Previous: Console-configured infrastructure.

Solution: Fully Terraform-managed resources.

Result: Version-controlled, repeatable, and code-reviewed deployments.

Production Readiness

Previous: Temporary proof-of-concept implementations.

Solution: Standards-first architecture and documentation.

Result: Production-ready Terraform modules, naming standards, containerization patterns, and Apigee governance guidelines.

Technical Innovation

AI-First Migration Framework

A combination of IDE assistance, agentic workflows, and model-driven review accelerated migration timelines while maintaining engineering quality controls.

Cloud Tasks for Delayed Messaging

Because SQS delayed messages do not directly map to Pub/Sub, Cloud Tasks was introduced alongside Pub/Sub to preserve delayed-delivery behavior without changing business logic.

Workload Identity Federation Everywhere

GitHub Actions and inter-service communication relied on keyless authentication using Workload Identity Federation, eliminating long-lived service account keys.

Inverted Timeline Allocation

Traditional migrations often spend weeks on code conversion and days on validation.

This project completed conversion in 2–3 days and dedicated the majority of the engagement to integration testing and quality assurance.

Production-Scale Standards

All validated patterns—including Terraform modules, naming conventions, containerization approaches, and Apigee configurations—were designed for future production adoption rather than temporary proof-of-concept use.

Wohlig’s Approach

1. Catalogued and classified every Lambda function, trigger, environment variable, and AWS dependency.

2. Established the Google Cloud landing zone, Shared VPC, IAM model, organizational hierarchy, and billing foundation.

3. Used AI-assisted development to migrate 18 critical Lambda functions and convert Terraform configurations to Google Cloud equivalents.

4. Implemented supporting services including Pub/Sub, Cloud Tasks, Apigee, GitHub Actions migration, and Workload Identity Federation.

5. Performed end-to-end validation covering onboarding flows, messaging systems, database connectivity, scheduled jobs, and API routing.

6. Delivered migration runbooks, production recommendations, and knowledge-transfer sessions to the KreditBee engineering team.

About KreditBee

KreditBee, operated by Krazybee Services Limited, is a Bengaluru-based fintech company providing digital lending solutions for salaried and self-employed professionals across India. Founded in 2016, the company is an RBI-registered systemically important Non-Banking Financial Company (NBFC).

About Wohlig Transformations Pvt. Ltd.

Founded in 2015, Wohlig Transformations specializes in GenAI and DevOps, with more than 160 professionals across India and the United Kingdom.

Detailed Case Study : https://youtu.be/M9V5tYhfShc

Project Overview

Meesho partnered with Wohlig Transformations to build an end-to-end Document Intelligence platform spanning three key pillars: Google Workspace for document authoring and governance, Gemini Enterprise for conversational access and retrieval, and a custom ADK agent running on Vertex AI Agent Engine to provide depth-aware, fully cited enterprise search.

Meesho operates using a BHAG (Big Hairy Audacious Goals) framework across functions such as Pricing, Monetisation, CPDO, Ranking, and Growth. These teams continuously generate strategic documents including R2R reviews, PFS sessions, working sessions, and KR documents. As the organization scaled, these artifacts became fragmented across individual Google Drive accounts, creating challenges around governance, discoverability, and organizational alignment.

To address this, Wohlig delivered a two-phase platform on Google Cloud.

Phase 1 focused on document governance and ingestion across Google Workspace.

Phase 2 introduced an AI-powered ADK agent integrated into Gemini Enterprise, enabling employees to query organizational knowledge through natural language while preserving document-level access controls.

The Challenge

Inconsistent Document Quality

There was no standardized process to enforce document quality before storage. Teams used different templates, resulting in incomplete and inconsistent documentation.

No Central Repository

BHAG documents were distributed across individual Google Drive accounts, making enterprise-wide knowledge sharing difficult.

Zero AI Discoverability

Employees had no way to search organizational knowledge using natural language.

Incomplete Retrieval Results

The Gemini Enterprise Drive connector returned document snippets rather than complete content, often exposing only a fraction of the available information.

Retrieval API Limitations

The Discovery Engine :answer endpoint permanently rejected custom GCP OAuth implementations, preventing adoption of the intended retrieval architecture.

Service Account Restrictions

Workspace datastore retrieval returned HTTP 403 errors when accessed through service account credentials, requiring an alternative authentication approach.

Key Objectives

• Enforce document quality before documents enter the repository.

• Create a centralized and permission-safe knowledge repository.

• Improve compliance through proactive governance and automated reminders.

• Provide deterministic retrieval depth independent of LLM behavior.

• Ensure complete citation coverage for every answer.

• Eliminate incremental AI inference costs by leveraging existing Gemini Enterprise licenses.

The Solution: Two-Phase Document Intelligence Platform

Phase 1: Document Governance & Ingestion System

Phase 1 introduced ten integrated components governing the entire document lifecycle within Google Workspace.

Custom Template Governance

A Custom Google Template Gallery combined with a Chrome Extension ensured that employees could only access Meesho-approved document templates while hiding Google’s default templates.

8-Rule Audit Engine

An Apps Script Add-on embedded directly into Google Docs validated documents against predefined compliance rules stored in Google Sheets.

The engine:

• Scored each document section from 0–100%

• Evaluated compliance automatically

• Prevented submission until all required sections passed validation

Submit-to-Meesho-Memory Workflow

Documents that passed compliance checks were automatically submitted into the central repository.

The workflow:

• Used the author’s Google Drive token

• Applied repository labels

• Sent confirmation notifications

• Preserved ownership and permissions

Governance & Adoption Automation

Several automated governance mechanisms were introduced:

• In-document nudge notifications

• Meeting invite monitoring

• Daily compliance reminders

• Escalation workflows to managers

• Organization-wide document audits

The backend architecture was later migrated from Apps Script to Cloud Run, with Cloud Scheduler replacing all scheduled triggers.

Keyless Domain-Wide Delegation

JWT signing was performed through the IAM Credentials API, eliminating the need for service account JSON keys.

Phase 2: ADK Agent Inside Gemini Enterprise

The second phase introduced a custom ADK agent registered within Gemini Enterprise Agent Space.

Employees could access organizational knowledge directly from the Gemini Enterprise chat interface they already used daily.

The solution evolved through six architectural versions:

• v1: SequentialAgent baseline

• v2: Parallel per-document extraction

• v3: Wiki-based retrieval

• v4: StreamAssist proof of concept

• v5: Batched parallel StreamAssist architecture

• v6: Production Zero-Vertex Pipeline

Depth-Aware Retrieval Architecture

The production architecture routes queries based on requested depth.

Small Queries

Handled through a single StreamAssist request with suggested follow-up questions.

Medium, Detailed & Exhaustive Queries

A three-stage pipeline executes:

1. Identify

   • Selects the most relevant documents from a candidate pool of up to 91 documents.

   • Generates focused extraction prompts.

2. Batched Parallel StreamAssist

   • Retrieves information from multiple documents simultaneously.

   • Executes 5–10 concurrent retrieval operations for exhaustive searches.

3. Merge

   • Synthesizes results into a single answer.

   • Produces 3–15 citations.

   • Generates follow-up recommendations.

OPT-5 Speculative Prefetch

Candidate retrieval begins in parallel with intent classification, eliminating a complete retrieval round-trip and improving response latency.

Wiki Builder

A Claude-powered wiki generation process consolidates information across multiple documents while preserving inline citations.

Technology Stack

Phase 1

• Cloud Run

• Google Apps Script Add-on

• Chrome Extension (Manifest V3)

• Cloud Scheduler

• Google Drive API

• Google Sheets API

• Drive Labels API

• IAM Credentials API

• Gmail SMTP (Nodemailer)

Phase 2

• Gemini Enterprise

• Gemini Enterprise Agent Space

• StreamAssist API

• Google ADK 1.30.0

• Vertex AI Agent Engine

• Discovery Engine API

• Gemini 3.1 Pro Preview

• Gemini 3 Flash Preview

Security & Access Control

The solution preserves Google Workspace permissions by injecting the end user’s Gemini Enterprise Drive OAuth bearer token into every retrieval request.

This ensures:

• Workspace ACL compliance

• User-level permission enforcement

• No unauthorized document exposure

Keyless Domain-Wide Delegation uses IAM Credentials API signing, eliminating service account key storage entirely.

Key Benefits & Results

Standardized Documentation

Previous: No document template standards.

Solution: Custom Template Gallery and Chrome Extension.

Result: Only approved templates available organization-wide.

Centralized Knowledge Repository

Previous: Documents scattered across personal drives.

Solution: Audit engine and submission workflow.

Result: Centralized repository with compliance enforcement.

Governance Visibility

Previous: Limited awareness of document compliance.

Solution: Automated scans, nudges, and escalation workflows.

Result: Organization-wide compliance monitoring.

Improved Retrieval Quality

Previous: Snippet-only search results.

Solution: StreamAssist retrieval using dataStoreSpecs.

Result: Complete document access with ACL enforcement.

Deterministic Search Depth

Previous: LLM-driven retrieval limitations.

Solution: Python-based parallel retrieval orchestration.

Result: Search depth enforced through code rather than model behavior.

Retrieval API Workaround

Previous: Discovery Engine answer endpoint restrictions.

Solution: StreamAssist API adoption.

Result: Fully functional enterprise retrieval.

Authentication Reliability

Previous: Service account authentication failures.

Solution: Per-user OAuth bearer token injection.

Result: Zero authorization failures.

Full Citation Coverage

Previous: Flash model responses without citations.

Solution: Gemini Pro retrieval with text grounding metadata.

Result: 3–15 citations per answer.

Zero Incremental AI Cost

Previous: Per-token Vertex AI inference costs.

Solution: All retrieval and synthesis workloads executed through Gemini Enterprise licensing.

Result: ₹0 incremental AI cost per query regardless of usage volume.

Technical Innovation

Two-Layer Document Intelligence Architecture

Phase 1 ensures document quality and governance.

Phase 2 makes organizational knowledge discoverable through conversational AI.

AppScript-to-Cloud-Run Migration

The backend was re-platformed during development without service interruption while improving scalability and operational control.

Keyless Domain-Wide Delegation

JWT signing through Google’s IAM Credentials API eliminated the need for service account JSON keys.

StreamAssist-First Retrieval

StreamAssist replaced Discovery Engine’s blocked answer endpoint and became the primary retrieval mechanism.

OPT-5 Speculative Prefetch

Parallel candidate retrieval and intent classification reduced overall query latency.

Zero-Vertex Pipeline

All retrieval, classification, evaluation, and synthesis workloads execute through Gemini Enterprise rather than Vertex LLM agents.

Pro and Flash Model Strategy

Gemini Pro handles retrieval and citation generation.

Gemini Flash handles intent classification for lower latency and cost.

Wohlig’s Approach

1. Defined requirements and designed the governance platform architecture.

2. Built the governance ecosystem, including templates, audit workflows, Chrome extensions, and submission processes.

3. Migrated the backend from Apps Script to Cloud Run.

4. Implemented adoption and governance automation, including nudges, meeting monitoring, escalation workflows, and domain-wide delegation.

5. Completed user acceptance testing and production rollout for Phase 1.

6. Diagnosed limitations of no-code Gemini Enterprise agents, including Discovery Engine restrictions and citation limitations.

7. Iteratively evolved the ADK architecture through six versions before arriving at the production-ready Zero-Vertex Pipeline.

8. Deployed the solution on Vertex AI Agent Engine, registered the ADK agent in Gemini Enterprise Agent Space, and completed organization-wide rollout.

About Meesho

Meesho is India’s leading social commerce platform, enabling millions of small businesses to sell online. Its BHAG-driven operating model generates a large volume of strategic planning documents, making enterprise knowledge discovery and governance critical to operational effectiveness.

About Wohlig Transformations Pvt. Ltd.

Founded in 2015, Wohlig Transformations specializes in GenAI and DevOps solutions, with more than 160 professionals serving clients across India and the United Kingdom.

Detailed Case Study : https://youtu.be/3lcqvWgBiCc

Project Overview

Meesho partnered with Wohlig Transformations to build a BigQuery Conversational Analytics agent for its Fulfilment & Experience (FnE) team, achieving 100% effective accuracy on 40 held-out evaluation prompts with every result manually verified row-by-row.

The Fulfilment & Experience (FnE) team at Meesho manages end-to-end operations for India’s largest social-commerce platform using a 10-table mercury dataset in BigQuery, comprising more than 224 columns and 64 defined business metrics.

Wohlig developed a BigQuery Conversational Analytics agent, published as FnE_v2_14Apr in BigQuery Studio’s Agent Catalog, enabling business users to ask natural-language questions and receive SQL queries, BigQuery jobs, result tables, auto-generated visualizations, plain-English insights, and knowledge-source references.

The engagement was executed in two phases. Round 1 achieved 89% effective accuracy across 57 evaluation queries, while Round 2 achieved 100% effective accuracy across 40 held-out evaluation prompts after a dataset quality improvement initiative and complete re-engineering of the knowledge base.

The Challenge

SQL Dependency Across Business Operations

The mercury dataset contained 10 tables, 64 metrics, and 68 business rules. Operational questions around refund clearance, LDR breaches, RTO percentages, NPS, and dispatch performance required analysts to manually write SQL.

Dataset Quality Constraints

The initial implementation reached 89% effective accuracy. Investigation showed that the remaining performance gap stemmed primarily from inconsistencies within the underlying dataset rather than limitations of the conversational analytics agent.

Evaluation Trustworthiness

Enterprise-grade analytics systems cannot rely on LLM-generated evaluation. Every output needed verification at the data level through direct comparison against trusted reference outputs.

Spark-to-BigQuery Conversion Challenges

During migration and reconciliation, 11 Spark normalization issues were discovered and corrected before outputs could be trusted as ground truth.

Overfitting Risk

A critical requirement was ensuring that evaluation prompts remained completely separate from training and verification datasets to avoid artificially inflated results.

Key Objectives

• Enable natural-language access to operational data without requiring SQL expertise.

• Validate outputs through row-by-row and cell-by-cell verification.

• Maintain complete separation between verified training queries and evaluation prompts.

• Ground responses in schema definitions, glossary terms, joins, and business rules.

• Create a repeatable methodology capable of scaling across future datasets.

The Solution: Two-Round Conversational Analytics Program

Round 1: Initial Dataset Evaluation

The first version of the agent was evaluated against 57 reference queries and achieved 89% effective accuracy, consisting of:

• 21 MATCH

• 30 ACCEPTABLE

• 6 genuine failures

Analysis revealed that remaining inaccuracies were driven by dataset quality issues rather than agent logic.

Round 2: FnE Cleaned Dataset

After Meesho engineered a cleaned version of the dataset, Wohlig rebuilt the schema understanding, instructions, glossary, and verified query set.

The updated agent achieved:

• 31 MATCH (77.5%)

• 5 NEAR_MATCH (12.5%)

• 4 ACCEPTABLE (10%)

• 0 NOT_MATCH

Resulting in 100% effective accuracy across all 40 held-out evaluation prompts.

Schema and Knowledge Foundation

The solution incorporated:

• 10 table descriptions

• 8 join relationships

• 88 glossary terms

• 225 documented columns

• 20+ critical field recommendations

The glossary included detailed formula definitions and denominator disambiguation to eliminate ambiguity in business metrics.

Structured Instruction Framework

The agent was governed by:

• 83 MUST/NEVER rules

• 21 instruction categories

• 14 BAD/GOOD examples

• Mandatory filters

• Bucket-metric and date-anchor mappings

This transformed loosely defined business rules into deterministic operational behavior.

Verified Query Set

A set of 73 verified queries was created:

• 57 queries from the MIA Metric List

• 16 supplementary patterns

The verified query set maintained zero overlap with evaluation prompts.

Three-Way Validation Framework

Outputs were validated across:

Spark on Dataproc ↔ BigQuery Conversion ↔ Agent SQL

This process achieved:

• 97/97 functional parity

• 40/40 evaluation queries validated

• 57/57 golden queries validated

Technology Stack

• BigQuery Conversational Analytics API

• BigQuery Studio (Agents Preview)

• Dataplex

• Dataproc

• BigQuery Mercury Dataset

• Gemini

Key Benefits & Results

Reliable Evaluation

Previous: LLM-as-judge evaluation.

Solution: Cell-by-cell manual verification.

Result: Every evaluation verdict was based on actual output data.

Accuracy Improvement

Previous: 89% effective accuracy.

Solution: Cleaned dataset and rebuilt knowledge framework.

Result: 100% effective accuracy on 40 held-out evaluation prompts.

Reference Consistency

Previous: Spark and BigQuery output drift.

Solution: Three-way validation methodology.

Result: 97/97 functional parity and 11 normalization issues identified.

Reduced Hallucinations

Previous: Risk of invented fields and incomplete logic.

Solution: 88-term glossary, 83 instruction rules, and worked examples.

Result: Zero genuine logic failures.

Evaluation Integrity

Previous: Risk of training/evaluation overlap.

Solution: Strict separation between verification and evaluation datasets.

Result: Production-safe and auditable evaluation process.

Improved User Experience

Previous: Manual SQL creation for every business question.

Solution: Conversational Analytics Agent in BigQuery Studio.

Result: SQL generation, execution, visualization, insights, and follow-up recommendations delivered through a single interface.

Technical Innovation

Three-Way Validation Methodology

Every output was validated through direct reconciliation across Spark, BigQuery, and generated SQL before the agent was evaluated.

Manual Row-Level Verification

No LLM-as-judge approach was used. Outputs were evaluated through direct row, column, and cell comparisons. Every NEAR_MATCH and ACCEPTABLE verdict was documented with written justification.

Deterministic Operating Framework

The solution incorporated:

• 88 glossary terms

• 83 MUST/NEVER rules

• 14 worked examples

• Fixed data windows

• 1.5 TB query scan limits

This established a predictable and controlled operational environment.

Repeatable Methodology

The same methodology that identified dataset limitations in Round 1 enabled 100% effective accuracy after data improvements in Round 2, demonstrating repeatability across evolving datasets.

Wohlig’s Approach

1. Collected and audited six input artifacts including tables, metrics, business rules, dimensions, and evaluation prompts.

2. Performed Spark-to-BigQuery conversion with detailed parity validation and correction of normalization issues.

3. Developed schema documentation, glossary definitions, join mappings, and column descriptions.

4. Created structured instruction frameworks, business logic rules, and worked examples.

5. Built a verified query repository with complete separation from evaluation datasets.

6. Trained, evaluated, and published the final agent in BigQuery Studio while delivering full evaluation reports to Meesho and Google for independent review.

About Meesho

Meesho is India’s leading social-commerce platform, enabling millions of small businesses to sell online. Its Fulfilment & Experience (FnE) organization manages the end-to-end customer journey from order placement through delivery, claims, returns, customer support, and post-sale operations.

About Wohlig Transformations Pvt. Ltd.

Founded in 2015, Wohlig Transformations specializes in GenAI and DevOps solutions, with more than 160 professionals serving clients across India and the United Kingdom

.Detailed Case Study : https://youtu.be/OuRF7hlSNNc