Part 5 of The E-Myth, revisited again

The previous article ended with a promise: after establishing why roles should be designed as bounded intelligence and why policies should govern their behaviour, we need the mechanics. How do you actually define a role so it can be delegated to a human, an AI, or a hybrid — and perform coherently regardless of which?

This is where theory meets practice. The shift from job descriptions to bounded intelligence specifications is not a minor refinement. It is a different way of thinking about what a role actually is.

What job descriptions actually specify

A typical job description lists responsibilities, reporting relationships, and required qualifications. "Manage client relationships." "Ensure content quality." "Handle customer enquiries." These statements describe what someone should do, but they assume an enormous amount about how they should do it.

Consider "manage client relationships." The phrase implies recognising when a client is unhappy before they say so explicitly. It implies knowing which concessions the company can afford and which it cannot. It implies understanding the difference between a client who needs reassurance and one who needs a solution. It implies sensing when a situation has escalated beyond the role's authority.

None of this is written down. None of it needs to be — because humans fill these gaps automatically. The job description is not a complete specification. It is a pointer to a much richer definition that exists only in tacit knowledge, accumulated experience, and contextual judgment.

This worked well enough when every role was filled by a human. The job description provided direction; the human provided everything else. Training might make the tacit knowledge explicit for a while, but once someone was competent, the description returned to its proper place as shorthand.

Why this breaks with AI

AI systems do not infer unstated requirements. They do not bring decades of accumulated social knowledge to every interaction. They do not sense when something feels off.

Give an AI the instruction "handle customer enquiries" and you will get wildly different behaviour depending on what else the system knows or doesn't know. Without explicit boundaries, the AI either overreaches — making decisions it should not make, like promising delivery dates or acknowledging liability — or underreaches, escalating everything because nothing is clearly within its scope.

The job description model produces AI implementations that are brittle, inconsistent, and heavily dependent on human oversight. The human ends up doing so much monitoring and correction that the delegation barely saves time. This is not a problem with the AI. It is a problem with the specification.

The same issue appears, less obviously, with human delegation. A new hire given only a job description will struggle until they absorb the tacit knowledge through observation, mistakes, and feedback. The difference is that humans eventually figure it out. AI systems do not figure anything out — they operate within whatever boundaries you define, and they explore every edge of those boundaries relentlessly.

The bounded intelligence specification

A role defined as bounded intelligence includes ten components that, together, specify everything the job description left implicit.

1. Objective. What the role is trying to achieve — not just what it does, but what success looks like. "Ensure published content maintains brand voice and meets quality thresholds" is different from "review content." The objective gives the role a purpose against which decisions can be evaluated.

2. Decision authority. What decisions this role can make autonomously. "Can approve content that matches tone guidelines" is decision authority. "Handles content approval" is not. The precision matters because anything not explicitly authorised will either be attempted inappropriately or avoided unnecessarily.

3. Decision boundaries. What the role must not decide, even if it seems logical. "Cannot approve content mentioning pricing without human review." "Cannot communicate directly with clients." These boundaries are not limitations to work around — they are load-bearing constraints that keep the role operating safely.

4. Inputs. What information the role receives and from where. Draft content arrives from the content creation function. Brand guidelines come from the design layer. Historical approved examples provide precedent. Specifying inputs prevents the role from operating on incomplete information or seeking data it should not access.

5. Outputs. What the role produces and for whom. Approval decisions go to the scheduling system. Revision requests go back to content creators with specific feedback. The outputs connect this role to others in the capability map.

6. Constraints. Rules that apply regardless of the objective. All content must pass a plagiarism check. All claims must be verifiable. These are not trade-offs — they are inviolable. When constraints conflict with objectives, the constraint wins.

7. Trade-off guidance. What happens when objectives conflict with each other. When deadline pressure conflicts with quality standards, should the role approve substandard work, miss the deadline, or escalate? The specification should say. Without trade-off guidance, the role makes these decisions inconsistently or based on whatever heuristic it defaults to.

8. Failure modes. How the role can fail and what happens when it does. If the plagiarism check is unavailable, does the role approve content anyway, reject it, or hold it for human review? If inputs are incomplete, does the role proceed with best-effort judgment or stop? Specifying failure modes turns "what could go wrong" into "what happens when it goes wrong."

9. Escalation triggers. Specific conditions that require handing off to another role or a human. These are the most critical part of bounded intelligence design, and they deserve their own section.

10. Success criteria. How to know if the role is performing well. Revision request rate, time to approval, client satisfaction scores. Without success criteria, you cannot detect drift or degradation until something visibly breaks.

Writing decision authority and boundaries

Decision authority is not a vague scope statement. It is a specific enumeration.

Consider the difference between "handles refunds" and "can approve refunds up to £50 for orders placed within 30 days when the customer provides a valid reason." The first version requires the person or system filling the role to interpret what "handles" means, what counts as a valid refund, and where the authority ends. The second version specifies exactly what decisions the role can make.

Decision boundaries require equal precision. "Cannot promise delivery dates" means something different from "cannot discuss delivery." "Cannot acknowledge liability" is a legal boundary that must be stated explicitly because it is not obvious from the role's purpose. "Cannot communicate directly with clients" might seem like an odd boundary for a customer service role, but it might be exactly right for a quality review function that needs to route communications through a different channel.

The precision matters more for AI-filled roles than for human-filled ones. Humans interpret boundaries with common sense. AI systems explore edges. If a boundary says "cannot promise delivery dates," an AI might interpret "we usually ship within three days" as information rather than a promise. The boundary needs to anticipate how it might be tested.

Defining escalation triggers

Escalation triggers answer the question: when should this role stop and ask for help?

Good triggers are specific and observable. "Any request involving more than £500" is a trigger. "When in doubt" is not — because an AI system does not experience doubt. "Any mention of legal action" is a trigger. "When the situation seems serious" is not — because "seems serious" requires exactly the kind of judgment that escalation is meant to protect.

The triggers should cover several categories. Threshold triggers activate when a value exceeds a limit: amounts, frequencies, durations. Pattern triggers activate when the role recognises something it was told to watch for: competitor mentions, legal language, unusual requests. Coverage triggers activate when the role encounters something outside its defined scope: new content formats, unfamiliar situations, cases not covered by existing templates. Conflict triggers activate when the role cannot resolve competing priorities: deadline versus quality, customer satisfaction versus policy compliance.

The design principle for escalation is fail safe. The role should err toward escalation rather than autonomous action at the edges. A role that escalates too often is annoying but correctable. A role that acts autonomously outside its competence creates problems that are harder to fix.

Specifying failure modes

Every role can fail. Bounded intelligence design makes failure modes explicit and plans for them.

What happens if the role receives incomplete inputs? A content review role might receive a draft without the associated brand guidelines. Does it review against general principles, request the guidelines, hold the content, or escalate? Each option has different implications.

What happens if constraints conflict? A constraint says all claims must be verifiable. Another constraint says content must be approved within 24 hours. A piece of content arrives with claims that cannot be verified before the deadline. Which constraint wins? The specification should answer this.

What happens if the role cannot determine which escalation trigger applies? A customer enquiry mentions a competitor and also involves an amount over the threshold and also uses language that might be legal in nature. Does the role pick one trigger, log all of them, or escalate with a different priority? Ambiguity at the edges creates inconsistent behaviour.

Failure modes should define graceful degradation — how the role behaves when operating outside its designed parameters. The goal is not to anticipate every failure, but to establish defaults that are safe. Hold rather than approve when uncertain. Escalate rather than act when ambiguous. Log rather than ignore when something unexpected happens.

Designing for humans versus designing for AI

The same bounded intelligence specification works for both human and AI-filled roles, but the margin for error is different.

When a human fills a bounded intelligence role, the specification serves as guidance. The human will adapt intelligently to situations the specification does not anticipate. They will recognise when a boundary should probably be interpreted flexibly. They will use judgment about whether an escalation trigger really applies to this particular case.

When AI fills the role, the specification is the constraint. The AI will not adapt beyond what is specified. It will apply boundaries literally. It will trigger escalation exactly when the conditions are met, not when it "makes sense" to escalate.

This means AI-filled roles require more complete specifications. Edge cases that a human would handle sensibly need to be anticipated. Boundaries that a human would interpret with nuance need to be stated precisely. Escalation triggers that a human would apply with judgment need to be specific enough for literal application.

The bounded intelligence specification provides a common language for roles regardless of who fills them. But the level of completeness required depends on whether you are designing for adaptation or for constraint.

How this connects to policies

Article 4 distinguished procedures from policies. Procedures tell you what to do; policies tell you what matters. Bounded intelligence specifications are where policies become operational for specific roles.

A policy might say "prioritise customer satisfaction within profitability constraints." That is organisation-wide intent. The bounded intelligence specification for a customer service role translates that policy into specific decision authority (can offer credits up to a certain amount), specific constraints (cannot reduce prices below cost), specific trade-off guidance (when satisfaction and profitability conflict, escalate rather than choose), and specific escalation triggers (any request that exceeds the role's authority to resolve).

Policies are situation-independent principles. Bounded intelligence specifications are situation-specific implementations. The policy tells every role what matters. The specification tells each role how to operationalise what matters within its particular scope.

The content review function

Return to the marketing agency from earlier articles. Consider the content review function — the capability that ensures published content maintains brand voice and meets quality thresholds.

A traditional job description might read: "Review content for brand consistency and quality before publication. Flag issues for revision. Ensure all content meets client standards."

This description works well enough for a human reviewer who has absorbed the tacit knowledge of what "brand consistency" means, how to recognise "quality," what "client standards" are, and when to "flag issues" versus approve with minor concerns. A new reviewer would take months to become competent, learning through observation, feedback, and mistakes.

For an AI system — or for a hybrid arrangement where AI handles routine reviews and humans handle exceptions — this job description is useless. It provides no actionable boundaries.

The bounded intelligence specification for the same role looks different. The objective is ensuring published content maintains brand voice and meets quality thresholds before publication. Decision authority includes approving content that matches tone guidelines and historical patterns, requesting revisions for specific identified issues, and scheduling approved content for publication. Decision boundaries specify that the role cannot approve content mentioning pricing, cannot publish content in new formats without human review, and cannot communicate directly with clients.

Inputs include draft content from content creators, current brand guidelines from the design layer, historical approved examples for precedent, and the publication schedule. Outputs include approval or revision decisions routed to the scheduling system, and revision requests with specific feedback routed to content creators.

Constraints are inviolable: all content must pass plagiarism check before approval, all factual claims must be verifiable against provided sources. Trade-off guidance states that when deadline pressure conflicts with quality concerns, escalate rather than approve substandard work.

Failure modes are specified: if unable to determine brand alignment, escalate to human review; if plagiarism check is unavailable, hold content until check is restored; if brand guidelines are missing or ambiguous, escalate rather than interpret. Escalation triggers include any content mentioning competitors, any content requiring legal review, any case where the content creator disputes the revision request, and any new content format not previously reviewed.

Success criteria include revision request rate, time to approval, client satisfaction scores with published content, and escalation frequency.

The job description version produces different outcomes depending on who fills the role. The bounded intelligence version produces consistent outcomes regardless — because everything the role needs to operate is specified rather than assumed.

The mechanics and the strategy

This article has focused on mechanics: how to define a role so it can be delegated coherently. The specification framework works whether the role is filled by a human, an AI, or a hybrid.

But the specification does not tell you how to decide what fills each role. That is a different question — a strategic one. Which roles should be filled by humans because they require judgment that cannot be specified? Which should be filled by AI because they are routine enough for specification? Which must remain hybrid because the judgment is specifiable but the stakes are too high for autonomous operation? Which should remain deliberately inefficient because efficiency would compromise something the organisation values?

The next article will address that strategic layer: deciding where judgment belongs.