An Agent Architecture Case Study

I built the agent architecture enterprises are about to need.

My twenty years are in Microsoft infrastructure. Tenants, identity, endpoints, Exchange, the plumbing. In February my position at National Business Technologies was eliminated in a reduction in force, and I had ninety days to replace a principal-level role. I treated it as a forcing function. Rather than running a job search on spreadsheets and manual follow-ups, I rebuilt the whole thing as an agent system and became my own Customer Zero.

Today it runs my pipeline end to end. 145 opportunities tracked, six active interview threads, continuous operation since February 6. Scheduled jobs run unattended on cron, regenerating the dashboard, classifying new email, and scraping job boards without a session open. Inside the session, it scans my inbox via Graph, drafts recruiter replies in my voice, tailors resumes, generates interview prep documents grounded in confirmed experience, and refuses to fabricate anything the source material does not support. It is the same pattern enterprises now need for tenant assessment, license optimization, oversharing review, and agent governance.

The reason this is worth a long read is specific. Most Microsoft infrastructure engineers have not yet shipped a production agent. I have. This document is how it is built, why the choices are the ones that transfer to a customer engagement, and where the pattern is directly portable to the work a Microsoft cloud practice is already being asked to do.

The system is live, not a demo.

These numbers come from the running system. Every row is an opportunity I acted on. Every folder holds drafted correspondence, screening notes, and prep artifacts the agent produced or helped produce.

Every metric above is queryable from the running system. The tracker is an .xlsx with a regenerated HTML view. The skills live in a plain directory the agent reads at session start. The run counts come from the action log.

What it actually does, in operator terms.

How the pieces fit.

The architecture has four tiers. A natural-language entry point, a skill router, a tool layer that mixes Model Context Protocol connectors with Python services, and a state layer on disk. Probabilistic work stays in the model. Deterministic work stays in Python. The two halves never pretend to be each other.

All sixteen skills, drawn three ways.

The four-tier block above is the bones. The three visuals below are the muscle. Constellation shows what each skill does and which ones share a tool. Swim lane shows how they execute in order during a normal morning run. Layered stack shows every moving part named in one place.

What the operator actually sees.

The maps above describe the shape of the system. The Command Center is where the operator lives. One URL opened at the start of the day, three stacked views, every piece of state the pipeline produced since the last run. The views below are rendered against sample data because the live pipeline holds confidential recruiter correspondence and active interview threads. The layout, the field structure, and the rendering pattern are exactly what ships. Company names are placeholders from the Microsoft documentation tradition: Fabrikam, Contoso, Northwind, Adventure Works, and friends.

This view is where the architecture pays off. The operator does not open Job_Tracker.xlsx, action_log.json, or the skill directory during a normal morning run. One URL holds the whole pipeline. Replace the operator with a customer tenant administrator and the rendering pattern still holds. Different data, same state spine, same deterministic rebuild every time the pipeline changes.

The choices I would bring to a customer conversation.

Why this pattern matches the work enterprises are being asked to do.

The architecture above is pattern transfer from a pipeline I built and run. I have not yet applied the same pattern at customer scale on a Copilot Studio or Agent 365 engagement. That is the honest distinction, and it is why Customer Zero is the right framing. My twenty years are in the Microsoft infrastructure these agents plug into: tenants, identity, Exchange, SharePoint, endpoints, the M365 control plane. I know how those components wire together. What they need is the right tenant to live in. Given the platform depth and the architectural fluency, the ramp into a customer conversation is short.