🛠️ Fable 5 as a Work Agent

An advanced model like Fable 5 is wasted on summarizing text or answering quick questions — its real value shows up in difficult problems: reviewing an entire project's architecture, assessing product/technology/business risks, turning an idea into an execution plan, analyzing a long document, and reviewing code/security/UX/databases.

Directing the right tool to the right task is the first filter for using the model as a work agent, not as an expensive chat.

High-value task; wasted capacity; diagnosis vs. quick question.

A prompt template that asks for a diagnosis of the core problem, strategic decisions, risks, a step-by-step execution plan, concrete deliverables, and what to do now — in order.

It’s a ready-to-copy-and-adapt prompt, tested on real project analysis tasks.

Prompt tested in practice (not an official quote); senior agent; deliverable in stages.

The model responds better when it understands the intent behind the request: the larger goal, audience, context, and expected result — not just the bare instruction.

"Create an AI learning path" is weak; saying who it’s for, what its goal is, and what final outcome you expect completely changes the quality of the response.

Intent context; target audience; stated expected outcome.

A template that states the objective ("professionals who want to apply AI at work by practicing every day") before asking for a learning path with an initial assessment, daily practice, a weekly project, support, progress criteria, and a final outcome.

Comparing the weak and strong prompts side by side clearly shows the benefit of adding context before asking.

Weak vs. strong prompt; structure with progress criteria; expected final result.

In practice: before writing any heavy analysis prompt, first confirm that the task warrants the model (Tip 1), then establish the real reason for the request (Tip 2)—together, they make a complete diagnostic prompt.

Used separately, each tip helps a little; combined, they change the kind of response you get.

Task filter + intent context; complete diagnostic prompt.

Common mistakes: using the model for a summary/caption task; asking for analysis without saying who it’s for or what outcome you expect; copying a generic prompt without adapting it to the actual project.

Quick checklist before starting: is the task difficult enough? Is the rationale explicit? Are the audience and outcome clear?

Pre-prompt checklist; adaptation to the real project; explicit rationale.

Low: summary, caption, text edit, quick idea. Medium: simple planning, comparison, content review. High: strategy, architecture, audit, product decision. Maximum: critical issue, migration, security, complex risk analysis.

Asking for maximum reasoning on a trivial task costs more and takes longer without any benefit—and the opposite produces an answer that’s too shallow for a serious decision.

Depth of analysis; cost × complexity; calibration by task type.

A short prompt that limits where to apply depth: "use deep analysis only for the strategic part. Don't overcomplicate the solution. Don't create unnecessary abstractions. Deliver the simplest solution that solves the problem well."

Focuses the expensive effort where it matters and keeps the rest of the response from becoming unnecessarily complex.

Selective depth; simplest solution; avoid over-abstraction.

Strong models may take too much initiative — before technical analysis or execution, you need to make clear what the agent can and can’t do on its own.

Without a declared limit, “evaluate this server” can turn into “I restarted the service”—an expensive surprise in production.

Explicit limits; agent initiative; separation of evaluation and execution.

"First, just assess. Don’t change files, restart services, create a branch, edit configuration, or run destructive commands. Provide a diagnosis with evidence. Then say exactly what changes you recommend and why."

Separate it into two explicit steps—evaluate, then recommend—before any real action takes place.

Evaluation without action; evidence-based diagnosis; recommendation separate from execution.

For a real security audit: request high reasoning depth only for the risk analysis (tip 3), but lock execution with “evaluate only, don’t change anything” (tip 4)—the agent thinks deeply and still won’t touch production without permission.

Unlimited depth is a risk; limits without depth lead to shallow analysis — both tips complement each other.

Depth kept in check by limits; safe auditing; think deeply without acting on your own.

Common mistakes: asking for maximum depth on every task out of habit; saying “evaluate the system” without specifying what it must not touch; confusing evaluation with authorization to execute.

Quick checklist: does the requested depth match the actual complexity? Are action limits explicit before any technical analysis?

Pre-prompt checklist; habit of maximum depth; explicit limit before analysis.

Never accept “done” without evidence—in code, automation, databases, deployments or documents, the model needs to prove what it did.

Without requiring proof, it’s easy to get a polished status report that doesn’t match what actually happened.

Real evidence; test run; verifiable log/output.

"Before saying something is done, confirm it with real evidence: a test run, changed file, log, command output, or verifiable result. If it wasn’t verified, clearly say: 'not verified.' If it failed, show the failure. If you skipped a step, say so."

Turns "I trust the answer" into "I check the evidence"—it works in any domain, not just code.

Explicitly say "not verified"; show the failure instead of hiding it; state when a step was skipped.

Instead of a single answer, analyze the same problem through several specialized lenses — strategy, product, communications, technology, and a skeptic who looks for flaws.

Good for evaluating ideas, offers, products, projects, and campaigns—the final synthesis is more robust than a one-shot analysis.

Role structure; skeptical agent; consolidation with priorities.

"Use a subagent structure: Agent 1 analyzes strategy and positioning. Agent 2 analyzes the product and user journey. Agent 3 analyzes content and communication. Agent 4 analyzes technology and automation. Agent 5 acts as a skeptic and looks for flaws. Then consolidate everything into a single recommendation, with priorities."

It’s a ready-to-use template for evaluating any complex decision across multiple dimensions at once.

5 fixed roles; one consolidated recommendation; explicit priority.

In practice, Agent 5 (the skeptic) in the subagent structure is the mechanism for real verification applied to decisions—it exists to reject an easy “done” and demand evidence before the final recommendation.

Verification isn't just for code—the skeptic role among subagents applies the same principle to product and strategy decisions.

Skeptical as a verifier; evidence before recommendations; a dedicated role for challenging assumptions.

Common mistakes: accepting “done” without asking for evidence; using only 1 perspective for a complex decision; skipping the skeptical agent because you think it will slow things down.

Quick checklist: is there concrete evidence for “done”? Was the decision reviewed from more than one perspective? Did the skeptic have a voice in the final synthesis?

Pre-acceptance checklist; multiple perspectives; skeptic’s voice in the synthesis.

The strongest use of Fable 5 isn’t getting the perfect prompt right once—it’s continuous project memory: positioning, target audience, offers, voice, mistakes to avoid, confirmed decisions, validated prompts, each in its own file.

Without memory, every session starts from scratch and repeats the same mistakes that were already fixed.

Project memory; topic-based folder structure; confirmed decision vs. hypothesis.

"Whenever we learn something important about this project, record it in memory. Format: decision or lesson; why it matters; where to apply it; what to avoid; date. Don’t duplicate information. Update the existing note when needed."

Turns memory into an automatic session habit, not a manual task that gets forgotten.

Structured record with a date; anti-duplication; update of an existing note.

For long tasks, the model may stop too early or end with a promise instead of executing — make it explicit that it should continue once it has what it needs.

Useful for code, documentation, planning, and content creation—any long task where stopping halfway means rework.

Execution instead of promises; stop only when necessary; destructive actions as an exception.

"If you already have enough information, proceed. Don’t end with a promise, plan, or generic question. Stop only if you need information that only I can provide or if the action is destructive or irreversible."

Closes the “I’ll do it later” loop that unnecessarily stalls long sessions.

Explicit stopping criterion; irreversible action as the only exception; end of “empty promises.”

Project memory is precisely the “enough information” that frees the agent to execute without pausing—the more complete the memory, the less legitimate reason the agent has to stop early.

The two tips form a cycle: well-maintained memory reduces unnecessary interruptions, and each run generates a new lesson for memory.

Memory as fuel for execution; the memory-action-lesson cycle.

Common mistakes: never recording lessons in memory; letting the agent stop out of habit from asking for confirmation; duplicating a note instead of updating the existing one.

Quick checklist: was this session’s lesson recorded? Did the agent execute or just promise? Is memory free of duplicates?

Session closeout checklist; recording vs. forgetting; duplicate note.

Assess the clarity, conversion, and impact of screens, pages, PDFs, and visual assets by sharing a screenshot or image—instead of just asking “make it look better.”

A structured visual review points out a specific, actionable problem instead of offering a vague aesthetic opinion.

Structured visual review; first impression; generating questions vs. desire.

"Analyze this screenshot or image. Compare it with the goal: helping someone quickly understand the value of the offering. Tell me: where the eye stops first; what’s confusing; what creates desire; what raises questions; what to cut; what to change to increase conversion."

Each question prompts a concrete, testable answer instead of a generic “it’s good.”

6 visual review questions; cuts vs. additions; conversion as a criterion.

In security, asking for a defensive review instead of exploration or attack avoids a blocked response and keeps the focus on protection.

How you frame the question determines whether you get real help or a refusal — even when asking about the same vulnerability.

Defensive framing; avoidable refusal; focus on protection.

"Review my server code defensively. Look for bugs, missing validation, authorization issues, accidental data exposure, configuration failures, and operational risks. Don’t create an exploit. Don’t show attack steps. Just identify the risk, affected file, likely cause, and defensive fix."

It’s literally the practical strategy for avoiding a "cyber" category refusal during a legitimate security review.

No exploit; risk + cause + fix; refusal avoided through framing.

For a product launch: use the visual review (tip 9) on the landing page/screenshot before publishing, and the defensive review (tip 10) on the backend that supports the form—cover the feature’s experience and security.

Together, the two tips cover “what the user sees” and “what protects what they don’t see”—security is never just code, and UX is never just aesthetics.

Experience review + risk review; full coverage of a feature.

Common mistakes: asking to “make it look nicer” without a conversion criterion; framing a security review as an exploit/attack request; reviewing only the screen and forgetting the backend.

Quick checklist: are all 6 visual review questions answered? Is the security review framed as defensive? Did it cover both screen and server?

Pre-publication checklist; correct framing; screen + server coverage.

"Review my app every day" is a weak loop — a good loop needs focus (a small area), criteria (based on memory), testing, and a recorded lesson from each cycle.

Repetition without criteria wastes budget and doesn't measurably improve anything; a loop with verification actually improves, cycle by cycle.

Weak vs. strong loops; focus per cycle; criterion saved in memory.

"Each cycle: 1) choose a small area of the system; 2) analyze it based on the criteria already saved in memory; 3) propose an improvement; 4) implement it only if it’s safe and reversible; 5) run a test; 6) ask the verifier to try to find an error; 7) record what you learned."

Each step in the loop has a specific purpose—skipping one (usually step 6 or 7) is the most common reason a loop fails to make progress.

7 steps of the loop; safe, reversible change; dedicated verifier.

Don’t rely only on chat history—create a file, database or supporting documentation that survives the end of the session.

Chat history disappears or gets too long to be useful; external memory is what makes weeks of work possible, not just a single session.

External memory; persistence beyond the session; supporting documentation.

Target audience, communication tone, offers, campaigns that worked, technical rules, strategic decisions, recurring mistakes, work processes, validated prompts, quality standards.

It’s the reference list for deciding what’s worth recording—it prevents empty memories or memories with too much noise.

External memory categories; recorded quality standard; documented recurring error.

Step 7 of the loop (“record the lesson learned”) is exactly where the loop feeds external memory — without external memory, the loop relearns the same thing every cycle.

The two tips close a virtuous cycle: the loop generates a lesson, external memory stores it, and the next cycle starts with a stronger criterion.

Virtuous loop-memory cycle; criteria that grow with each cycle.

Common mistakes: running a loop without a defined focus (“review everything”); skipping the verifier step; relying only on chat for work that lasts weeks.

Quick checklist: does the cycle have a small focus and a saved criterion? Did the verifier run? Was the lesson added to external memory, not just the chat?

Cycle checklist; small focus; lesson outside the chat.

The 12 tips in brief: the right task, explicit reason, calibrated depth, limits before acting, real verification, specialized subagents, project memory, continue until done, interface awareness, defensive review, verification loop, external memory.

Serves as a quick reference to review before writing any new work prompt.

Cheat sheet of the 12 tips; quick pre-prompt reference.

The complete generic prompt combines context, objective, working mode (subagents, evidence before making claims, execution instead of promises, project memory), and task—ready to paste at the start of any new project.

It’s the module’s largest code box—the condensed version of everything the track taught, ready to copy and adapt.

Master prompt; declared work mode; first next step.

Always replace: the context paragraph and the final task with details specific to your project. Always keep: the 7 items in the work mode—they’re what make the prompt work as an agent, not as a chat.

Keeps you from rewriting the prompt from scratch for every project—only the project-specific part changes.

Variable part vs. fixed part; reuse across projects.

"Fable 5’s value isn’t in giving better answers. It’s in working better. The weak way to use it is to ask for answers. The strong way is to build a system with context, memory, subagents, verification, and continuous execution. Those who use the model only as a chat tool will get better answers. Those who use it as a work system will gain a real advantage."

It’s the central thesis of track 2—all 12 previous tips are meant to move out of the chat and into the work system.

Chat vs. work system; real advantage; continuous execution.

Quick cross-reference: 2.2→1.6 and 1.3 (effort and boundaries), 2.3→1.4 and 1.7 (verification and subagents), 2.4→1.7 and 1.4 (memory and anti-overplanning), 2.5→1.6 (cyber category), 2.6→1.4 (subagent verification) — for anyone who wants to go deeper into the official/technical side of each tip.

Shows that track 2 isn’t disconnected—each practical tip has a technical/official foundation in track 1 for anyone who wants to go deeper.

Cross-reference map for path 1 × path 2; practical vs. official/technical.

Checklist combining the official techniques from track 1 (context, negative prompting, boundaries, proof of completion, concision, effort levels, subagents/memory) with the 12 practical tips from track 2, in a single cheat sheet for the entire course.

Closes the course with a single reference — you don’t need to remember which track each technique was in.

Single course checklist; ~19 techniques combined; closeout reference.