Internal AI Counterpart Context and Read-Completeness Automation: 11 of 371, and a Screen That Showed Nothing

Designing one agent to have deliberately broad, cross-module access is a reasonable, explicit choice — but if that access is implemented through the exact same mechanism used to grant every OTHER agent its narrow, single-domain access (one tag, on one tool, in one shared table), the broad agent's own reach is only ever as complete as someone remembering to tag every new tool for it specifically. A newly registered tool for a newly built module does not automatically inherit a blanket-access agent's permission just because that agent is supposed to see everything — each addition is its own, separate act of remembering, and the mechanism has no structural way to notice on its own that a specific tag was left off a specific row.

One of Centriu's internal specialist AI agents is deliberately built differently from the others on this pillar's own internal-agent-governance pages: rather than being scoped to a single domain (support, performance marketing, a specific reporting surface), it is modeled to operate on the business owner's own behalf, and is meant to have read access across essentially every module the business runs. That access is not implemented as a special case in code — it flows through the exact same shared table that governs every other agent's much narrower permissions: each registered tool carries a `risco` level (read or write) and an array of role tags naming which agent roles may use it, and this agent's own broad-access role is simply one more tag that has to be present on a given tool's row for it to see through that tool at all.

Measured directly against the real table: 371 tools are currently registered, and 11 of them — every one confirmed read-risk, meaning simply looking, not acting — did not carry this agent's own tag. All 11 belonged to modules the migration's own comment names explicitly: pricing, product and technical variants, dashboard reporting, legal documents, localization and translations, brand strategy, goal tracking, a stalled-item list inside one production system, a separate stalled-item list inside another, quality approvals, and creative-fatigue tracking. None of these are edge cases invented for this fix — they are eleven real, already-shipped reporting and tracking surfaces the business already runs on, that this specific agent simply could not see into, for as long as each one had existed without anyone specifically remembering to add its tag.

The fix itself is a single, targeted backfill: add the missing tag to every currently available, read-risk tool that does not already carry it — nothing broader, nothing touching write-risk tools, nothing retroactively changing what any OTHER agent role can see. What distinguishes this fix from a simple data patch is what runs immediately after it, inside the same migration: a database block re-queries every available, read-risk tool and checks, directly against the real, live authorization-check function — the exact function every actual request from this agent is evaluated against — whether this agent's own specific identity can now use it. If even a single tool still fails that check, the block raises a named, counted exception and the migration itself fails to complete. This is not a comment asserting the fix worked; it is the fix proving itself, in the same transaction, against the real authorization logic, at the moment it runs.

A second, related gap closed in the same investigation lives one layer up, on the screen a person actually uses to review this agent's own sessions. A session that exists purely to REGISTER context — no live back-and-forth conversation ever took place, but a real summary of that context was captured and stored — is a genuinely different kind of session from an empty one. The screen's own condition for showing an empty state checked only whether a conversation existed and whether a recommendation had been generated; it had no third branch for a session carrying only a summary. Opening exactly that kind of session showed a generic, empty-inbox icon and a placeholder message — visually indistinguishable from a session with nothing recorded at all, even though real, specific context sat in the database the entire time. The fix adds exactly that third branch: when no conversation and no recommendation exist, but a summary does, the screen now shows the actual recorded content, labeled clearly as registered context, instead of treating it the same as true emptiness.

Someone asks the internal agent modeled on the business owner's own behalf a question that depends on the business's current goal-tracking data — something the agent is deliberately designed to be able to see across, being one of the modules covered by its broad access. Before the fix, the underlying tool for that specific domain had never been tagged for this agent, so the answer comes back with no data for that domain — not an error, just an absence, indistinguishable from the domain genuinely having nothing in it. Separately, someone opens a session that was created purely to register a piece of context — no conversation ever happened inside it — expecting to see what was recorded. Before the fix, the screen shows the same generic empty state as a session with nothing in it at all. After both fixes, the goal-tracking question returns a real answer, and the context-only session shows exactly what was recorded.

The internal AI agent modeled on the business owner's own behalf now has confirmed, self-verified read access to all 371 currently registered tools it is designed to reach across — closing an 11-tool gap that had produced silent, undetectable blind spots across pricing, reporting, legal, localization, brand strategy, goal tracking, two systems' own stalled-item lists, quality approvals, and creative-fatigue tracking — and the session-review screen for this agent's own conversations now shows a recorded context summary instead of treating it as empty.

This automation governs the completeness of one internal AI agent's own READ access across Centriu's internal tool-permission system, and how a specific kind of internal session is displayed — it does not change what any other agent role can access, does not grant any new write capability, and does not affect any customer-facing feature or data.

Confirming a broad-access role's permissions are complete by reviewing the table once, at the time the role is designed, only guarantees correctness at that one moment — every tool registered afterward is a fresh opportunity for the exact same kind of gap to reappear, silently, with no mechanism forcing anyone to remember. Centriu's fix pairs the correction with a genuine, executed proof INSIDE the same migration that makes the change, rather than a comment asserting the change is complete — the same discipline confirmed running across several of this system's other recent permission migrations, each proving its own specific claim the same way, against the same real, live authorization function every actual request is checked against.