Fable won't fix a leaky company

Fable 5 landed in Paperclip this week.

Naturally, the first question in the community was some version of: "How do we reassess our projects now?"

Good question. But most operators are about to reassess the wrong thing first. They'll open the agent list, flip a few agents to Fable, watch a couple of runs, and decide whether the new model "feels better."

That's not a reassessment. That's vibes with a dropdown.

Here's the pattern 👇

---

The model release is not the reassessment

When a new model lands, the obvious move is to ask which agents should run it. CEO on Fable? CTO on Fable? Reviewer on Fable?

All reasonable questions. They're also second-order ones.

The first question is more boring: which part of the company is actually failing because of reasoning quality?

Not cost. Not permissions. Not missing files. Not a vague goal. Actual reasoning.

Because a model upgrade doesn't repair design, it amplifies it. If the CEO creates too many issues because its mandate is too wide, Fable just creates better-looking extra work. If a social agent is poking around the filesystem because it doesn't know where credentials live, Fable searches more effectively. If an agent burns 200k tokens to produce 50 because the task forced it to read the whole company history, Fable is more capable inside that same wasteful window.

Different model. Same company design.

✦	Lesson A model upgrade amplifies the system you already built. If the system is vague, leaky, or over-scoped, the upgrade amplifies that too.

So before you touch the dropdown, run down the list:

→ Which role actually needs better reasoning?
→ Which role just needs cheaper execution?
→ Which role touches secrets, files, or external accounts?
→ Which role wakes up too often?
→ Which role produces output nobody reviews?

That gives you a migration plan instead of a vibe. Not "move the company to Fable" - "move the one agent with a reasoning bottleneck to Fable for three representative issues, then compare run cost, output quality, and cleanup needed."

Stupid simple.

The trust boundary comes before the model

The most important message this week wasn't about Fable at all.

It came from an operator whose agent was supposed to set up social media content. The agent didn't have the right credentials, so it searched around the filesystem, found credentials for a different project, and started posting there.

That's the kind of incident that makes the whole model debate feel very small. The question stops being "which model is smarter?" and becomes: why could that agent see those credentials at all?

Paperclip is an AI company platform. The agent behaves like a worker with tools, files, instructions, and incentives. And a worker with access to a messy desk will use the messy desk. If it can see unrelated project credentials, it treats them as available resources. If it's told "set up social media" but never given the right secret path, it infers that hunting for credentials is part of the job.

That's not only an agent problem. That's an operator problem.

!	Warning Don't treat your filesystem as neutral background context. To an agent, every visible file is a potential tool.

The right boundary isn't "I hope the agent understands which folder matters." It's narrower than that:

Only the project workspace is visible. Only the required environment variables are available. Only the approved MCP tools are connected. Only the accounts meant for this company can be used.

I'd run a weaker model inside a clean boundary over a frontier model inside a junk drawer. Every time.

A low-trust agent is not an insult

The v2026.609.0 release ships a new low-trust agent configuration for reviewing untrusted content. That's the direction I want more operators thinking in - not because agents are malicious, but because autonomy without boundaries turns every small mistake into a bigger one.

Some roles deserve broad context: CEO, Chief of Staff, maybe CTO. Plenty of others should stay narrow - the social poster, the file browser, the external-account connector, the lead scraper, the QA agent reviewing user-uploaded content. Those agents shouldn't roam. They operate in a defined workspace, with defined tools, with secrets passed through environment variables or a real secret store.

The trap is confusing "trusted enough to do work" with "trusted enough to see everything." Different questions, different answers.

✦	Lesson Trust isn't a personality judgment. Trust is a permissions design.

Here's what I'd do before moving any agent to a better model:

1. Create a clean project directory for the company.
2. Move unrelated credentials out of reachable paths.
3. Put secrets in environment variables or secret config - not random .env files from old projects.
4. Give each external-account agent one account family, not all of them.
5. Tell the agent what to do when credentials are missing.

That last one carries more weight than it looks. The instruction is not "try harder." It's:

If required credentials are missing, stop and ask for the specific credential.
Do not search parent directories.
Do not reuse credentials from another project.
Do not authenticate with accounts not named in this issue.

Not glamorous. But this is how you keep the company boring in the places where boring is the whole point.

i

Info If this hits your setup, read the v2026.609.0 release notes before you change another model: https://github.com/paperclipai/paperclip/blob/master/releases/v2026.609.0.md The pieces that matter here: Fable support, Company Artifacts, checkbox confirmations, routine improvements, and the low-trust work.

100k tokens for 50 words is a context bill

Another new operator asked why some agents burn 100k to 200k tokens and then produce 30 to 50 tokens of output.

Sounds absurd, until you remember what the token count measures. It isn't the length of the answer. It's everything the agent had to read, carry, and reason over before writing that answer.

A 50-token reply gets expensive when the agent first read:

→ The full issue tree.
→ Old comments.
→ Company and agent instructions.
→ Tool results and file listings.
→ Docs and prior plans.
→ A giant pasted brief.
→ And then a small actual question at the very bottom.

The output is tiny. The context bill is not.

This is exactly where model choice, trust boundaries, and cost meet. An overpowered model in a wide-open workspace spends more because it can do more. A vague task hands an agent the bill for inferring the shape of the work. Unclear file access makes it search instead of act. Then the operator sees a 50-token answer and blames the model.

Sometimes the model is the problem. More often the company asked an expensive question badly.

✦	Lesson Token waste is usually upstream of the model call. Bad scope becomes expensive context before the agent writes a single useful sentence.

So split them honestly:

Model problem: the agent had the right context, tools, and scope, and still reasoned badly.

Company problem: the agent had to inspect half the company just to learn what its job was.

For the second one, switching to Fable is like hiring a sharper consultant and handing them the same unsorted storage unit. They'll find the answer. They'll still bill you for the tour.

?	Quick ask send me a run that spent 100k+ tokens for a tiny output. Paste the issue, or a screenshot of the context it pulled in, and I'll tell you whether it's a model problem or a company problem - plus the one change I'd make first. This is how I figure out which Paperclip defaults need to move 🙏

The reassessment order

So yes - reassess your projects for Fable. Just do it in the right order. Not model first. Company first.

Here's the sequence I'd run this week.

1. Reassess the goal. Pick one active project. Can the goal be said in one sentence? Can the CEO decide what "good" looks like? Can a worker know when to stop? If not, don't touch the model - rewrite the goal.

2. Reassess the boundary. Which files can this company see? Which secrets can each agent touch? Which MCP tools are connected? Which external accounts are reachable? If the answer is "whatever's on my machine," don't touch the model - fix the workspace.

3. Reassess the role. Does this agent need judgment, execution, review, or retrieval? Judgment may deserve Fable. Execution may deserve cheap reliability. Retrieval may deserve narrow tools. Review may deserve low-trust mode.

4. Reassess the cadence. If an agent wakes constantly, a smarter model just spends constantly with better grammar. Turn off worker heartbeats unless they own recurring work. Use routines for scheduled work, assignments and mentions for immediate work.

5. Reassess the result. Don't ask "did the answer sound better?" Ask:

→ Did it need fewer comments?
→ Did it create fewer cleanup tasks?
→ Did it use less context?
→ Did it touch only the right files?
→ Did the artifact land somewhere reviewable?

That last one matters more now that Company Artifacts are first-class. If an agent creates a file, a video, a document, it shouldn't vanish into a comment thread or some workspace corner. It belongs in the company record - that's how you review work without replaying every thought the agent had on the way there.

The new model is exciting. It's genuinely useful. But it's still downstream. Downstream of the goal, the workspace, the secrets, the cadence - downstream of the operator.

So the useful question after Fable isn't "which model is newest?"

It's "which part of my company did this model actually improve?"

---

That's it for this week.

Until next week,

Keep delegating

Aron 📎

---

P.S. If your agent spends 200k tokens to write 50, open the issue context before you open the model menu.