Running a Cross-Functional Architecture Review Without a CS Degree

Running a cross-functional architecture review without a CS degree is a matter of governing constraints. The person leading it must establish what the system must do, what it must never do, and who accepts the consequences. As AI agents take on more implementation work, that human responsibility becomes more important.

Why non-engineers are being asked to govern architecture now

The diagrams are unfamiliar, the discussion turns on implementation choices, and the person whose sign-off matters was never trained to read either. Product managers, security leads, compliance officers, and operations directors may know what it is like to be caught between these roles. They are responsible for the outcome even though they do not share the engineers’ technical vocabulary. Yet whether the system is acceptable depends on what the business must do, which regulatory limits apply, and what happens when the system runs. Those are subjects they already govern.

As coding increasingly happens inside agents, human work moves upstream toward deciding what should be built, defining constraints, and verifying outcomes. Implementation and intent become more clearly separated, and the people best placed to own intent are not necessarily those who write code. Diagrams, RFCs, and ADRs make implementation legible, but they do not settle what the organization must never permit. The review needs someone with the authority to make those boundaries explicit.

What an architecture review is actually doing, beneath the technical surface

An architecture review surfaces constraints, assigns accountability, and records which tradeoffs the organization accepts. Its constraints fall into four categories, namely business, regulatory and compliance, operational, and security. Business constraints cover what the business needs, such as revenue flows and SLAs, while regulatory constraints cover rules it must follow, such as data residency and PHI handling. Operational constraints set out who is responsible for recovery and incidents, while security constraints state what the system must never expose or allow. These requirements govern database, framework, and design choices.

A concrete constraint makes that order clear. HIPAA requires a signed contract that sets the rules for PHI handling before PHI may pass through a third-party inference API. The review must establish that boundary before implementation choices can be judged against it. Engineers resolve technical tradeoffs, but they are not automatically better placed to define the obligations behind those tradeoffs. The resulting record belongs to governance because it states who accepted the choice and who owns what follows.

Why AI agents in the development pipeline make the non-engineer's role more important, not less

An agent that generates or modifies code can introduce familiar security vulnerabilities. If the organization has failed to set a constraint on those vulnerabilities, the problem starts before implementation. Block’s engineers use MCP-powered tools to migrate legacy codebases, refactor complex logic, generate unit tests, streamline dependency upgrades, and speed up triage workflows. Governance must therefore address both their outputs and their authority to act.

Early MCP deployments exposed the importance of that distinction. An enterprise identity provider could see a user logging into an individual server without seeing the AI agent connection itself, creating shadow IT risk. The November 2025 MCP spec revision added Cross App Access (XAA) to put the enterprise IdP back in control of agent connections. Recognizing this gap requires an understanding of identity and access management. A governance owner can ask whether the organization controls the agent’s access even when a user’s login appears properly governed.

The practical response is a two-layer threat model. First, review the system the agent supports, including its data flows, access boundaries, and failure requirements. Then review the agent itself, including its tools, memory, retrieval sources, MCP servers, identity, approval flows, egress paths, logs, sandboxing, and failure modes. AWS announced threat-modeling support in AWS Security Agent on June 17, 2026, describing analysis of design documents or source code that generates STRIDE-based threats with mitigations. An agent can produce that analysis, but the organization must still decide which threats it is unwilling to accept.

The four questions a non-engineer should own in every architecture review

The first question establishes what the system must never do. Its answer is the non-negotiable constraint set, expressed clearly enough to guide implementation and verification. Examples include allowing unauthenticated egress or processing payments outside PCI scope. For an agentic system, the boundaries may prohibit writes without human approval or tool calls that reach production without sandboxing. These explicit limits on acceptable behavior remain binding when delivery becomes difficult.

The second question establishes who is accountable when the system fails. Each failure mode must have a named owner before the system goes live. Assigning that owner requires an understanding of reporting lines, contractual obligations, and regulatory exposure. An implementation discussion cannot resolve a gap in organizational responsibility. The review makes that gap visible while there is still an opportunity to assign ownership.

Third, establish what the system must do under failure conditions. Recovery, degradation, and audit requirements belong here because they define which consequences the organization can tolerate. RTO and RPO are business decisions expressed as technical requirements, with the governance owner setting the requirements and engineers implementing them. Audit requirements similarly begin with the need to establish who did what, when, and with what authorization. Their implementation follows from that obligation.

Fourth, establish where the code goes and who can see it. Healthcare teams face HIPAA restrictions on PHI, legal and professional services face attorney-client privilege obligations, and organizations in the EU and China face GDPR and BDSG, and PIPL, respectively. These obligations make data residency and access control governance decisions. In a cloud agent architecture, proprietary code transits the public internet, while a self-hosted architecture keeps it within the enterprise perimeter. The governance owner sets the boundary, and the platform team fulfills it.

How to read what you cannot read: navigating an unfamiliar codebase as a governance owner

A governance owner does not need to read implementation code line by line. The task is to locate where data crosses trust boundaries, which external systems the code calls, who owns each module, and what a component change could affect. It also requires understanding why the structure exists and which earlier constraint or decision produced it. Codebase maps, dependency graphs, ownership metadata, and architecture decision records provide a route into the system by answering these governance questions about how it is built.

Natural-language interfaces make that route more accessible. A governance owner can ask which services the payments module calls externally and receive a direct answer. DeepWiki, from Cognition, has pre-indexed popular public repositories, with free access for public repositories and paid plans for private repository access and higher-quality generation. Self-hosted code intelligence platforms provide the same class of query capability inside the organization’s infrastructure. For an owner who has already set a data-residency constraint, that deployment model lets them see the code while keeping it within the enterprise perimeter.

The Model Context Protocol (MCP) supplies a common connection layer for this tooling. It is an open standard defining how AI applications connect to external tools, data sources, and services. Rather than requiring a bespoke integration for every connection, it provides one protocol implemented on each side. The governance owner need not understand that implementation to govern its use. The relevant questions remain which systems the agent can reach, under whose identity, and with what approval flow.

Running the review session itself: structure, participants, and the artifacts that matter

The session should produce three durable artifacts, which are a constraint register, an accountability map, and a decision record. The governance owner runs the meeting and owns the register, while an engineer or technical lead assesses whether the system can be implemented within its constraints. A security or privacy representative validates coverage of the threat model. An operations or reliability representative assesses whether failure and recovery requirements are realistic. For agentic systems, the review also needs whoever owns the agent’s identity and tool permissions, often a platform or infrastructure lead.

Draft the constraint register before the meeting and update it during the discussion. Its structure is simple, with fields for the constraint, its source, its owner, and its verification method. The source establishes whether the requirement comes from a regulatory, contractual, operational, or business obligation. Engineers confirm feasibility rather than becoming the default authors of those obligations. For agentic systems, add a distinct agent layer covering tools, memory, retrieval sources, MCP servers, identity, approval flows, egress paths, audit logs, sandboxing, and failure modes.

Open the meeting by reading the constraint register aloud so that obligations frame the discussion. For each constraint, confirm that it remains accurate, has an owner, and has a verification method. Build the accountability map during this process by naming an owner for each failure mode. An unowned failure mode is a governance deficit. Flag technical design questions as action items for engineers to resolve offline rather than letting them displace the review’s purpose.

The Architecture Decision Record (ADR) captures which tradeoffs were accepted, by whom, and why. The governance owner records the constraint that drove each decision and the accountability consequence of the choice. The engineer adds the reasons for the implementation choices, so both sides of the reasoning are kept in one lasting record. That record allows the decision to remain intelligible after personnel changes. Close the session by confirming that the accountability map is complete and the ADR is drafted.

Where the non-engineer governance owner still needs engineering partnership

Engineers must assess whether current technology choices can satisfy a requirement and what that requirement costs in latency, throughput, or availability. They must also judge whether a proposed verification method tests what the system is required to do. With agentic systems, they must also weigh costs such as how much of the context window is used by connecting multiple MCP servers with many tools. These consume token budget before useful work begins and can affect the governance owner’s tooling decisions.

The governance owner sets the constraint and acceptance threshold, the engineer assesses feasibility and cost, and the governance owner decides whether that cost is acceptable. Deferring all constraint-setting because the language sounds technical abandons the business, regulatory, and operational responsibilities the review exists to protect. Agentic delivery introduces another version of that failure when code generation outruns review and constraints are skipped for speed. The constraint register must remain a precondition of agent-assisted delivery.

Building the organizational habit: making cross-functional architecture governance routine

A successful meeting becomes governance only when the organization makes it a habit to keep constraints in view. Reviews should be triggered by new system components, agent integrations, external data flows, or changes in regulatory exposure. Agents can change systems faster than quarterly reviews can track, so governance owners need early-warning signals. A maintained register and an established review cadence give those signals somewhere to lead. Without that continuity, each meeting has to reconstruct the obligations it should be applying.

The access model matters as much as the schedule. Governance owners need queryable codebase structure without depending on engineers to translate every navigation question. Self-hosted code intelligence, deployable as a single Docker container and connected to the organization’s repositories, can provide that access without exposing code outside the enterprise perimeter. MCP-based connectors to Jira, Linear, and Confluence can link the constraint register and ADR library to live codebase context. This lets people find governance information as they work, without having to hold another meeting to recover it.

The same access supports new governance owners who need to learn where to start, who owns what, and why the system took its present shape. A queryable constraint register and ADR library become their ramp-up guide. The organizational investment is a register template, a review cadence, queryable codebase access, and an owner who can apply the four questions. As agents speed up implementation, the pace of safe delivery depends on how fast people can set constraints and name who is accountable. The teams that win will treat constraint governance as a first-class function.