Taking AI agents from visual design to production in one action
An agent framework and publishing service that tests a visually designed agent on the same runtime it is published on, then deploys it as its own service for each environment.
- Partner
- A multinational advisory firm
- Period
- October 2024 to January 2026
- Publish states
- 5
- Not published, Pending, Published, Failed and Unpublish pending
- Runtime
- 1
- The same engine for testing and production
- Live endpoint
- Per env
- A separate service for each environment
The challenge
Teams could prototype AI agents, but each one that needed to go live became a separate engineering project: new code, new infrastructure and a new deployment process.
What we built
A component framework for composing agents visually on Agno, the same runtime that runs them in production, and a publishing service that deploys each agent as its own container on Azure Container Apps through infrastructure as code. Publishing tracks the deployment and records the live endpoint for the chosen environment.
What was delivered
- Agents, agent teams and workflows assembled from reusable components without new code
- Agents tested in the platform on the runtime they are published on
- Each published agent runs as its own service, with approval for production
Partner background
Our partner is a multinational advisory firm whose teams work with large volumes of documents, spreadsheets, databases and email. It wanted one internal platform where those teams could build data pipelines and AI agents themselves, instead of commissioning a new application for each need. The platform had to run inside the partner's Microsoft 365 and Azure environment, keep each team's work separate, and move work from experiment to production through controlled environments. This case study covers one part of that platform; nine case studies describe the whole.
The challenge
Every agent was a project
Moving a prototype agent to production meant writing an application, provisioning infrastructure and wiring memory, storage and credentials by hand. The cost of that work decided which ideas were tried.
Agents need more than a model
Useful agents combine memory, knowledge search, guardrails, web search, tools and observability. Each combination had been built separately, with no shared structure to reuse.
Tested is not always shipped
When an agent is tested on one engine and deployed on another, its behaviour can change between the test and production.
Production needs boundaries
A published agent had to run apart from the platform itself, with its own resources, allowed origins and environment, so one team's agent could not affect another's.
Objectives
- Let teams compose agents from reusable parts instead of writing new code
- Test an agent on the same runtime it will run on in production
- Publish an agent to a chosen environment with one action, with approval for production
- Run each published agent as an isolated, separately managed service
- Record publishing status and the live endpoint against the workflow
Our role
CharCentric provided technical leadership and architecture within a multidisciplinary engineering team, and contributed directly to implementation. The platform was built over 16 months, from October 2024 to January 2026, as a Python and FastAPI backend on Azure.
Scope and timeline
The work covered the agent component framework, the publishing service and its integration with an infrastructure-as-code deployment service. The framework was built between February and September 2025, and one-action publishing between June and September 2025.
Approach
Components with one contract
Every agent, agent team and component implements the same interface and is created by a factory from its configuration, so adding a new component type does not change the rest of the platform.
One runtime, from test to production
Agents run on the same Agno version both when they are tested in the platform and when they are published. A published agent loads the same stored workflow version that was tested, so what was tested is what runs.
Publishing as infrastructure
Each published agent is provisioned as its own container on Azure Container Apps through a Pulumi-based deployment service. Resource limits, scaling and failures stay separate for each agent and environment, and agents published with autoscaling scale to zero when idle.
Implementation
Agent framework
Agents, agent teams and workflows share a common base. Twelve component types attach to them, including memory, storage, knowledge, web search, web crawling, MCP tools, guardrails, observability and user feedback, each with its own configuration. Architecture and contribution guides explain how to add a component type.
Publishing service
A publish request records the environment, service tier, autoscaling choice and allowed origins. Production requests wait for approval from a workspace owner. The service then requests a container from the deployment service and checks its status every five seconds for up to ten minutes. The version moves through five states, from Not published to Published or Failed, and the live URL is stored for that environment.
Running agents
Published agents use PostgreSQL for memory and sessions, Redis for streaming output and Weaviate for knowledge search. Unpublishing has its own tracked state, so an agent being removed is never mistaken for a live one.
Tools and technologies
| Tool | Purpose |
|---|---|
| Agno | Agent runtime for testing and production |
| Pulumi | Infrastructure as code for agent containers |
| Azure Container Apps | Hosting for published agents |
| PostgreSQL and Redis | Agent memory, sessions and output streaming |
| Weaviate | Vector search for knowledge sources |
| FastAPI | Platform API |
What was delivered
- Publish states
- 5
- Component types
- 12
- Runtime for test and production
- 1
- Separate live endpoint
- Per env
- A component framework documented with its own architecture and contribution guides
- One-action publishing from a tested workflow to a running agent service
- Publishing status, approval and endpoint recorded for each environment
- Published agents isolated from the platform and from each other
Why it matters
Most organizations can build an agent demo. The harder part is making the second, fifth and twentieth agent cheap to release and safe to run. A shared component model and a repeatable publishing path address that directly.
If your organization is planning a platform of this kind, or needs a specific part of one designed and delivered, we would be glad to discuss it.