The Intelligence Layer Needs a Signature Line
A companion piece, written in agreement with the enterprise intelligence layer argument — and in service of the parts it leaves for the reader to supply.
The intelligence layer argument is generally right about the thing most organizations get wrong. Governance debates stall because they're abstract, and infrastructure makes them concrete. You cannot resolve "is this safe to turn on" in a policy document; you resolve it with audit trails someone can inspect, access controls someone can review, and evaluations someone can rerun. The second-project argument is also right: shared harnesses beat per-project heroics, and an organization that rebuilds its guardrails for every application isn't governing, it's improvising in parallel.
So: yes. And — an intelligence layer built exactly as described will pass its architecture review and still fail its first real incident, because three load-bearing elements live outside the diagram.
The layer has no signature line
Walk through the governance pillar: guardrails, audit trails, prompt management, evals, monitoring, configurable rules. Every element is harness. No element is a person. Nowhere in the architecture does a named human own an output, hold the authority to refuse a deployment, or intervene before a consequence becomes practically irreversible.
This matters because harnesses bound and detect; they do not certify. An eval suite samples a distribution — it tells you how the system behaved on the cases you thought to test, which is not the same as trusting "what output will be produced for given inputs." A guardrail catches the failure classes someone anticipated. The gap between bounded and correct is exactly where a human review has a job, and an architecture that doesn't name whose job it is has built an accountability vacuum with excellent observability. When something goes wrong, the audit trail will faithfully point at whoever configured the nearest guardrail — the person with the least authority over the architecture that produced the failure. There's a name for a human positioned to absorb blame for a system they couldn't meaningfully control, and it isn't "accountable owner."
The fix costs one sentence per application: this output class is signed by this role, who can inspect it, refuse it, and interrupt it before execution. If no role can honestly sign that sentence, that's not a paperwork gap — it's a discovered fact about the system, and the architecture review should treat it as a blocker no differently than a missing authentication layer.
Discoverability is an exposure decision, not a plumbing decision
The first pillar's goal — organizational data made semantically discoverable so agents can find what they need without a human wiring each connection — is the genuine capability unlock, and it is also, stated plainly, a deliberate expansion of the input-exposure surface. These are the same fact. An agent that can discover any API and compose it at runtime is the textbook confused deputy, and agent-discoverable capability plus retrieved untrusted content is the canonical prompt-injection surface. None of this argues against the semantic layer. It argues that the decision to make a data source discoverable is a governance event — the moment of exposure — and it happens before any output exists for the observability pillar to observe.
Output errors can be caught downstream. Disclosures cannot be un-sent. So the intake question for the semantic layer isn't "can the agent find this" but "what happens when the agent finds this while processing content an adversary influenced" — asked per source, at onboarding time, with the same seriousness the architecture already applies to model outputs. An intelligence layer with world-class output monitoring and an unreviewed input surface is a vault with cameras inside and no lock on the door.
Trust is earned per promotion, not granted per platform
The subtlest risk in a frictionless foundation is that it makes every artifact feel production-grade at birth. When the data connections exist, the guardrails are inherited, and a new application is "an agent configuration and a prompt workflow," nothing in the developer experience distinguishes an exploratory sketch from evidence an auditor will rely on. The platform's whole value proposition is that those feel the same to build.
They must not feel the same to promote. An output's institutional status — sketch, working record, recommendation, executed change — should set its evidence requirement, and crossing each boundary should trigger validation appropriate to the artifact, not to the platform. This is cheap to implement precisely because the layer exists: the provenance capture, the eval hooks, and the audit trail are already there. What's missing is only the rule that says the bar rises when the artifact's authority does — and that the self-composing agent, the architecture's most ambitious promise, sits at the top of that ladder, not outside it, because an agent that assembles its own integration path is the artifact whose provenance is hardest to reconstruct after the fact.
The honest tagline
"Governance as the mechanism for saying yes" is a good pitch and a bad design goal. A governance function whose purpose is enablement has had its refusal capacity defined away before the first sprint. The sturdier framing keeps both edges: the intelligence layer is the infrastructure that makes yes fast and no meaningful — fast yes, because the controls are concrete and reusable; meaningful no, because somewhere in the architecture a named person has the information, the authority, and the standing to refuse, and the system is built so that refusal is a supported operation rather than an outage.
An intelligence layer with a signature line, an input-exposure review, and promotion gates isn't a slower version of the original proposal. It's the version that survives contact with its second incident — which, like the second project, is where the architecture's value actually gets tested.