Taking AI agents from visual design to production in one step
An agent framework and publishing service that turns a visually designed agent into a running, separately deployed service for each environment.
- Partner
- A global consulting firm
- Period
- October 2024 to January 2026
- Agent types
- 5
- Conversational, content generation, data analysis, generic and CrewAI
- Sub-component types
- 8
- Memory, RAG, guardrails, tools, web search and chains
- To publish
- 1 step
- Design to a live endpoint per 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, and a publishing service that provisions each agent as its own container through infrastructure as code. Publishing tracks the deployment and records the live endpoint for the chosen environment.
What was delivered
- Five agent types and eight reusable sub-components, assembled into workflows without new code
- Workflows tested inside the platform before release, then published per environment
- Each published agent runs as its own service with memory, knowledge search and tools
Partner background
Our partner is a global consulting 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.
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, document search, guardrails, web search and tools. Each combination had been built separately, with no shared structure to reuse.
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 a workflow inside the platform before releasing it
- Publish an agent to a chosen environment with one action
- 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 workflow orchestrator, the publishing service and its integration with an infrastructure as code deployment service. The framework was built between February and September 2025, and one-step publishing between June and September 2025.
Approach
Components with one contract
Every agent and sub-component implements the same interface: initialize, execute and clean up. A factory creates the right component from its configuration, so adding a new agent type does not change the orchestrator.
A graph, not a script
Workflows are compiled into a LangGraph graph. Components return commands that tell the graph where to go next, which allows both fixed sequences and routing decided by a model.
Publishing as infrastructure
Rather than running published agents inside the platform, each one is provisioned as its own container through a Pulumi based deployment service. This keeps resource limits, scaling and failures separate for each agent and environment.
Implementation
Agent framework
Five agent types share a common base: conversational, content generation, data analysis, generic and CrewAI. Eight sub-component types (chains, LangSmith chains, guardrails, knowledge base, memory, RAG, tools and web search) attach to an agent, each with its own state.
Publishing service
A publish request records the environment, service tier, autoscaling choice and allowed origins. The service requests a container from the deployment service, then checks its status every five seconds for up to twenty minutes. The result, Published or Failed, and the live URL are stored on the workflow version for that environment.
Running agents
Published agents run on the Agno framework with PostgreSQL for memory and sessions, Redis for streaming output, Weaviate for knowledge search, and search and scraping tools. Agents can be unpublished as cleanly as they are published.
Tools and technologies
| Tool | Purpose |
|---|---|
| LangGraph | Workflow graph and routing |
| Agno | Runtime for published agents and teams |
| Pulumi | Infrastructure as code for agent containers |
| Azure | Hosting for agent services |
| PostgreSQL and Redis | Agent memory, sessions and output streaming |
| Weaviate | Vector search for knowledge sources |
| FastAPI | Platform API |
What was delivered
- Agent types
- 5
- Sub-component types
- 8
- Publish states tracked
- 4
- Separate live endpoint
- Per env
- A component framework documented with its own architecture and contribution guides
- One-step publishing from a tested workflow to a running agent service
- Publishing status, timing 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.