The PAC Framework™

The structure for your agentic transformation. Three pillars to navigate what agents can do, and what they should.

PAC Framework: Potential, Accountability, Control

How do you decide when the landscape won't hold still? By focusing on the right questions.

The barrier to building agents has never been lower. What's possible changes by the month. The real question isn't whether you can. It's whether what you build today still compounds in a year, or becomes dead weight when the next model drops.

Agents are already making decisions in your organisation. Some you don't even know about. When something goes wrong, someone has to explain what happened. If the liability chain isn't mapped before the incident, it's too late to draw one after.

Policy says "don't." Architecture says "can't." The difference matters when agents act autonomously across systems and organisations. Identity, delegation, sandboxing: the infrastructure to enforce what governance promises.

See what's really possible. Pick what lasts. Govern it. Enforce it.

They're Interdependent

Drop any one and the others fall short.

Potential without Accountability: reckless adoption. You build fast and hit a wall when the first incident happens and nobody can explain what went wrong.

Accountability without Control: governance on paper. Policies mean nothing if the infrastructure can't enforce them.

Control without Potential: infrastructure without a mandate. If the business doesn't see value, funding stops.

Inside Each Pillar

Each pillar has a specific structure. These are the questions and trade-offs that surface in practice.

Business value: not every process benefits from an agent. The question is where it actually mattersV1 IncrementalV2 OperationalV3 StrategicV4 Transformative
Reliability: how often it gets it right — and how confident you are in that number. Without the error margin, the percentage means nothing. A workflow's failures are enumerable; an autonomous agent's aren'tMeasured as % ± error margin
Blast radius: what happens when it's wrong. Same quality, very different consequences depending on where output landsB1 ContainedB2 RecoverableB3 ExposedB4 RegulatedB5 Irreversible
Autonomy: the level of independence the agent earns, determined by all dimensions togetherA1 SuggestionA2 ApproveA3 OversightA4 DelegatedA5 Autonomous
Implementation architecture: workflows, agent loops, and autonomous agents aren't exclusive choices — they compose. A workflow can contain an agent loop step that delegates to an autonomous sub-agent. The outer layer sets the reliability floor and tightens the error margin; the inner layer raises the quality ceiling
Context management: what information reaches the agent, and how
Model selection: frontier or open-weight? Cloud or on-prem? What are you locked into?
Cost structure: setup, hosting, and inference. Cloud scales per call; on-prem means hardware that depreciates
Durability: build on what stays stable: workflow logic, context infrastructure, evaluation pipelines. Not on what changes every quarter
Harness debt: scaffolding you built to compensate for a weaker model becomes a liability when the model improves. Most teams don't see it until a new model drops and their pipeline fights it. (Read more)

Potential Scanner (in development): the AI-driven tooling behind our agentic screenings. Capability decomposition, model tier scoring, and harness debt analysis, built on the Potential pillar.

Governance thresholds: the reliability bar for each autonomy level depends on blast radius, and it is a lower bound, not a headline rate. Contained tasks can tolerate more; irreversible ones never clear it
Shadow agents: employees are already building agents without compliance review. The liability sits with the company. You can't govern what you can't see. (Read more)
Delegation becomes abdication: agents interpret and expand intent. If you can't trace what was given and what was acted on, accountability dissolves. (Read more)
Liability chains: if the chain isn't mapped before the incident, it's too late to draw one after
Data governance: what agents can access, where it goes, and what regulation requires
Audit trails: designed for compliance, not just debugging. Can you show a regulator what happened and why?
Regulatory landscape: EU AI Act, NIST, ISO 42001. The frameworks are converging. Better to shape governance around them than react
Ownership: who owns AI governance? If no one owns it, everyone assumes someone else does

Infrastructure as gate: either you have audit trails or you don't. Either credentials are scoped or they aren't. No reliability score compensates for guardrails you haven't built. (Read more)I1 OpenI2 LoggedI3 VerifiedI4 AuthorizedI5 Contained
Policy vs. architecture: policy says "don't." Architecture says "can't." The difference matters when agents act autonomously
Approval that scales with the blast radius: a read can stand for a month and a repair for a day; whatever reaches outsiders at once is signed per action with its parameters shown, and an irreversible act is never delegated
Agent identity: who is this agent, who does it act for, and how do you prove it? The building blocks exist: DIDs, Verifiable Credentials, OAuth OBO. They weren't built for agents, but they apply directly
Delegation chains: what an agent can access, for how long, and what happens when it hands off to another agent
The confused deputy: an agent with credentials but no scoped limits on what it can do with them. Every delegation without explicit boundaries is a potential confused deputy. (Read more)
Cross-organisation trust: when agents cross organisational boundaries, how do you authenticate, pass authority, and keep someone accountable?
Emerging trust infrastructure: eIDAS 2.0, EUDI wallets, business wallets. The identity layer is being rebuilt, and agent infrastructure needs to interoperate
Supply chain: which models, plugins, and APIs does your agent depend on? Can you trace what changed?
Standards: OAuth 2.1, OBO, Trust Spanning Protocol, AgentGateway, OpenID for agentic identity. The building blocks for agent auth, delegation, and cross-domain trust are landing fast

Observed

Blast radius

What happens when it is wrong, and whether the world can be put back. Two questions, not one: a wrong header is public and undoable, a sent mail is invisible and permanent. Before anything acts alone, the undo has to be known: who reverses it, how, and how long that takes.

B1 Contained: wrong output stays inside the system that produced it
B2 Recoverable: it reaches something real, and undoing it restores the world
B3 Exposed: people outside see it before anyone can undo it
B4 Regulated: a regulator, a contract or a supervisory body is involved
B5 Irreversible: no undo exists: money moved, mail sent, data published, safety touched

Reliability

How often it gets it right, and how confident you are in that number. Count only the outcomes something has judged, and read the lower bound of the confidence interval rather than the headline: ten out of ten is a lower bound near 72%. The implementation pattern determines how knowable that bound is.

Infrastructure

The guardrails in place.

I1 Open: nothing recorded, nothing scoped: the agent acts with what it was handed
I2 Logged: every action is written down afterwards
I3 Verified: the record is signed, so a stranger can check it was not edited
I4 Authorized: a permit decides per action, before it happens, and refuses outside it
I5 Contained: the credential never reaches the agent: something else performs the act

Business value

Why it matters.

V1 Incremental: saves effort on work that was already being done
V2 Operational: changes how a process runs, not only how fast
V3 Strategic: changes what the organisation can offer
V4 Transformative: changes what business the organisation is in

Verifiability framework only: the profiler visualises six axes

Can something other than the agent tell it was wrong, and soon enough to matter. This is what makes a narrow action safe on its first run, with no track record at all, and what no track record can replace when it is absent.

K1 Unchecked: nothing can tell whether the output was right
K2 Sampled: someone looks at a sample now and then
K3 Reviewed: a person reviews each output before or after it lands
K4 Checked: a check runs on every output, by a path the agent does not control
K5 Refutable: that check can prove it wrong, and soon enough to matter

Decided

Governance thresholds

Where the line is drawn: the lower bound reliability has to clear, over a minimum of judged outcomes, rising with the blast radius. Each organisation sets its own. In Above Beyond's own fleet the bar runs from 0.80 over ten judged runs for contained work to 0.96 over eighty for regulated work, about a year of evidence. Irreversible work has no bar: no record earns it, so make the action reversible first.

Follows

Autonomy

The level of independence the agent earns. Not a dial you set: it follows from the others, and the bar rises with the blast radius. It is lost the same way: one refuted outcome sends it back to approval.

A1 Suggestion: it proposes, a person does the work
A2 Approve: it does the work, a person approves before it lands
A3 Oversight: it acts, a person watches and can stop it
A4 Delegated: it acts alone within a set boundary, and is checked afterwards
A5 Autonomous: it acts alone and sets its own boundary

19 Questions for Your Team

Each pillar translates into concrete questions you can take to your stakeholders. Conversation starters, not a checklist. The right question at the right table surfaces gaps that dashboards and audits miss.

What decisions are you not yet delegating to agents, and what's that costing you?
Will better models make your current setup more valuable, or obsolete?
How much value are you leaving on the table by over-constraining?
Are your agents actually making decisions, or just automating steps humans already defined?
Does the right context reach your agents at the right time?
Are you building on established and emerging standards, or on an island?
Do you know the error margin on your agent's reliability, or just the headline number?

Do you know every agent running in your organisation?
If an agent causes harm, is the liability chain clear?
Can your infrastructure prevent an agent from running without being registered?
Could you explain to a regulator what your agent did and why?
When an agent makes a consequential decision, can you trace who authorised it and what happened?

Are your agents contained by architecture, or only by policy?
When agents delegate to other agents, can authority only decrease?
What happens when human oversight breaks down in practice?
How do you balance agent quality with data privacy?
Are agents restricted to what they can do, or only blocked from what they can't?
Does your agent setup work when agents need to cross trust boundaries?
What happens when an agent wanders into a use case you didn't anticipate?

Where the Rules Meet the Questions

Each question points at the articles, controls and functions a regulator or auditor would ask about. Indicative, not legal advice: a starting row for the compliance person at the table.

	EU AI Act	ISO/IEC 42001	NIST AI RMF
P1		A.6.1.2	MAP 1
P2		A.6.2	MANAGE 2
P3		A.5	MAP 1
P4	Art. 3	A.6.1.2	MAP 1
P5	Art. 10	A.7	MAP 2
P6		A.10	GOVERN 6
P7	Art. 13, Art. 15	A.6.2.4	MEASURE 2
A1	Art. 26, Art. 49	A.4.2	GOVERN 1.6
A2	Art. 25, Art. 26	A.3.2	GOVERN 2
A3	Art. 49	A.4.2	GOVERN 1.6
A4	Art. 12, Art. 13, Art. 86	A.6.2.8, A.8.2	GOVERN 4
A5	Art. 12, Art. 14	A.6.2.8	MANAGE 2
C1	Art. 9, Art. 15	A.6.2.6	MANAGE 1
C2	Art. 25	A.10.2, A.10.3	GOVERN 6
C3	Art. 14, Art. 26	A.9.2, A.6.2.6	MANAGE 2
C4	Art. 10, GDPR Art. 5, GDPR Art. 25	A.7	MEASURE 2
C5	Art. 15	A.6.2.6	MANAGE 1
C6	Art. 25	A.10	GOVERN 6
C7	Art. 9, Art. 72	A.6.2.6	MANAGE 4

Article numbers refer to Regulation (EU) 2024/1689, ISO/IEC 42001:2023 Annex A and NIST AI RMF 1.0. The whole framework, with ids, is also served as data: pac.json

It's Iterative

Models improve, protocols land, regulations tighten, internal policies evolve. And your own progress shifts the landscape too: the right control infrastructure unlocks new autonomy levels, which open new use cases, which create new blast radius, which demands new accountability. This isn't a one-time assessment. It's a living practice. PAC is built to be re-run, and the Agent Profiler gives you a concrete way to track how your positions shift across iterations.

This framework underpins everything: the programme, the workshops, and the advisory services. Start with the free tools, or go deeper when you're ready.

Assess your use case →

Questions? shane@trustedagentic.ai