I mapped each of the nine Unify-placed AWS APN consultants end to end — scope, SOPs, pain points, system access, stakeholder relationships, the work they actually execute day to day. This was not a survey or a workshop. I leveraged each consultant's standard operating procedures and decomposed them into the cadence, inputs, outputs, and decision points that an agent would have to replicate. That source material is the foundation for every agent design that follows; Phase 1 of the production engagement extends it through the knowledge transfer interview program, the deeper per-consultant capture, and the named-stakeholder commitments referenced below.

against a weighted formula of impact, feasibility, and cross-consultant reach. The priority set of four agents that Phase 2 builds against was derived from that ranking, not selected by intuition.

covering every platform the consultants touch — Smartsheet, QuickSight, Highspot, Salesforce, Asana, SharePoint, Slack, Email, Contract Central, Marketo, and others — with per-consultant access/block status. The access constraints surfaced from this exercise drive the deployment phasing and have produced four active provisioning workstreams.

Built and demonstrated to the client: working implementations of the Intake Normalizer (classification, routing, auto-acknowledgment) and the Communications Drafter (audience-tailored drafts with anti-hallucination constraints) — the two agents that ranked highest on impact and reach in the discovery work, deliberately chosen to validate feasibility of the most consequential patterns rather than the easiest ones. Both integrated with Slack. The Intake Normalizer was demonstrated autonomously: a partner email forwarded into a Slack inbox is classified, routed to the correct owner, logged, and — for urgent items — auto-drafted as a response, with no human button-press in the loop.

A per-consultant view detailing each individual's scope, SOPs, pain points, tools available and missing, stakeholders, and mapped agents. A weighted ranking of all sixteen candidate agents with the impact/feasibility/reach scoring formula made explicit. An organization-and-stakeholder coverage view with per-program consultant and agent counts. Agent-to-system access mapping with the read/write/proxy patterns per agent, plus supporting views of agent-by-organization coverage and consultant-by-agent benefit. A system taxonomy of every platform the consultants touch, classified by category, vendor, and type (SaaS / internal AWS / core), with per-consultant access and block status. A live agent operations dashboard with confidence scoring, token accounting, processing time, source and urgency breakdowns, auto-route rates, and a per-action audit feed.

Runtime isolation, data exposure through tool calls, prompt injection, evaluation drift, vector-store confidentiality, and cross-agent blast radius — each mapped to specific AWS services and design patterns within the production plan.

The design specifies a charter, six defined roles (CoE Chair, Agent Owner with interim consultant and named AWS FTE successor, Model Risk Reviewer, Data Steward, Connector Owner, Incident Responder), a six-stage agent lifecycle (registration → approval → deployment → monitoring → recertification → retirement), and a defined governance cadence (weekly per-agent review, bi-weekly CoE operations, monthly cross-agent observability, quarterly leadership governance, on-change reviewer sign-off). Each lifecycle stage is tied to a specific artifact and a named owner. The CoE is the operating-model layer the technical architecture sits inside — the part most agentic deployments underinvest in, and the part that determines whether the agents are still operating six months after they go live.

The Agent Registry, the connector posture layer, the human-in-loop gating for high-risk actions, the prompt versioning workflow, the evaluation harness — none of these are off-the-shelf AWS products. They are the real consulting build.