From Service Desk to Agent Fabric — MCP Playbook and the Future of Indian IT Outsourcing

Uber’s engineering team has published material describing a meaningful shift in how they operate AI inside the company. They have moved Model Context Protocol (MCP) from a pilot into a standardised internal platform. Their published numbers — in the engineering blog and the accompanying conference talk linked at the foot of this post — describe in the order of sixty thousand weekly AI tasks flowing through a centralised gateway, with around ten thousand internal services exposed as agent-callable tools. Engineers and non-technical staff compose those tools into workflows through either a no-code builder or SDKs, with governance, redaction and access control inside the platform rather than in each agent.

That is interesting on its own technical merits. It becomes much more interesting if you sit in Bangalore, Pune, Hyderabad, Chennai or Noida and run a large infrastructure-delivery organisation for global clients. The pattern Uber has industrialised internally is, in shape, the same pattern that Indian IT outsourcing has been circling around for years without quite landing.

This article walks through what Uber appears to have built, separates that confirmed picture from my own extrapolation into the outsourcing world, places it in a maturity model, and addresses the political and commercial reasons why the rollout is harder than the architecture diagrams suggest.

If you only have six minutes, there is a companion executive briefing covering the maturity model, the incentive conflict and the bank case study. This is the long form.

What’s Verified, What’s Mine

Before going further: what Uber has publicly described — the gateway pattern, the auto-conversion of service endpoints into MCP tools, the no-code builder, the weekly-task and service-count numbers — is treated here as the confirmed picture, citable to their public material. The specific figures (60,000 weekly tasks, 10,000 services) come from Uber and should be verified against the linked sources rather than taken on my authority.

Everything that follows about Indian IT outsourcing — the role taxonomy, the workflow examples, the economic envelope, the rollout phases, the incentive analysis, the bank case study — is my extrapolation, informed by fifteen years inside the industry. It is not an Uber statement and should not be read as one.

That separation matters because the Uber numbers travel well — they get repeated in pitch decks and LinkedIn posts without the surrounding caveats — and outsourcing-specific claims get attributed back to Uber in ways that misrepresent what they actually said.

Protocol Versus Platform

A precision point worth getting right up front, because technical readers will object if it is left fuzzy.

MCP itself is a protocol. It specifies how an AI agent describes tools, calls them, and consumes their results. It is open, broadly adopted, and useful. The protocol on its own does not build a platform. HTTP is a protocol — the World Wide Web is the vast set of conventions, infrastructure and tooling built on top of it. MCP sits in the same relationship to a platform like the one Uber has built.

What Uber has built is not “MCP”. It is a gateway, registry, governance and builder platform that uses MCP as its interface contract. The protocol is the load-bearing standard. The platform around it is where most of the engineering investment sits.

For the rest of this article, when I say “the Uber MCP stack” or “an MCP-centred fabric”, I mean the protocol-and-platform combination. When I mean the protocol itself, I will say “the MCP specification”.

Uber’s Build, In Four Pieces

Before standardising MCP, Uber’s AI initiatives looked like most large engineering organisations’ — multiple teams, multiple stacks, multiple ways of calling internal services, and every new agent requiring hand-wired integrations against an estate of around ten thousand services. Governance was worse: each integration had its own access pattern and (often non-existent) data-redaction story. Uber has been candid in their public material that this was the state they were trying to change.

What they built has four moving parts.

A gateway sits between every agent and every internal service. AI traffic terminates there. Authentication, authorisation, rate-limiting, logging and PII redaction happen at a single layer, so that sensitive-data handling is done once rather than once per agent.

A registry catalogues the tools an agent can call. The decisive design choice — and the source of most of the engineering value — is that Uber did not require every team to hand-write an MCP tool definition. Their tooling auto-converts existing service endpoints into MCP tools. New service ships, new tool appears, agents pick it up.

A scanning and access-control layer runs inside the gateway. Every tool registered goes through risk scanning. Every call is bound to a named identity with scoped permissions and is logged.

A builder layer sits on top: a no-code workflow composer for non-engineers, and SDKs for engineers. Both produce workflows that run through the same gateway against the same registry. There is no second-class tier of tools or governance.

Uber’s material also describes a future direction — a skills repository that curates and shares verified multi-step workflows across the organisation, on the model of an internal app store.

What’s Actually Novel

Most of the individual components are not new. API gateways are decades old. Tool registries exist in many forms. Governance is well-trodden territory. What is distinctive is the combination at scale, with one open protocol as the contract, and with auto-generation of tools from existing service definitions.

Specifically: the auto-conversion of endpoints into MCP tools is the multiplier. Without it, exposing ten thousand services as agent-callable would be a years-long manual programme, and most organisations stop at a few hundred. With it, the marginal cost of bringing a new service into the agent surface area drops close to zero, and the platform compounds. Every new tool added makes every existing agent more capable. That compounding is the architectural insight most observers miss.

The single governance chokepoint is the second distinguishing characteristic. Many enterprises have built point AI integrations; few have built one place through which every AI call passes, logged, audited and scoped. That single chokepoint is what makes the platform credible to a public-company audit function.

What It Bought Them

The published numbers — around sixty thousand weekly AI tasks and ten thousand services exposed — are the headline. The qualitative outcomes Uber describes matter as much: governance moving from per-project negotiation to platform property, every new tool exposed making every existing agent more capable, and the population of people able to compose workflows expanding well beyond the AI engineering team.

Verify the methodology against the linked engineering blog and conference talk before quoting these figures further. The definitions of “task” and “service” matter, and pitch-deck repetition tends to lose the qualifiers.

Why MCP And Not An Existing Platform

A reasonable question: why would an outsourcer build an MCP-centred fabric rather than adopt one of the existing platforms already in this space?

ServiceNow’s AI agents and Workflow Studio are strong when ServiceNow is the system of record, weaker when the client estate is multi-vendor.

Microsoft Copilot Studio is excellent if the estate is heavily M365/Azure-centric. The trade-off is platform lock-in and a relatively closed extensibility model.

Moveworks and Aisera are specialist L1-automation vendors — strong out-of-the-box for tickets and natural-language ITSM, less flexible beyond the service desk.

PagerDuty AIOps targets incident response and on-call; not designed as an estate-wide fabric.

UiPath, Automation Anywhere and Blue Prism are RPA platforms with AI features layered in; they work, particularly for legacy systems without APIs, but were not designed around the agent-orchestration model.

Atlassian Rovo, Cortex, and OpenAI operator-style systems are credible newer entrants, worth tracking particularly when the underlying platform is already in use.

The case for an MCP-centred fabric is specifically protocol-openness and multi-tenant flexibility. An Indian outsourcer running infrastructure for thirty different clients does not want to bet on each client’s chosen vendor stack. They want a fabric that can wrap any client’s tool surface — ServiceNow at client A, BMC at client B, Cherwell at client C — into the same agent-callable shape. MCP is the only protocol-level standard that makes that portable.

The honest counterpoint: the MCP ecosystem is younger than any of the platforms above, and the per-tool engineering effort to build wrappers is real. The right answer for most outsourcers is probably both — use Copilot Studio or ServiceNow AI inside specific engagements where platform fit is strong, and stand up an MCP-centred fabric as the cross-client integration substrate that owns multi-tenant governance.

The Outsourcing Mirror

Replace “Uber’s ten thousand internal services” with “a client’s BigFix, SCCM, Intune, ServiceNow, Active Directory, Azure, vSphere, NetBackup, Splunk, CrowdStrike, Citrix DaaS and forty other tools” and the structural picture is the same. Indian IT outsourcing companies run the infrastructure for a large share of the Global 2000. The same constellation of vendor tools, the same heavy ITIL process layer, the same delivery pyramid of engineers operating that process at scale.

A typical infrastructure engagement touches forty to one hundred discrete tools, most with an API and none currently agent-safe. ITIL workflows are structured, repeatable and multi-system — the exact shape an orchestration platform is designed to industrialise. A large outsourcing tower processes hundreds of thousands of tickets a month, of which a meaningful proportion is highly repetitive.

The genuinely difficult difference is multi-tenancy. Uber operates one estate. An outsourcer operates many. The platform has to be multi-tenant by design — strong client isolation, separate audit boundaries, per-client data sovereignty. That is materially harder than the Uber single-tenant build.

The Service Desk Becomes A Routing Layer

A working taxonomy of roles inside a typical infrastructure outsourcing tower, sorted by how aggressively the MCP-centred pattern can be applied.

Fully automated covers password resets, account unlocks, drive and printer mappings, mailbox quota requests, software-catalogue requests, license assignment, standard patch deployment, backup-job verification, daily dashboards, and joiner-leaver provisioning. Structured inputs, well-defined steps, known failure modes. Agents run them; humans review the exception queue.

Agent-led with human approval covers production change execution, privileged access grants, firewall rule additions, DNS changes — anything that would have gone through a CAB. The agent drafts the change record, attaches the technical justification, runs pre-change validation, and produces the back-out plan. A human approves with a click.

Human-led with agent assist covers L2 and L3 incident analysis, root cause analysis, architecture review, capacity planning, vendor escalation, major-incident communications and service-review preparation. The agent gathers diagnostics, summarises logs, retrieves relevant knowledge-base material, and drafts a first version. The human applies judgment, two to four times faster.

Human-only, at least for now, covers Sev-1 crisis leadership with customer C-suite involvement, contract negotiation, performance management, and the conversations that require reading what is not being said. The agent can prepare the brief; the conversation is yours.

The role that changes most is the L1 engineer. Most of the L1 queue today is repetitive triage; after MCP, most of that volume is auto-resolved before reaching a human. The L1 engineer ends up doing what L2 does today — the genuinely novel cases. The role population shrinks but the people in it operate at a higher level.

The patch-management engineer moves from running deployments to owning strategy. The asset and license manager shifts from reconciliation to vendor negotiation. The SDM stops stitching reports together and starts having strategic conversations. L3 specialists are the least affected in volume but the most augmented in capability — the same person designing a thirty-thousand-endpoint patching strategy, with a domain agent at their side that knows every Fixlet and every advisory.

Three Workflows In Detail

Three concrete workflows, each composed from agents calling registered tools through the gateway. Every system referenced is one Indian outsourcers already run for clients.

A — VDI session won’t connect

Today, a ticket of this shape sits in the L1 queue for fifteen to forty-five minutes before an engineer picks it up, asks for basic information the user has not provided, checks four or five systems by hand, and either resolves it or escalates.

With an MCP-centred fabric, the ticket arrives at an orchestrator agent that recognises the symptom class and dispatches in parallel — an Active Directory agent checks account status and recent authentication failures; an Intune agent checks device compliance and last-seen timestamp; a Citrix agent checks session-host availability and active maintenance windows. Within seconds the orchestrator has a structured diagnostic.

If the issue is a known pattern, the orchestrator resolves directly or routes the user to the right self-service path. If the diagnostic shows something unusual, the orchestrator escalates to L2 with the full brief pre-attached. The L2 engineer reads a one-paragraph summary and makes a decision, rather than starting from zero in four different tools.

B — New joiner onboarding

HR fires a “new hire confirmed” event. An onboarding orchestrator reads the role profile and location. An identity agent creates the AD account and provisions the M365 mailbox. A licensing agent assigns the right SKUs. An endpoint agent triggers the laptop build. A collaboration agent adds the new joiner to relevant Teams and SharePoint sites. A VPN agent provisions remote access. A notification agent sends the welcome packet and notifies the manager.

Every step is logged. Every approval that requires a human — sensitive group memberships, elevated privileges, anything outside policy — is routed as a single one-click decision. What used to be a three-to-five-day, twelve-touchpoint process across three teams becomes a four-to-eight-hour automated workflow with a clean audit trail.

C — Emergency patch deployment

A vendor publishes a critical advisory. A vulnerability agent parses it. A CMDB agent identifies affected assets. A risk agent calculates the blast radius. A change agent drafts the emergency CAB record — justification, test plan, back-out plan, customer notification — and routes for one-click approval. A patch agent executes the pilot deployment. A monitoring agent watches for regressions. If no regressions, broader rollout proceeds in stages. A reporting agent generates the customer report at each stage.

The patch-management engineer’s role here is to set the strategy, define the pilot group, review the monitoring envelope, and approve the rollout cadence. One engineer, around an engineer-hour in the loop and four-to-eight hours of wall-clock execution, on a workflow that previously consumed two to three engineers across one-and-a-half days.

From FTE Arbitrage To Outcome Arbitrage

The strategic case is more persuasive with numbers. The figures below are directional, my own estimates based on what I have seen in infrastructure delivery — not Uber numbers and not benchmarks. Real client engagements will move these by a factor of two or three either way depending on tower maturity, tool quality and data hygiene.

These are platform-success-case figures, not industry averages. Realistic deployments will hit the lower bound of the “after” column unless three conditions are met: clean CMDB hygiene, well-classified ticket taxonomy, and an MCP-centred fabric covering at least 60 percent of L1 ticket categories. The “before” column reflects mid-range offshore-billed contracts; US- and Europe-billed contracts run two to three times higher on the L1 cost line.

The L1 auto-resolution rate is the line worth interrogating most carefully. Public Moveworks and Aisera figures advertise 40–60 percent on flagship deployments, but the deployed-average across their customer base is closer to 25–35 percent. The 25–40 percent range above reflects that deployed-average reality, not the marketing number.

The commercial implication, if these numbers hold even directionally, is the structural shift from billed-FTE to billed-outcome. That shift has been talked about in this industry for a decade. The MCP-centred pattern is the first thing I have seen that makes it plausibly executable. Whether the industry actually executes it is a different question — and the most interesting one in this whole article.

The Incentive Problem

The hardest problem here is not technical. It is commercial and political, and the previous version of this article underplayed it.

Outsourcing revenue is FTE-shaped. A typical infrastructure deal is priced as a stack of named roles — L1 engineers, L2 engineers, L3 specialists, SDMs, project managers, change managers — multiplied by a billing rate and a headcount, with volume commitments and tiered SLAs layered on top. When an outsourcer reduces the headcount required to deliver a given service, the immediate effect is a smaller bill to the customer. That is revenue cannibalisation, and it cuts directly against the platform business case.

The same is true at the individual delivery-team level. A tower lead’s annual review is partly shaped by the size of the tower. A practice head’s standing inside the firm is partly shaped by the practice’s billable headcount. When automation reduces both, the people who would have to champion the platform are also the people whose internal position it weakens. This is not a moral failing on their part — it is rational behaviour given how the firm rewards them.

There are four paths through this, and they tend to fail in different ways.

Path one — productivity dividend. Keep the FTE count and use the productivity gains to expand scope or accept new work without growing the team. This is the path of least internal resistance but the one most likely to produce no measurable customer benefit and therefore no commercial differentiation.

Path two — margin retention. Hold the customer price flat, reduce the delivery cost through automation, retain the margin. This works in shorter contracts but creates trust issues at renewal — customers eventually see the AI talking points elsewhere and ask why they are paying yesterday’s price for tomorrow’s delivery model.

Path three — outcome repricing. Move new contracts to per-ticket, per-incident or per-user pricing where automation directly drives margin. This is the structural prize but requires commercial nerve, and the renegotiation conversation is uncomfortable. Existing customers will ask why their renewal terms are changing; new customers will ask whether the model has been proven elsewhere first.

Path four — productivity-billed sharing. Open-book pricing where automation gains are explicitly shared between vendor and customer. Mature, durable, hard to negotiate. Requires the kind of trust relationship that exists in a small minority of outsourcing accounts.

Customers will also resist. Not all customers, but a meaningful share — particularly in regulated industries where automated change execution is uncomfortable, where data-sovereignty constraints make agentic processing politically difficult, or where the customer’s own IT organisation has a vested interest in keeping the outsourcer’s headcount visible and known.

None of this is a reason not to build the platform. It is a reason to plan the commercial conversation as carefully as the technical one. The firms that succeed will be the ones that build the platform and have the commercial discipline to convert the technical capability into a different deal shape. The firms that build the platform but cannot have the conversation will end up with a quietly impressive internal capability that does not show up in revenue.

Where This Can Go Wrong

The first version of this article underplayed operational complexity. The honest list of failure modes.

Automation blast radius. An agent that can change firewall rules across an estate can break that estate at machine speed. Mitigations: layered approvals, staged rollouts, kill switches, per-action blast-radius modelling.

Incorrect remediations. The agent confidently executes a fix that is wrong for the specific environment. Mitigations: bias toward propose-not-execute for production actions, confidence scoring on every action, source attribution.

Data quality dependency. The platform is only as good as the data it relies on. The CMDB problem is the most visible — agents need accurate asset inventory for identification, blast-radius calculation and change correlation, and most long-running outsourcing engagements have CMDB hygiene problems that have been tolerated for years. Beyond CMDB, the same applies to knowledge-base quality (agents grounded in stale or contradictory KB articles produce confidently wrong answers), ticket-taxonomy quality (poorly classified incident categories destroy the orchestrator’s routing accuracy), inconsistent naming and tagging (the same server appearing as three different identities across tools), and the tribal-knowledge problem (the senior engineer who knows the one production server that must not be patched on Wednesdays because of a quirk that was never documented). Standing up the fabric forces these issues into daylight, which is uncomfortable in the short term and necessary in the long term.

Privilege escalation. Scopes too broad means agent compromise gives lateral movement. Mitigations: minimum-privilege per workflow, separate identities per agent, secret rotation, prompt-injection defences.

Audit, legal and data sovereignty. Cross-border inference is a real audit issue; contracts often constrain where prompts can travel. Mitigations: region-pinned gateway, sovereign model selection, redaction before any cross-border hop.

AI-induced outage. Tool-wrapper regression, model behaviour change, or workflow loop can cascade. Mitigations: canary tool deploys, per-client model pinning, workflow tests in CI, clear rollback story.

Over-automation. Removing humans from too many steps removes the implicit knowledge transfer that keeps L2 and L3 engineers sharp. The L1-to-L2 promotion path was always partly about pattern recognition built up over thousands of tickets. Mitigations: rotate humans through agent-handled work for training, design agent output as a learning surface rather than a black box.

Integration brittleness. Auto-generated tool wrappers are not always semantically correct — the wrapper might technically work but get the underlying business logic subtly wrong. Mitigations: human review of high-stakes wrappers, regression test suites at the tool level, a tiered trust model (draft → verified → skills-grade).

None of these is a reason not to build the platform. All are reasons to build it with the operational discipline that distinguishes a working enterprise platform from a clever demo.

A Maturity Model

The pattern fits into a broader six-stage model that locates outsourcers against where the industry is heading.

The ceiling between Stage 2 and Stage 3 is where the platform investment matters. Everything before Stage 3 is point automation — useful, productive, but not compounding. Stage 3 is where every new tool exposed makes every existing agent more capable, and where governance becomes a property of the platform rather than the agent. Stages 4 and 5 are where the commercial model shifts.

Most outsourcers reading this article sit at Stage 1 or 2 for their largest accounts. The honest gap to Stage 3 is two to four quarters of platform work plus the unglamorous data-hygiene investment described in the risks section. The gap from 3 to 5 is the incentive problem above.

Case Study: An 80,000-Endpoint Bank

To anchor the abstractions, a fictional but representative client journey.

A global bank with 80,000 endpoints across thirty countries, currently outsourced to a single Indian IT provider on a five-year contract. The current delivery footprint is roughly 450 named FTEs across all towers (service desk, endpoint, identity, cloud, network, security operations) — an endpoint-to-FTE ratio of around 1:175, which is typical for a well-run but not bleeding-edge tower. Monthly ticket volume sits around 95,000, of which roughly 42,000 are repetitive L1 categories. The customer’s CMDB hygiene is moderate; their ITSM (ServiceNow) is well-maintained but the integration with their endpoint management estate (a mix of SCCM and Intune) is inconsistent.

Phase 1 (months 0–3). Stand up the MCP gateway. Expose three tools: ServiceNow, Active Directory, Intune. Build one agent: L1 password-reset and account-unlock automation. Wire the no-code builder. Measure baseline. Six gateway calls per minute by week ten.

Phase 2 (months 3–9). Expose SCCM, Splunk, vSphere, NetBackup. Build the orchestrator agent and the VDI-triage workflow. Train fifteen SDMs and twenty senior engineers on the builder. By month nine, around 22 percent of L1 volume auto-resolves; the L1 headcount has not changed yet, but the queue depth has dropped by around 30 percent and customer satisfaction has lifted by single-digit points.

Phase 3 (months 9–18). New-joiner onboarding workflow goes live. Emergency patch workflow goes live. Asset and license reconciliation agents go live. The L1 auto-resolution rate stabilises around 32 percent. The bank’s customer asks why the SDM monthly report has improved so visibly. The renewal conversation begins.

Phase 4 (months 18–24). Renewal lands on a hybrid model — partial FTE billing plus a per-ticket envelope. Around four percent of the original FTE base is redeployed to other accounts; another eight percent shifts to higher-value advisory work; the remainder continues in delivery roles. The vendor’s blended margin on the account improves by approximately 2–4 percentage points despite the lower headline contract value. Customer-side, the cost-per-incident reduces by around 18–22 percent.

The interesting metrics in this case are not the headline ticket numbers. They are the renewal terms and the redeployment ratio. The renewal is what tells you whether the platform investment converted into a defensible commercial position. The redeployment ratio is what tells you whether the firm managed the internal political conversation well enough to keep its experienced people inside the business.

The fictional bank is a composite, not a real client, and the numbers should be read as illustrative rather than predictive.

The Rollout Path

A staged path for an outsourcer starting today. The phases are deliberately conservative.

Phase 1 (months 0–3). Pick one client, one process. Stand up a per-client MCP gateway. Expose three to five tools. Build governance from day one: scanning, redaction, audit logging, scoped access, secret rotation. Build one specialist agent. Measure baseline before anything is turned on.

Phase 2 (months 3–6). Build the no-code builder layer. Train ten SDMs and ten senior engineers. Compose the first three workflows — password reset, account unlock, basic VDI triage. Publish the numbers internally.

Phase 3 (months 6–12). Expose the rest of the client’s estate. Build specialist agents per major tool. Compose the next ten workflows. Begin the internal skills-repository pattern, curated rather than free-for-all.

Phase 4 (year 2). Replicate the platform pattern to the next two or three clients. Each new client engagement still requires substantial per-client work — tenant isolation, data sovereignty, CMDB onboarding, integration with each client’s specific tool versions, contract renegotiation, change management with the client’s IT organisation. Implementation time improves from quarters to a few months, not weeks.

Phase 5 (year 3+). Outcome-billed contracts begin to make sense with two or three reference clients in production. The commercial nerve to renegotiate large multi-year contracts on a new basis is as important as the technology by this point.

The substantial work that remains, even after the platform pattern is established, includes identity federation across client tenants, robust RBAC for multi-tenant agent access, rollback safety for agent-executed changes, hallucination containment in production conditions, change-governance integration with each client’s existing CAB, observability across the full stack, and workflow determinism for processes with regulatory SLAs. These are the issues that determine whether the platform delivers in production or merely demos well.

The Third Wave

Indian IT outsourcing has been through three waves. Offshoring in the 1990s and early 2000s — moving work from where it was expensive to where it was cheap. Digital transformation in the 2010s — moving customers from legacy stacks to cloud, mobile and modern collaboration. The third wave is automation-led services — moving the unit of delivery from the FTE to the agent-augmented workflow.

The companies that build a credible MCP-centred fabric first will set the terms for the decade that follows. The ones that wait will negotiate with customers who have done the math and know what the cost-per-ticket should be in a world where an agent handles a meaningful share of the volume.

Uber’s published material is the most usable public case study to date of what such a platform looks like in production at scale. The architecture is reproducible. The protocol is open. The operational discipline required is well within what mature outsourcing organisations already have. The incentive conversation is harder than the engineering, and it is the part that decides who wins.

The technology has been ready for two years. The platform pattern is now visible. The work that remains is execution, and the conversation about who gets paid for it.

Sources & Notes

Uber claims in this article reference the company’s publicly available engineering material on MCP:

• The conference talk: https://youtu.be/yVqMxBahjfA
• Uber’s engineering blog at https://www.uber.com/blog/engineering/ — search for their MCP and AI platform posts.
• The Model Context Protocol specification at https://modelcontextprotocol.io

Vendor capabilities in the competitive-landscape section reflect publicly available product documentation as of 2026 and move quickly; verify with vendors directly before procurement decisions.

Economic envelope figures, the role taxonomy, the workflow examples, the maturity model, the bank case study and the incentive analysis are my extrapolation based on fifteen years in infrastructure delivery. Not benchmarked, not audited, not validated by any of the firms named. Treat as a starting hypothesis for a client-specific business case, not as a benchmark.

Where the article uses “could”, “would” or “should”, that is deliberate hedging. The MCP-centred pattern is a working architecture inside Uber; whether it works equivalently inside a multi-tenant outsourcing environment is a thesis I find credible but cannot yet point to a published reference for.

Feedback, corrections and counter-evidence are welcomed.

About the Author

Ajay Walia

AI {IT Architect} focusing on local-first multi-agent AI engineering, zero-data-egress systems. Ideator, Creator and Executor on Curious Bit.

LinkedIn GitHub 📧 Subscribe