Alquimia
002 · How it works

How Agentic Platform works.

An agent platform is the operational layer underneath AI agents in production. This page is the architectural reference — what the platform does, how it composes, where it runs, and what it makes inspectable.

The first AI agent is not the hard one. The fourth is. The shape of the problem changes the moment an organization runs more than one — and that is what Agentic Platform is built for. The architecture is composable, the deployment is sovereign, and every decision an agent makes is traceable from prompt to outcome.

003 · The architecture

Three layers stacked, with six components inside the agent layer.

The agent layer is what Alquimia owns. The runtime layer is what the platform integrates with. The foundation is your infrastructure. The six components inside the agent layer share state through the runtime layer and persist artifacts through the foundation. They are the platform.

Architecture · three tiers
L01 → L03
L01Agent layer
Alquimia Agentic Platform
  • Studio
  • Runtime
  • Registry
  • Observability
  • Governance
  • SDK + CLI
L02Runtime layer
Integration target

Production-grade inference runtime — GPU scheduling, model serving, explainability.

L03Foundation
Your infrastructure
  • Kubernetes
  • Identity
  • Secrets
  • Event bus
  • Storage
  • Observability
  • Networking
Agent layer · Runtime layer · Foundationalquimia / agentic-platform
003.1 · The six components of the agent layer
  • 01Component

    Studio

    No-code agent design. Prompt configuration, tool selection, lifecycle management. The place where an agent is defined once and the definition is the source of truth.

  • 02Component

    Runtime

    Production execution. Agent-to-agent orchestration. Event-driven inference. Execution lives at the platform layer, available to every agent uniformly.

  • 03Component

    Registry

    OCI-backed publish and pull. Every agent gets a name, a version, and a namespace. Promotion and revocation happen at the platform layer, not by editing code in a repository.

  • 04Component

    Observability

    OpenTelemetry traces. Behavioral metrics. Token analytics. Every inference is inspectable in a single surface across the fleet.

  • 05Component

    Governance

    Role-based access control. Single sign-on. Secrets management. Multi-tenant agent spaces. Enterprise primitives at the platform level, applied uniformly to every agent.

  • 06Component

    SDK + CLI

    For engineering teams that extend the platform, integrate custom tools, or wire agents into existing systems. Extensibility without giving up the platform's properties.

004 · Integration surface

Every integration is a standard interface.

Agentic Platform plugs into infrastructure your organization already operates. The pattern across every surface is the same: a standard interface, not a vendor-specific binding. The day your organization decides to change one layer, the rest of the stack keeps working.

SurfaceWhat it integrates with
  • 01Identity

    Standard SSO protocols (OIDC, SAML) — your identity provider.

  • 02Secrets

    Standard secrets-management APIs — your secret store.

  • 03Container orchestration

    Kubernetes API — any conformant Kubernetes distribution.

  • 04Event bus

    Pub/sub messaging — any compatible broker.

  • 05Storage

    S3-compatible object store — any compliant storage product.

  • 06Observability

    OpenTelemetry — any OTel-compatible observability stack.

  • 07Model providers

    Standard inference APIs + custom adapters — any LLM, open weights you self-host or hosted endpoints.

  • 08Channels

    Connector framework — any messaging, chat, or email channel.

  • 09Inference runtime

    Standard model serving primitives — any production-grade inference runtime.

  • 10Explainability

    Standard explainability surfaces — any open-source explainability framework.

005 · Where it runs

Kubernetes-native. Anywhere your organization runs Kubernetes.

Agentic Platform deploys to your account, your perimeter, your governance. Four deployment topologies are in production use today.

01Topology

On-premises

Your hardware, your datacenter.

Kubernetes on your own hardware in your own datacenter. Maximum sovereignty — data, models, and compute stay within physical infrastructure your organization owns.

02Topology

Private cloud

Your account, your perimeter.

Kubernetes on private cloud infrastructure. Sovereignty preserved at the data level — your account, your perimeter, your governance.

03Topology

Major public cloud

Your cloud account.

Kubernetes on any of the major public cloud providers. The platform deploys to your cloud account. There is no data path through Alquimia infrastructure.

04Topology

Hybrid

Any combination.

Any combination — control plane on-prem, inference in a regional cloud, archive in another region. Composition is part of the design.

005.1 · Agnostic deployment

Four layers. Standard interfaces at every layer.

Every layer in the deployment stack uses standard interfaces, so the choice of model, runtime distribution, or observability stack remains the organization's — not Alquimia's.

Deployment · agnostic stack
L01 → L04
  • L01
    Model layer

    Any LLM — open weights you self-host, hosted endpoints, managed AI services. The platform does not require any specific model or vendor.

  • L02
    Runtime layer

    Any production-grade inference runtime with GPU scheduling and model serving primitives. Open-source explainability frameworks integrate at this layer.

  • L03
    Cloud / infra

    Any conformant Kubernetes — on-prem, private cloud, or major public cloud. Lightweight distributions also supported.

  • L04
    Data sovereignty

    Data, models, and decisions stay inside your perimeter. No data path through Alquimia or any third party unless your organization chooses one.

Model · Runtime · Cloud · Sovereigntyalquimia / agentic-platform
005.2 · Running on your stack today

The agnostic architecture above, mapped to the four stacks our customers run in production today.

  • On-premises

    01
    Runtime layer

    Red Hat OpenShift with OpenShift AI

    AI services available

    Self-hosted open-weight models, plus any LLM provider you integrate

  • AWS

    02
    Runtime layer

    Amazon EKS (or another Kubernetes distribution)

    AI services available

    Amazon Bedrock, plus any LLM provider

  • GCP

    03
    Runtime layer

    Google Kubernetes Engine (or another Kubernetes distribution)

    AI services available

    Vertex AI, plus any LLM provider

  • Azure

    04
    Runtime layer

    Azure Kubernetes Service (or another Kubernetes distribution)

    AI services available

    Azure OpenAI, plus any LLM provider

Hybrid deployments combine any of the above — for example, the control plane on OpenShift on-premises with inference in a regional cloud through that cloud's managed AI service. The architectural commitment is the same in all cases: the platform deploys to your account, your perimeter, your governance.

The combinations above are the most common deployment patterns. The specific architectural decisions our customers have made in production — including the reasoning behind their runtime-layer and explainability choices — are shared in our Insights track and in the use cases.

006 · Governance & observability

Every agent invocation produces an inspectable record.

The platform captures six properties of every call. Capturing them is part of the runtime, available to every agent uniformly, with no per-agent instrumentation effort.

  • 01
    Identity

    Who or what triggered the agent.

  • 02
    Prompt

    The exact prompt the agent received, including any contextual data retrieved at runtime.

  • 03
    Tools

    The tools the agent was allowed to call and the responses they returned.

  • 04
    Model

    The exact model and version that produced the output, with inference parameters.

  • 05
    Decision

    The output the agent produced, classified by type.

  • 06
    Outcome

    The downstream action the decision triggered.

The six properties flow through the observability layer (OpenTelemetry traces, behavioral metrics, token analytics) and through the governance layer(RBAC, audit trails, retention policies aligned with the organization's regulatory posture).

The audit committee's question — who handled this interaction, with what authority, and what did the model produce? — has a single answer from one observability surface.

For reproducible behavioral metrics across agents, models, and versions, the platform integrates with Gaussia — the open evaluation suite crafted by Alquimia.

007 · A walk-through

Two AI agents. One pipeline, traceable end to end.

// Hypothetical illustration

Take a typical production deployment: two AI agents collaborating on a customer support pipeline.

Agent AAgent

Conversational support over a chat channel.

Triggered by a customer message. Retrieves the customer's account context through a platform-registered tool. Responds in natural language. Logs the full conversation as a structured event.

Agent BAgent

Automated ticket triage.

Triggered by every new incident, regardless of channel. Classifies the ticket against the organization's category taxonomy. Prioritizes it based on context — severity, customer tier, recurrence. Routes it to the right technical team. Logs the classification, the model that produced it, and the timestamp.

007.1 · How they compose

Configured in Studio, executed by Runtime, observed in one surface.

Both agents are designed in Studio. Each one is defined by three pieces — the prompt that captures its behavior in plain language, the tools it can call, and the guardrails that constrain it. The configuration is a property of the platform layer, available to both agents through Studio, the same way every other agent in the fleet is configured.

When a customer interaction happens, the runtime executes Agent A on the incoming message. Agent A produces the response and emits a structured event. Agent B subscribes to the same event stream and runs its classification. Both agents' traces — identity, prompt, tools, model, decision, outcome — flow into the observability layer. The audit committee, asked retrospectively who handled this interaction and how?, gets the answer from one place.

This walk-through is the pattern. Concrete deployments — including ones in production today — are documented in our use cases and in the Insights track.

008 · Get in touch

Bring your problem. We'll walk you through it.

We work with organizations building AI agents on their own infrastructure — corporate enterprises, state-owned operators, and regulated mid-market teams. A short call is enough to see if Agentic Platform is the right fit for your case.

Get in touch