ExplanationUnderstand the concepts

Agent Console architecture

Agent Console is built for multi-tenancy, observability, and governed AI use. This page explains the components and design principles behind the platform as it is built today: the hub-and-spoke orchestration model, the execution gateway, how agents are described and reached, and how tenant isolation and observability work. A short section at the end lists capabilities that are planned but not yet built.

Design principles

Agent Console follows twelve core design principles that guide architectural decisions.

Tenant isolation first

Every request carries tenant context, and data paths enforce tenant boundaries.

Isolation is enforced at:

  • API gateway level (authentication and tenant context).

  • Database (tenant-owned records carry a tenant ID; application queries are scoped to the user’s tenant, taken from their JWT).

  • Tool access (scoped to the agent through its execution gateway virtual key; tenant scoping happens internally, through the JWT the calling agent passes).

  • Storage (a shared GCS bucket across tenants, with cross-tenant and cross-user file access gated at the application level).

  • Logs and telemetry (tagged with tenant ID).

This prevents data leakage between organisations and supports data sovereignty requirements.

Regional services

Data-processing services operate within regions to meet data residency and latency requirements, whilst central platform management services may run globally.

This enables Agent Console to comply with regional data protection regulations whilst maintaining centralised platform operations for efficiency.

Model inference is an exception. For some models, Vertex AI may spread inference across regions for compute availability, and the platform does not control which region serves a given request. This is a common constraint across cloud providers.

Gateway-mediated LLM access

No model call bypasses the execution gateway.

All AI model requests pass through a central gateway that enforces routing policies, tracks usage, and applies governance rules. This architecture ensures complete visibility into AI usage and prevents agents from making unmonitored model calls.

Provider-agnostic

The execution gateway can abstract different AI providers behind a unified interface.

LiteLLM gives Agent Console a single interface that can span providers, so in principle the platform could route a request to the best available provider based on performance, cost, or availability. Today only Google (Gemini) and Anthropic (Claude) models are wired up, both served through Vertex AI.

This remains a designed capability rather than one the platform relies on. Each agent is configured with a specific model, and playbooks (the user-authored instructions that shape an agent) are written against a particular model’s behaviour, which makes switching the model underneath them risky.

Cost attribution by default

Every token is attributed to a tenant, user, and agent.

The execution gateway tracks input tokens, output tokens, model used, execution duration, and associates this usage with:

  • Tenant (for billing and quota management).

  • User (for individual usage tracking).

  • Agent (for capability-level cost analysis).

This granular tracking enables accurate cost allocation and usage-based billing.

Contract-driven agents

Every agent declares its identity, reachability, and capabilities through a contract.

Agents register with the platform using the standard A2A AgentCard, which specifies:

  • Identity (name, description, version, and optional provider).

  • Reachability (the URL and transport the agent is served at).

  • Skills (the discrete units of work the agent performs).

  • Exchange formats (the input and output MIME types the agent accepts and produces).

  • Capabilities (protocol-level features such as streaming).

This contract enables the platform to discover agents and route tasks appropriately without knowing agent implementation details. The tools an agent may call and the permissions it holds are governed separately, through its execution gateway virtual key, and are not declared in the contract. For the full picture, see Understanding agent registration.

Extensibility via Agent-to-Agent communication

Other teams can build and register agents without platform changes.

The hub-and-spoke architecture allows new domain agents to register their capabilities. The root orchestrator routes requests to an agent using its declared contract. This enables new capabilities to be added without modifying core platform code.

Governance by default

The platform governs model and tool access centrally, through the execution gateway.

Governance is applied through:

  • Tool usage (which tools an agent may invoke, governed by its execution gateway virtual key).

  • Model access (which model an agent uses, governed by the gateway).

  • Usage and cost (tracked per tenant, user, and agent at the gateway).

Keeping a user in control of significant actions, such as informing them before writing data, is currently the responsibility of each agent’s developers rather than something the platform enforces centrally.

Observe everything

Every agent invocation, prompt, tool call, and model interaction is traceable, measurable, and auditable.

Observability captures:

  • Agent execution traces (start, steps, completion, duration).

  • Prompts sent to AI models (for audit and optimisation).

  • Tool invocations (which capabilities were used).

  • Costs incurred (tokens, model, execution time).

  • Errors and failures (for debugging and reliability).

This data supports performance monitoring, cost optimisation, and compliance auditing.

Defence in depth

Isolation is enforced at more than one layer.

Security controls span:

  • Network (VPC isolation, private endpoints).

  • Authentication (OAuth2, JWT validation).

  • Authorisation (tenant-scoped permissions).

  • Data (encryption at rest and in transit).

  • Audit (comprehensive logging).

Multiple security layers ensure that a breach at one level does not compromise the entire system.

Fail gracefully

Failures are surfaced, not hidden.

The orchestrator records the status of each run and message. A message that fails is recorded as failed and surfaced to the user, who can try again. Step-level retry and resume across a multi-agent run are planned, not built (see Planned capabilities).

Prefer buy over build

Use managed services unless platform differentiation requires custom solutions.

Agent Console prioritises managed services for:

  • AI model hosting (Vertex AI).

  • Observability (Cloud Trace, Cloud Logging).

  • Distributed tracing and AI observability (Coralogix).

  • Authentication (Keycloak or managed identity providers).

Custom solutions are built only when unique requirements (multi-tenancy patterns, specific governance needs) cannot be met by managed services.

Hub-and-spoke architecture

Agent Console uses a hub-and-spoke model where a root orchestrator connects users to specialised domain agents. Each run is a conversation between one user and one agent; the orchestrator does not chain agents together or combine results from several agents.

Root orchestrator

The root orchestrator is the central hub.

When you submit a request, the orchestrator:

  1. Authenticates and authorises the request, against your identity and tenant.

  2. Routes the request to the agent you selected.

  3. Relays the agent’s streamed response back to you.

  4. Records the conversation.

The orchestrator is the only component that users interact with directly. It provides a unified interface whilst forwarding work to the domain agent that handles it.

Domain agents

Domain agents are specialists that handle specific tasks. Agent Console provides two today:

  • Briefing agent: gathers a brief through a chat conversation and creates it as a project in LUMA.

  • Copywriting agent: generates and refines marketing copy, and can use web search to ground its drafts.

Domain agents operate independently. They receive requests from the orchestrator, execute tasks, and return results. They do not communicate directly with users, and a run involves a single agent, so agents do not communicate with each other.

Extensibility

This architecture enables teams across Storyteq to build and deploy new agents without modifying the core platform.

New agents:

  1. Implement the agent contract (declare identity, skills, and exchange formats).

  2. Deploy to the execution environment so the contract is reachable.

  3. Register with the agent registry.

Once an agent is registered, the orchestrator can route requests to it when a user selects it. No changes to orchestrator code are required.

Execution gateway

All AI model requests pass through an execution gateway that provides routing, tracking, and governance.

LLM gateway (LiteLLM)

Agent Console uses LiteLLM as its execution gateway.

LiteLLM provides:

  • Unified API: a single interface that can front multiple providers; today Gemini and Claude models are configured, both via Vertex AI.

  • Model routing: route requests to different providers based on availability, cost, or performance.

  • Failover: retry failed requests or switch to alternative models.

  • Usage tracking: track every token processed, model used, and execution duration.

  • Cost attribution: attribute usage to tenants, users, and agents.

  • Virtual keys: per-agent keys that govern which models and tools an agent may use.

No model call bypasses this gateway, ensuring complete visibility and control over AI usage and costs.

Provider abstraction

The gateway abstracts provider-specific APIs.

Agents request a model using a standard format, and the gateway translates the request into the provider’s API call, handles authentication, and manages response formatting. In principle this lets the platform add providers or switch models without changing agents, though in practice each agent is pinned to a specific model (see the provider-agnostic principle above).

Cost and usage tracking

The gateway tracks usage metrics for every request.

For every request, the gateway records:

  • Input tokens (prompt size).

  • Output tokens (response size).

  • Model used (specific version and provider).

  • Execution duration (time from request to response).

  • Tenant ID (for cost attribution).

  • User ID (for individual tracking).

  • Agent ID (for capability-level analysis).

  • Timestamp (for reporting and analytics).

This data flows to the observability layer for reporting, billing, and optimisation.

Context and memory

Agents are shaped by playbooks: per-agent, versioned instruction sets that an administrator configures. The orchestrator passes the selected playbook to the agent in the A2A request, and the agent folds those instructions into its own prompt.

The orchestrator persists each run’s conversation history in its database, and an agent works from that history within a run.

Agent Console does not retrieve brand context from a vector store or knowledge base, and it does not maintain long-term memory across runs. Richer context and cross-run memory are planned, not built (see Planned capabilities).

Tools and capabilities

Agents use tools to accomplish tasks beyond text generation.

Tool types

Agent Console uses two kinds of tool.

MCP tools are standalone servers that expose their capabilities over the Model Context Protocol. They suit work that is useful to more than one agent, or that runs as a reusable service, such as brand content intelligence (cmp-mcp) or web search (search-mcp).

Function tools are defined inside an agent and are specific to that agent, such as the copywriting agent’s emit_copy tool.

The rule of thumb is simple: if a capability is useful to more than one agent, build it as an MCP server; if it is specific to a single agent, implement it as a function tool.

Tool access

Agents reach MCP tools through the execution gateway, which proxies tool calls alongside model requests and records usage for observability and audit.

Which tools an agent may use is governed by its execution gateway virtual key rather than declared in the agent contract, consistent with how the platform governs model access.

Observability

Every agent invocation, AI model request, tool usage, and run is tracked and logged.

Observability stack

Agent Console uses Google Cloud observability services:

  • Cloud Trace: distributed tracing for request flows across components.

  • Cloud Logging: structured logs for all platform events.

  • Cloud Monitoring: metrics dashboards and alerting.

These services are augmented with Coralogix for application performance monitoring.

What is observed

Observability captures comprehensive platform activity:

Agent execution traces:

  • Request received (timestamp, tenant, user, agent).

  • Steps executed (sequence, duration, success/failure).

  • Tools invoked (which capabilities, parameters, results).

  • AI model calls (prompts, responses, tokens, costs).

  • Final output (format, size, success/failure).

Usage metrics:

  • Tokens consumed (by tenant, user, agent, model).

  • Execution times (by agent and tool).

  • Success rates (completions vs failures).

  • Cost per execution (actual spend by tenant).

Errors and failures:

  • Exception details (type, message, stack trace).

  • Context (what the agent was doing when failure occurred).

  • Recovery actions (retry attempts, fallback models).

Usage reports

Administrators use observability data to:

  • Monitor workspace usage (consumption by agent, remaining allowance).

  • Track costs (actual spend vs budget).

  • Optimise performance (identify slow or expensive agents).

  • Audit compliance (verify governance policies are enforced).

  • Forecast capacity (predict future usage trends).

Security and tenant isolation

Agent Console enforces isolation at multiple layers to prevent data leakage between tenants.

Authentication and authorisation

Users authenticate via Keycloak (or managed identity provider) and receive JWT tokens.

The Access API intercepts requests and translates the JWT into a Resource Permission Token (RPT) that carries tenant context.

Every request includes tenant context, ensuring users can only access data within their organisation’s boundaries.

Network isolation

Agent Console can deploy with VPC isolation:

  • Private endpoints for internal services.

  • Network policies restricting traffic between components.

  • No direct internet access for execution environments.

This prevents unauthorised external access and contains potential security breaches.

Data isolation

Tenant isolation is logical, enforced at the application layer:

  • Database records owned by a tenant carry a tenant ID, and application queries are scoped to the tenant ID from the user’s JWT, so a user reads only their own tenant’s data.

  • Object storage uses a shared bucket with folder hierarchies (not tenant-based); cross-tenant access is gated at the application level.

  • Logs and telemetry are tagged with tenant ID for access control.

Deployment

Agent Console runs on Google Kubernetes Engine (GKE).

Deployment uses a shared golden-paths Helm chart, applied through ArgoCD, with per-environment values. Each service runs as a container, with a Cloud SQL Proxy sidecar for PostgreSQL access and Workload Identity for GCP access.

Vertex AI is used as the model provider, reached through the LiteLLM gateway rather than called directly. The models in use include Gemini and Claude variants.

Agents can be built with or without Google’s Agent Development Kit (ADK). The briefing agent uses ADK (TypeScript) through an adk-litellm bridge; the orchestrator and copywriter agents use plain Node and the A2A SDK. ADK is one way to build an agent, not a platform requirement.

Planned capabilities

The following are part of the platform’s direction but are not built today:

  • Multi-agent workflows: chaining agents, passing data between them, branching, and step-level retry. Orchestration today is single-agent.

  • Richer context: retrieving brand context, such as Brand & Campaign Intelligence, so agents draw on structured brand data rather than playbook instructions alone.

  • Memory across runs: long-term memory of user preferences and project context beyond a single run’s conversation history.

  • Safety scanning (Model Armor): input and output scanning at the inference layer, such as prompt-injection, sensitive-data, and harmful-content checks.

Related pages