I build make systems. Music. infrastructure.

These are the questions a Fortune-500 buyer or a top-tier startup board would ask before signing a senior architect at the rate they'd actually pay one. The answers below are mine, in plain language, with the architecture cards I'd sketch on the whiteboard while I talked. Sourced from the same blog I write at agenticwork.io/blog and the platforms behind it.

1. 01 opening · scope

   Walk me through the most complex agent system you've architected end-to-end.

   AgenticWork — the orchestration platform behind agenticwork.io. Three integrated runtimes (Chat, Code, Flows) sharing one credential model, one audit pipeline, and one model-routing layer. Roughly 14k lines of TypeScript in the orchestrator, another 8k in the helm chart and bundled MCP tooling.

   The hard problems weren't the agent loops. They were the seams: per-tool credential scoping so an LLM never sees a token, a 10-stage Chat pipeline where DLP runs at four points and prompt-injection validation is a discrete stage, a SmartModelRouter that ingests user feedback every 30 minutes and re-scores providers, and a SHA-256 chain-hashed audit log that's tamper-evident by math, not policy.

   I architected it for compliance officers, not engineers. Day one a HIPAA-covered hospital can deploy it inside their VPC, point it at their Azure AD, and have agents whose every action is exportable to their SIEM with the approver's name attached.

2. 02 multi-cloud · provider strategy

   A regulated workload needs an inference layer. How do you pick between AWS Bedrock, Azure OpenAI, and Vertex AI?

   I don't pick. I route. The question of "which provider" is a runtime decision per request, not an architectural commitment per workload.

   The deciding factors are residency (where the customer's data must stay), capability (which model handles this prompt class best in eval), economics (cost per output token at the routing target), and posture (which provider has the BAA signed, which has the air-gap option, which is on the customer's procurement-approved list). In AgenticWork, all four are inputs to the SmartModelRouter — every 30 minutes the scores are re-derived from real usage feedback, not static benchmarks.

   Defaults I usually start at: Bedrock for the majority of US healthcare and financial-services work because the BAA + IAM model is path-of-least-resistance; Azure OpenAI when the customer's IdP is already Entra and their data lives in Azure regions; Vertex when the workload needs Gemini's long context window or Document AI. Bedrock and Azure for the same workload if the customer wants provider failover written into the SLA — both behind the router, neither load-bearing.

3. 03 tool layer · MCP vs synthesis

   Walk me through how you decide between a registered MCP server, an in-house tool, and on-demand synthesis.

   Three buckets, one decision tree.

   MCP server if the surface is long-lived, heavily-used, narrow, and the credential's already scoped. A specific Kubernetes operator, a single Jira CRUD path. The economics work, the patching tax is bounded, the credential blast-radius is known. Use MCP. The Linux Foundation just adopted it; the protocol is bet-on-able.

   In-house tool if the surface is in our own product, the contract with the agent is part of our schema, and we want full type-safety. Same lifecycle as the rest of the codebase.

   Synth for the long tail — capabilities the agent needs once a month, where standing up an MCP server and minting a long-lived credential is more risk than the capability is worth. Synth generates a one-shot Python tool, plumbs in scoped credentials at execution time, runs in a sandbox, gates behind a human reviewer, and tears down. No catalog to enumerate, no token to leak.

   The numbers that drive this: VentureBeat tracked 92% exploit probability across 10 deployed MCP plugins; prompt injection is the #1 attack vector against agents in 2026. Standing tool registries are catalogs for the attacker. Synth removes the catalog.

4. 04 security · prompt injection & exfil

   How do you prevent prompt injection and data exfiltration in a production agent stack?

   Defense in depth at four explicit checkpoints, plus an architectural commitment that the model never holds the credential.

   The four DLP scan points in the AgenticWork Chat pipeline: (1) user input on receive, (2) tool input before execution, (3) tool result after execution, (4) LLM output before responding. 50+ rules across credentials (AWS/GitHub/Slack tokens, private keys), PII (SSN, credit cards with Luhn check, IBAN), infrastructure (ARNs, IPs, K8s secrets), HIPAA identifiers, and injection patterns (SQL, command, path traversal). Severity drives action — low logs, medium redacts, high blocks.

   Architecturally: the LLM is in a separate process from the credential. CredentialScopeService mounts only the scopes a specific tool requires at the moment of execution. If a tool's prompt-injection hijacks the call, the call still can't escalate to scopes the tool wasn't granted — the credential was never in the address space.

   And then sandboxing: every tool execution is isolated, no persistent disk, no cross-run memory, network egress allowlisted at the policy layer. The blast radius of a successful injection is one execution.

5. 05 compliance · HIPAA / FedRAMP / EU AI Act

   A hospital and a federal agency want the same agent product. How does compliance shape the architecture?

   It's the same architecture, configured differently. Compliance isn't a tier; it's a deployment profile.

   The hospital needs a signed BAA, encryption at rest and in transit, the right to audit, and HIPAA's minimum-necessary rule encoded into role-based scopes. We deploy AgenticWork inside their VPC behind their Entra (or Okta), point inference at Bedrock or Azure OpenAI under their BAA, and turn on the cryptographic audit chain. PHI never leaves their tenant. Auditors get a SIEM-exportable trail with the approver attribution every HIPAA reviewer wants to see.

   The federal agency wants something stricter: FedRAMP-aligned controls, often air-gapped, often with sovereign-cloud constraints (GovCloud, Azure Gov, Google Public Sector). The same orchestrator runs. The model layer flips to providers with the right boundary attestation. OpenAgentics, our MIT fork at openagentics.io, is the path when the federal customer needs the option to run the platform with no vendor in the loop.

   And the EU AI Act timer is real — high-risk system enforcement starts August 2, 2026, penalties up to €35M or 7% of global revenue. The AgenticWork audit log was designed for that environment: tamper-evident by SHA-256 chain, exportable in a form a conformity assessment can consume.

6. 06 eval · reliability · production readiness

   How do you know an agent is actually good enough to ship?

   Three layers of evaluation, and a shadow-mode period before any agent gets write-access in production.

   Layer one — offline: task-specific evals against a frozen test suite. For a triage agent, ~500 historical incidents with the human's classification as ground truth. Pass rate, calibration, false-positive cost, false-negative cost. We track per-model so we can decide cost/quality on the router. Most agents stay in demo because there is no offline eval — that's the gap most teams skip.

   Layer two — shadow: the agent runs on real traffic but its outputs go to a review buffer, not to action. Two weeks. The on-call team grades the drafts. We measure agreement rate, time-to-grade, false-confidence. If agreement is below a threshold, the agent doesn't promote.

   Layer three — live with HITL: the agent acts, but every write goes through a human gate. We measure approval rate, edit distance on approved actions, time-to-approval. As approval rates climb past ~90% on a class of action, we promote that class to autonomous-with-rollback. Reads were always autonomous. Writes earn it.

   None of this is about the model being smart. It's about whether the system is honest about how often it's wrong.

7. 07 cloud architecture · multi-region · resilience

   Multi-region. Active-active. Five-nines on inference. How?

   Two regions per cloud, two clouds per workload, one active control plane that owns routing decisions.

   The routing layer (SmartModelRouter) is stateless; it's deployed in every region behind a global anycast LB. Region-local cache for model scores. The audit chain is region-pinned but replicated to a second region with eventual reconciliation — the chain hashes mean we can detect divergence cryptographically.

   For inference itself, every workload has at least one primary and one cross-cloud failover wired into the router. If Bedrock us-east-1 throws a 5xx, the router's circuit breaker opens after 5 failures and the request is re-tried on Azure OpenAI East US in under 200ms. The user doesn't see it. The audit log records both attempts.

   Five-nines isn't an inference promise — no model provider gives you five-nines on a single-region SLA. It's a routing promise. We hit it because the failover is the design, not the contingency. The shape of the architecture is: one global IP → URL map by tenant → regional NEG → containerized routing layer → multi-cloud inference, audited end-to-end.

   This is the same shape that runs the Gnomus family on a tighter budget — one Global External LB, Cloud Armor, Certificate Manager, eleven hostnames, ten-minute provisioning per new site. Different scale, same pattern.

8. 08 human-in-the-loop · throughput

   HITL slows everything down. How do you keep it from killing throughput?

   Gate the writes, never the reads. Surface decisions in the expert's existing workflow, not as a separate inbox. Promote classes of action to autonomous as approval rates earn it.

   Reads are free. The agent investigates logs, queries metrics, runs git blame, reads runbooks — none of that gates. Most of the agent's work is reads.

   Writes get a gate, but the gate sits where the expert already lives. Inside ServiceNow for incident response. Inside the EHR for the clinician. Inside the claim file for the adjuster. The reviewer sees a rendered view, not a JSON blob — what the agent will do, what changes after, why it thinks it should. Approve or amend, not a chat thread.

   The trick is action classes graduate. "Restart this pod" earns autonomous status after 200 approvals at 95%+. "Drop a customer record" never does. The system keeps the receipts.

   Numbers from a real customer running this pattern in AIOps: MTTR went from 22 minutes to 4, oncall pages dropped 60%, the human is still in the loop where the loop matters.

9. 09 audit · compliance-grade trails

   What does a compliance-grade audit trail look like for an autonomous agent?

   Tamper-evident by mathematics, not by policy. Every entry chain-hashes the previous one. Per-action receipt. Exportable to SIEM in a structure a regulator can consume.

   The schema: actor (which agent, on behalf of which user, in which workspace), intent (the prompt + the plan), scopes (credentials plumbed in, at what level, for how long), tool (synthesized or registered, code hash, version), result (changed-state delta, where output went), approver (if HITL, identity + timestamp + the rendered view they saw), hash (SHA-256 over previous entry's hash + this entry).

   Why chain-hash? Because policy-based "trust the log" doesn't survive an insider threat or a failed-trust scenario. If you change one entry, the chain breaks at that entry and every subsequent one. You can prove the chain hasn't been tampered with by re-deriving the hash sequence.

   Exports: SIEM-ready JSON to Splunk/Datadog/Sentinel, FedRAMP-aligned per-event format, EU AI Act conformity-assessment shape. Same source, different views. Architecture deep-dive if you want the receipts.

10. 10 team · org design · build vs buy

    How do you structure the team to ship this work? Build, buy, or open-source?

    Three pods, six to nine people. Buy where the surface is commoditized, build where the security model lives, open-source the parts that need to outlive any one vendor — including yours.

    Pod 1 — Platform (3–4): orchestrator, routing, audit, policy. Senior engineers, cross-cloud literacy, security-forward mindset. This is the load-bearing pod. The credential model and audit chain live here.

    Pod 2 — Surfaces (2–3): Chat, Code, Flows or whatever the customer-facing modes are. Designers + engineers. This is where most of the perceived product lives.

    Pod 3 — Trust (1–2): security, eval harnesses, compliance documentation, customer audits. Reports up to the same lead as Platform — no separate fiefdom.

    Buy: model providers (don't train your own foundation model), observability, IdP. Build: orchestration, routing, audit, the security model that wraps everything. Open-source: the orchestrator core. Why? Because 94% of IT leaders fear AI vendor lock-in; the only durable answer is "the leverage is the agent, not the lock-in." We MIT'd the AgenticWork core as OpenAgentics for exactly this reason.

    Hire shape: 2 staff+ engineers, 3–4 senior engineers, 1 design engineer, 1 trust/compliance engineer, 1 PM-of-record. ~$3M/yr fully loaded. This shipped real revenue inside one calendar quarter.

11. 11 demo-to-production gap

    Most enterprise AI projects die between demo and production. Where exactly do they die, and what do you do about it?

    They die in the integration pass. The demo works because it's a closed system. Production is open — identity, data, audit, change management, on-call, the procurement review. Nobody planned for any of those, so the project rebuilds them at production-time, badly, and ships nothing for a quarter.

    The numbers are stark and worth memorizing in this seat. RAND's research tracked AI project failure rates above 80% in some cohorts. S&P Global said 42% of companies abandoned most AI initiatives in 2025. 95% of pilots fail to scale.

    The fix is to make the integration pass the first pass. The demo runs against real identity (their IdP), real data (a sandboxed copy of their actual records), real audit (writes to the chain), real on-call (the alert goes to a real Slack channel). Anything fake is a liability you'll pay for at production-time. We sell a 14-day shadow pilot at AgenticWork because shadow-on-real beats demo-on-fake every single time.

    The other half of the answer: own the seams. The seam between IdP and the agent. The seam between the audit log and SIEM. The seam between the agent and the on-call rotation. Those are the things that surprise teams in production. They're where I spend most of an architecture review.

12. 12 closing · the no

    When do you tell a customer "no, we shouldn't build this"?

    When the agent's wrongness costs more than the agent's rightness saves. When the work isn't reversible inside a meaningful window. When the task is one a junior human would refuse to do unsupervised — that's the "should" question, and the answer is the same for an agent.

    Also: when the customer wants the demo as the product. If the project is a vanity AI feature with no path through the integration pass, no eval, no HITL plan, no audit posture — I say no, and I tell them what to fix before we'd say yes. 80% of workers are rejecting AI because the deployment architecture is wrong, not because the technology is. Adding another wrongly-deployed surface accelerates the problem.

    The yes I give freely is the boring one: ship the smallest agent that touches the seams. Reads-only. HITL on writes. Audit on. One clear win in 90 days. That's the contract a $1M/year seat justifies — not the speech, the receipts.