A shared platform for enterprise AI agents

The goal was not to put one chatbot into production. It was to make many different agents deployable against existing enterprise systems without creating a new security, integration, and operations model every time. Different model providers, enterprise APIs, credentials, retrieval sources, streaming interactions, failures, audit requirements, and observability all had to behave like platform capabilities rather than project-specific code.

Agents needed to work with existing enterprise systems: modern APIs, older integration contracts, transactional data, document knowledge, and services that were never designed with an AI caller in mind.

The platform also had to serve multiple organizations and workloads without allowing one agent's tools, credentials, data, or execution context to leak into another. Those guarantees needed to come from the platform architecture, not from every development team remembering the same rules.

A provider-agnostic agent runtime sits behind governed gateway layers for model and tool access. Authentication, provider routing, consumer boundaries, rate limits, request policy, and audit are platform responsibilities rather than code each agent reimplements.

Enterprise APIs become agent capabilities through machine-readable contracts. A catalog and policy layer determines which tools exist and which ones an agent may invoke, while credentials remain in managed secret stores and are resolved only when the capability executes.

Retrieval and knowledge access are treated as platform services rather than prompt-specific plumbing. Observability follows execution across the agent, model, retrieval, and tool boundaries so an operator can understand a run end to end. The workloads run on container orchestration with infrastructure managed as code.

I lead the architecture and technical direction of the initiative. I define the platform boundaries, agent runtime and gateway strategy, tool model, tenant and credential isolation, retrieval integration, observability approach, and the standards an agent must meet before it becomes a production workload. I also guide the teams building on top of that foundation.

1. Separate agent behavior from model-provider infrastructure

   Why

   Agents should express what they need from a model, not embed the assumptions of one provider throughout the application. Keeping that boundary explicit allows model choice and routing to evolve without rewriting every agent.

   Trade-off

   The abstraction itself becomes a platform responsibility, and provider-specific features have to be adopted intentionally instead of appearing automatically.

2. Generate agent tools from API contracts

   Why

   Enterprise systems may expose hundreds of operations. Hand-writing and maintaining a tool for each one does not scale, and manual descriptions eventually drift from the API. Making the contract the source of truth turns tool exposure into a governed integration process.

   Trade-off

   Contract quality becomes critical. Older systems often need their interfaces described or normalized before they can become good agent tools.

3. Make identity, credentials, and tenant isolation platform responsibilities

   Why

   An agent should receive permission to perform an action, not the underlying credential required to perform it. Centralizing identity and credential resolution reduces the blast radius of both implementation errors and autonomous behavior.

   Trade-off

   The platform owns more security complexity and becomes responsible for maintaining correct policy across every execution path.

4. Instrument the complete agent path

   Why

   Agent execution crosses multiple non-deterministic steps. A conventional application log cannot explain why a run chose a tool, where latency accumulated, or which dependency caused a failure. End-to-end telemetry makes those questions operationally answerable.

   Trade-off

   Detailed telemetry introduces storage, cost, privacy, and retention decisions of its own.

The platform turns agent delivery from a series of one-off experiments into a reusable engineering capability. Teams can concentrate on domain behavior while the shared layer provides governed model access, enterprise tools, retrieval, identity boundaries, telemetry, and deployment patterns. The more important result is architectural: introducing another agent no longer means inventing its production model from scratch.

This public description intentionally omits the systems involved, model-provider configuration, tenant details, tool catalog, infrastructure topology, and operational configuration.

• Kubernetes
• Apache APISIX
• Terraform
• OpenTelemetry
• Oracle Database
• PostgreSQL
• Redis
• Node.js