Enterprise Agent Platform for Safe Internal Software Delivery

Overview

TELUS created Gizmos to shorten the path from an employee’s AI prototype to a shareable internal application. The underlying problem was not primarily generating an agent or web application; it was the operational “last mile” required to give that software an approved identity flow, domain, runtime, security controls, observability, data storage, and a path toward production. TELUS has roughly 100,000 employees across more than 45 countries and operates several distinct businesses, with more than 30 ways for employees to authenticate. A conventional deployment guide required steps such as creating a Google Cloud project, obtaining a Kubernetes namespace, configuring workload identity, writing Terraform, and editing Helm charts. That process was difficult even for experienced developers and often prevented newer AI-assisted builders from shipping at all.

Gizmos was positioned as a general-purpose, safe sandbox and deployment substrate rather than a single-purpose agent product. It accepts applications, MCP servers, automations, web apps, and other AI-generated software, and uses Cloudflare infrastructure for dynamic Workers, Containers, databases, key-value storage, and globally distributed delivery. The platform puts authentication, authorization, sharing policies, application isolation, security checks, and operational tooling in front of user-created software. TELUS reported that approximately 15,000 people had used Gizmos, representing about 15% of the company, and that the service reached nearly half a million views in one month. Elsewhere in the rollout, the team cited approximately 10,000 monthly users. These figures indicate substantial internal adoption, although they are self-reported usage measures rather than an independent evaluation of reliability, safety, or business value.

Problem and product approach

Employees could build a prototype in a few hours with an LLM or an AI development environment, but distributing it to a colleague introduced enterprise requirements that the prototype did not understand. Early users needed to provide sign-in, an approved domain, security review, runtime infrastructure, data-location answers, and monitoring. The original onboarding flow asked users to export a ZIP file from Google AI Studio and upload it to Gizmos. In practice, many users did not know how to create a deployable ZIP, and generated applications often assumed infrastructure that the platform did not provide, such as an Express server.

TELUS responded by publishing an llms.txt file and platform guidance so that coding agents could generate applications compatible with Gizmos. It then built Gizmos Studio, an open-code environment running in a Cloudflare Container, giving each user a place to build directly without manually preparing an archive. The design goal was to meet users in the environment where they already worked and to support multiple agent interfaces rather than force everyone into a terminal or a single framework. Later integrations supported deployment from Claude desktop, Claude Cowork, browser-based workflows, and a Gizmos connector implemented as an MCP service on the same Worker infrastructure.

Architecture and LLMOps workflow

Gizmos functions as an internal platform layer for software produced with LLMs. Cloudflare dynamic Workers provide the principal execution and request-handling substrate, while Containers support heavier or more CPU-intensive workloads. The distinction allows relatively lightweight, I/O-bound applications and more demanding data-processing workloads to use different deployment shapes. The platform can provision Cloudflare databases and KV storage on demand, and its globally available infrastructure is intended to support TELUS’s international organization.

A central request path handles access to deployed Gizmos. The platform checks organizational membership, applies authentication and authorization, and deploys each Gizmo on its own domain to reduce cross-application interference. The team described browser isolation and authentication redirects as part of the design, and considered putting additional network protection such as Tailscale or a VPN in front of the service. Gizmos also supports custom bindings: one Gizmo can expose a service to another through a permissions-aware interface. An example is a user-picker service backed by TELUS’s organizational hierarchy, which other applications can consume without each application implementing the integration independently.

Authentication was redesigned after a Google-only sign-in button excluded users from TELUS business units that used different identity systems. Better Auth was used to provide an email-based entry point that selects an available method, including passkeys, Google authentication, or an emailed sign-in link sent through a Cloudflare Worker email service. This is an important LLMOps lesson: a deployment platform cannot be considered usable if the generated application is accessible only to the team that built it. Identity brokering and enterprise onboarding were treated as platform capabilities rather than application-by-application work.

Governance, security, and reliability

The platform introduced several controls intended to make experimentation safer. Each deployment is scanned for secrets, and the team described using a Gemini model to flag code that appears obviously problematic. Findings can be passed back into the AI-assisted development loop, with Gizmos Studio allowing a user to revise an application and redeploy it. These mechanisms are useful guardrails, but the presentation does not establish that model-based scanning provides comprehensive vulnerability detection, privacy compliance, or a substitute for formal review.

TELUS also used organizational membership checks, role-based access controls, sharing policies, isolated domains, and application-level permissions. It was exploring agent identity and “on behalf of” authorization patterns so an agent could operate with a distinct identity and a traceable delegation from a human user. At the time described, that capability was still being integrated rather than presented as a completed enterprise control. The organization advised employees not to place sensitive information in Gizmos while data-governance and privacy protections were still being strengthened. This qualification is material: the platform was safe enough for selected internal experimentation and ordinary applications such as dashboards or task tools, but the account did not claim that all regulated or sensitive workloads were production-ready.

Operational visibility arrived after an outage exposed the consequences of launching without instrumentation. For roughly the first several weeks, users discovered failures before the platform team did and reported them in Slack. Adding tracing initially broke outbound calls and caused widespread HTTP 500 responses, illustrating that observability changes also require testing and staged rollout. TELUS later added an independently hosted status page running on another Worker and a cron-triggered health check every five minutes, so the status service would remain available when Gizmos itself was unavailable. The team also corrected geographically misleading checks that produced false outage reports.

Cost, capacity, and data operations

Early unrestricted access created a direct LLMOps cost risk. For example, users could repeatedly invoke expensive OCR workflows at scale, so the platform eventually needed metering, limits, billing, dashboards, and organizational chargeback. The team reported that Cloudflare isolates were inexpensive and that AI usage was the principal cost concern, accessed through a TELUS AI proxy. Cost governance was therefore focused less on raw application runtime and more on controlling model and API consumption. The approach was still evolving, with the team intentionally allowing experimentation before progressively introducing stronger limits.

The platform initially stored page views, clicks, deployments, and other analytics events in the same D1 database used by the application. A capacity indicator showed the database’s approach toward D1’s 10 GB limit; at one point analytics represented nearly half of the stored data, although total usage was still below 1% of capacity. Analytics events were moved to Analytics Engine, which reduced pressure on the transactional database. That migration exposed a measurement error: sampling made Analytics Engine suitable for aggregate page-view analysis but unsuitable for accurately counting unique users. User counting was moved back to D1, causing reported user numbers to increase by roughly seven times. This illustrates why telemetry storage and metric definitions should be designed before usage growth: LLMOps observability needs not only data collection, but also semantics that are valid for adoption, cost, and reliability decisions.

Development process and lessons

Much of Gizmos was generated through AI-assisted or “vibe coding,” including approximately 157 commits over two busy days. The approach enabled rapid feature delivery but produced duplicated implementations, layers of wrappers, excessive comments, and nearly 100,000 lines of code that were later removed or consolidated. A dedicated refactoring effort reduced multiple approaches to one and deleted roughly 18,000 lines of comments in a single day. The practical lesson was not to reject AI-generated code, but to schedule architectural review, cleanup, testing, and simplification before accumulated code becomes an operational liability.

The team also learned that supporting a broad range of runtimes and frameworks can become a distraction. Repeated rewrites across frontend, backend, MCP, and runtime technologies consumed effort without necessarily improving the product. Conversely, assuming that all builders use the same development environment created unnecessary friction: experienced developers preferred Claude Code, while many new builders worked in Claude desktop, Cowork, or a browser and had never used a terminal. Gizmos therefore expanded its interfaces instead of insisting on one workflow.

The marketplace presented another operational challenge. AI can produce large volumes of agents, dashboards, and small applications, but most catalog entries may receive little or no use. Gizmos addressed discoverability with featured applications, team views, stars, and usage metrics. This is a product-governance response to AI-generated software abundance rather than a claim that the underlying curation problem has been solved.

Results and tradeoffs

TELUS’s reported adoption suggests that reducing deployment friction can unlock software creation beyond conventional engineering teams. Store managers reportedly built internal social applications and automations, while sales teams created multi-agent marketing workflows. Users also built platforms on top of Gizmos, indicating that the substrate supported composable internal services rather than only isolated prototypes. The reported figures—15,000 total users, approximately 15% of the organization, nearly half a million monthly views, and about 10,000 monthly users at another measurement point—show reach, but do not by themselves demonstrate quality, security, model accuracy, cost efficiency, or durable productivity gains.

The central tradeoff is between rapid, low-friction experimentation and enterprise control. Gizmos provides a meaningful set of platform controls, including identity integration, RBAC, isolation, secret scanning, observability, status reporting, metering plans, and delegated-service concepts. However, the account also makes clear that sensitive-data governance, agent identity, cost enforcement, and stronger sandboxing were works in progress. The case therefore represents an emerging LLMOps pattern: put a managed platform around employee-generated AI software, learn from real usage, and progressively add controls as adoption exposes failure modes. It should be assessed as a rapidly iterated internal developer platform and experimentation environment, not as evidence that AI-generated applications are automatically secure or production-grade.