The framework was the easy part: shipping AI tooling inside a Fortune 500
Date: 2026-05-19 Post 2 of ~27 (build-in-public, intermittent cadence)
I built an internal 21-agent VS Code framework for my team at Republic Services last year. Adopting it across the engineering org took longer than building it.
A short writeup, because most of the AI engineering conversation in 2026 is about how to build agent systems and not nearly enough about how to deploy them inside a real engineering org. The gap matters: a model is only as useful as the workflow that wraps it, and the workflow is only as useful as the team's willingness to actually run it on Monday morning.
The setup
Republic Services has ~17,000 collection vehicles, 5M+ daily pickups, and an internal engineering org delivering against a >$1B multi-year digital-platform investment. I tech-lead a 5-developer pod inside that work. Mid-2024 I authored a VS Code Custom Agents framework — 21 specialist agents, 34 reusable skills, a single Orchestrator that auto-delegates to sub-agents under 3 automated quality gates — to drive our PRD-driven dev workflow. Zero-dependency markdown, security/audit hooks, handoff-loop guards, the works. It runs locally per developer, slots into our existing PR review process, and respects every IP boundary the company cares about.
That much was straightforward engineering. The hard part was getting other engineers and QAs to actually use it.
Live demos beat documentation by ten to one
I wrote a README. Three engineers read it. I did a 45-minute live demo for one pod, screen-sharing the actual workflow against a real Rally story, and four engineers had it running by end of week. The asymmetry isn't a knock on documentation. Adoption is a confidence problem, not an information problem — people need to see the failure modes, not just the success path.
Embed before you scale
The first three pods to adopt the framework had me in their stand-ups for a week or two, pair-debugging when the agent did something weird, shipping framework fixes within the same sprint. After that, those pods became their own evangelists. Engineer-to-engineer trust does work the platform team can't do directly.
Security and IP guardrails are the precondition, not the differentiator
In a regulated Fortune 500 environment, "the agent will not exfiltrate PII or secrets" isn't a feature you describe — it's the precondition for being allowed to demo at all. We built PII/secret scrubbing into the context pipeline before delegation, locked-paths concurrency to prevent cross-pod stomping, session persistence with audit trails. If any of those had been missing, the framework wouldn't have made it past the first show-and-tell.
The repeatable pattern matters more than the novel one
I spent more time on the Orchestrator-and-sub-agent skeleton than on any individual agent's prompt. A team that adopts an agent framework is implicitly betting on the shape of the framework, not on the cleverness of any particular agent. Make the shape boring and predictable; let the agents specialize.
What I underestimated
Three things, in order of how much they hurt:
— Adoption is a portfolio problem. Of the 21 agents I built, four get used daily, eight weekly, the rest situationally. I initially treated every agent as load-bearing. They aren't. The value is the four daily agents plus the structure that lets the long tail exist for when the team needs them.
— Internal "customers" expect production-grade reliability. Engineers tolerate three weird failures before they stop using a tool. I had to ship handoff-loop guards (warn at depth 5, hard-stop at 8) and crash recovery before the second pod would adopt. The bar for internal tooling at this scale is closer to "production SaaS" than to "internal script."
— The hardest part wasn't the agent design or the security model. It was being the person in the room who could translate between "what the model can do" and "what the engineering org needs to be able to ship next sprint." That translation skill is what makes a 21-agent framework adoptable inside a Fortune 500 instead of staying a clever weekend project.
That last one is also, I think, the thing the AI-native hiring world is figuring out it actually wants when it posts Forward Deployed / Applied AI roles. The model is the easier half of the problem.
Why I'm posting this
There's a lot of "I built an MCP server" content in 2026 — ~23K of them in the public registry as of May. There is almost no "here's what shipping AI tooling at scale into a real engineering org actually looks like." The second is the harder problem. If you're hiring for Forward Deployed / Applied AI roles, the first kind of candidate is everywhere; the second kind isn't.
The second reason is that this portfolio at danielmicaletti.dev is itself the public-facing version of the same work — a live MCP server you can wire into Claude Desktop in 30 seconds. That's the demo. The framework above is the harder version of the same job done inside a 5,000-person company under regulated-industry constraints. Same job, different scale.
Open to Staff/Founding AI Engineer and Forward Deployed / Applied AI Engineer scope at AI-native teams. Remote-first. The live agent at the top of this page does the rest of the talking.