A 3-Part Thought Leadership Series by Nate Lomax
In Part 2 we dug into the adapter-based architecture and tenant orchestrator that lets Symphony integrate safely across diverse enterprise toolchains via MCP-powered, context-aware feedback loops.
Finishing the series, we’ll cover what we learned building Symphony in the wild – and where it’s headed next.
Lessons from Production — and the Future of Symphony
Multi-tenancy is where theory meets reality. Each Symphony tenant has its own:
- Platform configuration
- Agent preferences
- Secure credentials
Every agent container receives only scoped secrets at runtime.
Nothing is shared. Nothing lives in code.
This wasn’t optional. It’s what makes enterprise adoption possible.
Beyond Coding: Lightweight AI Workflows
Not everything needs a full coding agent. We introduced smaller LLM-driven automations using the same trigger system – like the QA Lead Assistant. When a work item lacks acceptance criteria, Symphony:
- Analyzes the ticket
- Generates testable criteria
- Updates the item
- Assigns QA for review
No container. No repo checkout. Just targeted AI assistance. This opened the door to future workflows:
- Bug triage
- Estimation support
- Requirements validation
Coding is only the beginning.
What We Learned
- Abstraction pays off early. The three-adapter architecture (agent, repo, work manager) cost very little to implement upfront and has already paid dividends. Adding Codex support was straightforward because the agent interface was already defined. And when we eventually add Jira support, the adapter interface and orchestration logic won't change at all.
- Ephemeral containers simplify everything. When each agent job gets its own container, a whole class of workspace isolation problems disappears. No shared filesystem state, no cleanup logic, no worrying about leftover artifacts from a previous run. It also simplifies deployments – since every job spins up a fresh container, it always pulls the latest image. There’s no fleet of long-running agent containers to roll out updates to.
- Declarative triggers beat hardcoded logic. Being able to reconfigure what events trigger what actions without changing core system code makes the system dramatically easier to operate and help avoid spaghetti code.
- Credential management in multi-container, multi-platform systems is hard. Each platform has its own auth model, each container needs scoped credentials, and local development needs to mirror production. There’s no magic solution – just careful layering.
- Agents need guardrails, not just prompts. MCP tools, process safety rules, and container isolation aren’t just nice-to-haves. They’re what make the difference between a demo and a production system.
Who Symphony is Actually For
Most of what Symphony does today was built based on what I personally wanted an agent to help me with in my day-to-day work as a developer. Assign a work item, get a PR back. Get review feedback applied without context-switching. That was the starting point.
From there, we spent time learning from other roles within DevIQ – QA leads, project managers, team leads – what would help accelerate their workflows. That’s where the QA Lead Assistant came from. Those conversations are ongoing, and we expect to keep expanding what Symphony can do for both developer and non-developer roles.
But the most surprising discovery has been how valuable Symphony is for business development – even in its current, mostly code-focused state. It can perform detailed analysis of large codebases and surface all of its findings directly in Azure DevOps, where team members can collaborate, comment, and build on the results without ever needing to open an IDE. That wasn’t the original use case, but it’s become one of the most impactful.
What's Next?
The architecture is designed to grow. The three-adapter model means GitHub support is a repo adapter and a work manager adapter – no changes to orchestration or agents.
Jira support is just a work manager adapter. A new AI agent is just an agent adapter. The combinatorial surface expands with each new implementation, and the orchestrator doesn’t need to know the difference.
That’s the long-term vision: a team using GitHub Issues and GitHub Repos gets the same autonomous agent experience as a team on Azure Boards and Azure Repos. A team that wants Claude Code gets the same orchestration as a team that prefers Codex. The platform meets teams where they are.
The goal isn’t to replace developers. It’s to give teams an always-available, tireless teammate that handles the well-defined work so humans can focus on the hard problems. Symphony is the system that makes that possible – regardless of what tools are in the stack. That’s Symphony.
