Category: Tech News

This guide explains how to build an AI agent for your business without writing code — covering how to select the right first task, and how to build the six components that turn a chatbot into an agent that runs independently.

Why most businesses are still using AI wrong

Most businesses using AI today are using it as a chatbot. You type a question, it gives an answer, you copy that answer somewhere useful and move on. Every step requires a person in the middle.

An agent works differently. It is a loop — looking at a goal, taking a step, checking what happened, then continuing until the job is done. From there, it can reach outside itself — send an email, update a spreadsheet, pull data from your CRM — without you issuing each instruction.

As of June 2026, OpenAI’s coding agents account for 64% of all tokens consumed by its enterprise customers. That is not a chatbot metric. It means the majority of enterprise AI use has already shifted from asking questions to delegating work.

Most Australian businesses are still on the asking side. As of February 2026, only 8% of Australian SMBs report using AI broadly, with 16% describing their use as limited. (Source: NAIC AI Adoption Insights, ai.gov.au, February 2026)

Triggered byA user questionAn event, schedule, or form submissionRuns whenYou ask itAutomatically, on a defined scheduleOutputA text responseA completed task or actionMemory between sessionsNonePersistent context, rules, and proceduresTool accessNoneEmail, CRM, calendar, files via MCPScopeOne question at a timeFull workflow from trigger to finished output

Feature	Chatbot	AI Agent

Step one: pick the right first task

The task you start with determines whether your first agent succeeds or stalls. Not every repetitive task is the right starting point.

Three criteria for a good first agent task

A task qualifies if it meets all three of the following.

It happens more than once a week. Low-frequency tasks are harder to train because you see fewer examples of what correct output looks like before you automate.

It has a consistent trigger. A trigger is the event that starts the task — an email arriving, a form being submitted, a scheduled time being reached. If the task starts differently every time, the agent cannot run reliably.

It produces a predictable output. A report, a notification, a data entry row, a drafted reply. If the output changes shape depending on circumstances, the agent cannot be evaluated consistently.

Monthly invoice routing qualifies. Lead qualification from inbound enquiry forms qualifies. Weekly operations summaries qualify. “Help me think through this” does not.

The businesses we work with most commonly start with one of three workflows: inbound lead triage, internal reporting, or document processing.

Build the trigger first, not the logic

Most first agents fail because the builder starts by writing instructions for what the AI should do, before locking where the task starts and where the result lands.

Define the trigger and the destination first. What event starts the task? Where does the finished output go? Once those two things are fixed, write the instructions in between. This single rule prevents the most common first-build failure.

Test before you automate

Before setting the agent to run automatically, test it on five real historical examples. Use cases that have already happened, with known correct outputs.

Four of five correct: the agent is ready to run. Three of five correct: the prompt needs work, not a different tool. Fewer than three: the task definition is too broad — narrow it first.

This test takes less than an hour and prevents an agent from running on live work before it is reliable.

How to build the agent: six rungs

Once you have the right task, build the agent in six stages. Each stage depends on the one before it. Skipping ahead is the most common reason first builds underperform.

Rung 1: Context

Before the agent can do anything useful, it needs to know your world. Not in general terms. Specifically: who your customers are, how your operation works, what you have decided and why.

Write this down in plain text. The agent reads it every time it runs. Nothing it produces is generic because it is reading your actual business before it moves.

Context compounds over time. Every time the agent works, it can write observations back to those files. You are training it on your operation, and that training belongs to you. Anyone can access the same AI model. No one can replicate the context you have built.

This is the stage most businesses skip. It is the one that determines output quality more than any other.

Rung 2: Memory

Context is what you give the agent. Memory is what it keeps from doing the actual work.

There are three kinds. The agent remembers facts about your business and customers. It remembers rules — every correction you make is saved and never broken again. And it remembers procedures — a step-by-step method for completing a specific task, owned permanently once taught.

Together, context and memory are what separate a generic AI tool from one that works the way your business works.

Rung 3: A lane, not a task

A task is a one-off instruction. “Draft this email.” Done, gone.

A lane is ongoing ownership. “You handle the inbox. Read what comes in, sort it by priority, draft replies, and flag anything that needs a human decision. Every day, without me asking.”

The moment an agent owns a lane, you stop assigning work. The work runs itself. That is the difference between a tool you operate and a worker who operates.

Rung 4: Tools

An agent with no connection to your actual systems can only describe work, not do it. Connect it to where the work lives — your email, your calendar, your CRM, your files.

For a first build, MCP (Model Context Protocol) is the simplest approach. No code required. Most common business tools can be connected in under a minute.

Once connected, the agent stops drafting emails for you to send. It sends them directly. Rather than summarising your calendar, it reads it and acts on what it finds.

Rung 5: A schedule

An agent with context, memory, a lane, and tools is still waiting for you to trigger it. A schedule removes that dependency.

Set it to run every morning, every hour, or overnight. It wakes up on its own, completes its lane, and contacts you only when a decision requires a human. You go from operating the agent to receiving its output.

This is the stage at which the work genuinely runs without you.

Rung 6: Guardrails

An agent that runs automatically, touches your real accounts, and operates while you are not watching needs boundaries set before it is let loose.

Define three things: what it is allowed to touch, what it must never touch, and which decisions require your approval before action is taken.

Low-stakes tasks it handles without checking. High-stakes decisions — a refund above a set threshold, an email to a key client, a change to a financial record — it drafts and holds for your sign-off.

You stop being the operator. You become the approver.

What this looks like in a real Australian business

A Sydney-based mortgage broking firm was managing roughly 120 active loan applications at any given time. Their admin team was spending the majority of each day on routine client communication — chasing missing documents, sending status updates at each stage of the application, and manually updating their compliance log after every client interaction.

An agent was built to own that lane. It monitored the application pipeline, identified which stage each file was at, sent the appropriate status update to the client, flagged missing documents to the relevant broker, and updated the compliance log automatically. The agent was scoped and running within two weeks. Routine client communication, which had previously consumed the majority of two staff members’ days, was reduced to a morning review of flagged exceptions.

The same business applied the same six-rung build to a second workflow the following month.

How long does it take to build a first AI agent

A first agent built with the six-rung approach typically takes one to two weeks from task selection to reliable automated output.

The first few days involve corrections as the agent learns the business context. By the end of the second week most agents are running consistently. By the end of the first month the correction rate drops significantly and the agent begins to handle edge cases it was not explicitly trained on.

A common pattern: rough on day three, reliable by day fourteen, genuinely yours by day thirty.

Building your second and third agent

Once the first agent is running, the second build is faster. Context files already exist. Tool connections are already in place, and the guardrail framework carries over too.

Each subsequent agent inherits the shared knowledge about your business and is pointed at a new lane. A team of agents running in parallel — each owning a different workflow — is how businesses move from managing tasks to managing outcomes.

The businesses seeing the strongest results from AI are not using more sophisticated tools. They are running more tasks through structured, repeatable agent workflows.

Frequently asked questions

Start building today

Not sure which task to start with? Automation Consulting works with Australian businesses to identify, scope, and build first agent workflows. Our 20 Hours Free programme covers the full build at no cost for qualifying businesses — scoping included.

In January, Judith Butterfield had a stroke and spent 2 months in Doncaster Royal Infirmary. The stroke affected the right side of her body and left her speech fragmented.

Her GP surgery had installed an AI reception service to reduce phone queues. She tried to book an appointment 5 times and did not reach a human on any attempt.

The system asked callers not to use speakerphone. Butterfield held the phone in her left hand because her right hand could no longer operate a keypad. When the system asked her to repeat her name, it did not understand her, and the call ended. She told the BBC the experience was “very difficult and upsetting.” A receptionist could have asked her to spell it.

Butterfield, 71, registered with a different practice. Her original surgery has since decommissioned the AI system and recruited more reception staff. The watchdog Healthwatch reports similar problems from other Yorkshire patients, including one case involving a regional accent.

The same failure has now played out at a bank and an airline, with the same underlying shape.

Why do AI customer service systems fail?

AI customer service systems fail for structural reasons rather than technical ones. Two documented cases show what that looks like at scale.

Commonwealth Bank: the queue that did not shrink

In July 2025, Commonwealth Bank of Australia cut 45 customer service roles, saying its new AI voice bot had reduced call volumes by around 2,000 a week. Staff reported the opposite. The Finance Sector Union said volumes were rising, overtime was being offered to cover the load, and team leaders were being pulled onto the phones. The union took the bank to the workplace relations tribunal over its call volume claims.

On 21 August 2025, CBA reversed the redundancies and apologised, saying it “did not adequately consider all relevant business considerations” and that the roles were not redundant.

The work had not disappeared. The bot absorbed the simple calls, and customers with urgent or complicated problems kept calling. Automating the easy contacts changed the composition of the queue rather than its size.

Air Canada: the company owns what the bot says

On the day his grandmother died, Jake Moffatt asked Air Canada’s chatbot about bereavement fares. It told him he could book now and claim the reduced rate within 90 days of the ticket being issued. The airline’s actual policy, on the page the chatbot linked to, does not allow refunds for travel already taken. Moffatt booked at full fare, applied, and was refused.

British Columbia’s Civil Resolution Tribunal found Air Canada liable for negligent misrepresentation and awarded Moffatt C$812.02. The airline had argued its chatbot was a separate legal entity responsible for its own actions. The tribunal rejected that. It also rejected the argument that the correct policy was available elsewhere on the site, asking why a customer should have to check one part of a company’s website against another.

That was not a defence. Whatever your AI says is what your company said.

Deflection rate conceals the problem

Most AI customer service deployments are measured on deflection rate, which is the share of enquiries resolved without a human. Judith Butterfield’s five failed calls each counted as deflected.

Deflection rate does not separate a solved problem from an abandoned one. A deployment can report 80 percent deflection while losing its most frustrated and most vulnerable customers. CBA’s case shows the same distortion one level up: the bot’s deflection figures looked like reduced demand while the queue behind it was growing.

What to measure instead: resolution rate, which is the share of enquiries actually resolved, and escalation rate, which is the share reaching a human. Also track the proportion of conversations that end without either outcome.

What do teams miss when deploying AI in customer service?

Seven failure points account for most of the damage. All seven are design decisions rather than model limitations.

1. The callers the system was not designed for

Voice AI is usually tested on clear, standard-accent speech. Real callers have regional accents, second languages, speech affected by illness or age, background noise and poor reception.

Butterfield’s case involved two assumptions at once: that her speech would be recognised, and that she could use a keypad if it was not. Neither assumption held. The people excluded by assumptions like these are often the ones with the most urgent need.

2. No route to a human

In each of the cases above, the customer could not exit the automated conversation on the terms they needed. An AI assistant that cannot answer a question should hand over on the first failure rather than rephrase the same answer.

The vendor behind the GP reception system states that practices can enable routing straight through to reception on every call. That option existed at Butterfield’s surgery and was not switched on.

3. Emotion as a routing trigger

Distress, anger, urgency, legal language and bereavement appear regularly in support queues. They are also the interactions where a wrong answer costs the most. Moffatt was asking about a bereavement fare on the day his grandmother died, which is exactly the conversation that should have reached a person. Route these on detection rather than after several failed attempts.

4. Scope set too wide

AI support deployments that work handle a small set of high-volume, well-defined requests and escalate everything else with the conversation history attached. Deployments that fail attempt every request type at once and handle all of them poorly.

CBA’s experience adds a second point. Automating the simple contacts changes the composition of what remains. Plan capacity for the queue you will have after deployment, not the one you have now.

5. No memory across the conversation

Some systems treat each message as a separate event. The customer explains the situation, answers a clarifying question, and finds by the third message that the opening has been forgotten. The same happens when a customer moves from chat to phone and has to start again.

Repeating yourself is the point at which most people stop trying. Confirm that context persists across messages and across channels before going live.

6. Answers invented from a contaminated knowledge base

An AI assistant will produce an answer even when the correct one is not available to it. Air Canada’s chatbot described a bereavement policy the airline did not have.

The usual cause is the source material. Internal notes, draft pricing, superseded policies and old support threads get loaded alongside customer-facing content, and the assistant resolves the contradictions at random.

Build a separate knowledge base containing only approved customer-facing information, and check it for contradictions before launch rather than after.

7. The assistant cannot take action

Most support requests need something done rather than something explained. A refund processed. An address changed. An appointment moved. An account unlocked.

An assistant connected only to a knowledge base can describe the process and cannot complete it, so the customer is left with instructions they cannot act on. This produces the most common complaint about AI support, which is being sent a link to a help page the customer has already read.

Decide before deployment which actions the assistant can execute in your systems, and route everything else to someone who can.

Where does AI belong in customer service?

Each failure above has the same shape. A human service existed, it was removed or hidden, and AI became the only way through. A patient needed a doctor. A grieving passenger needed a fare policy. A banking customer needed a problem fixed that the bot could not fix.

Compare that with a visitor on a website at 9pm with a question about whether a product suits their room. That visitor is not in a queue and is not being denied anything. Without an assistant they leave the site, and the business never knows they were there. The alternative to AI in that case is no response at all.

The rule: use AI to add a route, never to remove one.

An example

We built an AI consultant for a major Australian flooring retailer on the add-a-route principle. It answers product and service questions, works out what the visitor needs, and recommends suitable options with clickable links and images shown in the chat. Where relevant it prompts them to book an in-store or in-home consultation, and pre-fills part of the booking form from what the conversation has already covered.

It answers from approved product and service content, holds context so the visitor is not asked the same thing twice, and follows a defined path for each common situation rather than one general instruction set. Anything it cannot resolve goes to a person who follows up directly, which was a requirement at the start of the build rather than an addition to it.

We keep tightening it against real conversations: what visitors actually ask, and where the assistant fell short.

If you want the same approach applied to your own site or support line, we can start by mapping where your customers currently get stuck.  Start with 20 hours free: real consulting work, no cost, before you commit to anything.

Summary

Placement determines the outcome in AI customer service. An AI assistant put in front of an urgent need, with the human alternative removed and success measured by how few callers reach a person, will eventually reproduce Butterfield’s five phone calls or CBA’s reversal.

An AI assistant that opens a route which was previously closed, with a person one step away, handles enquiries that would otherwise go unanswered.

Frequently asked questions

Leading companies are already seeing close to $3 back for every $1 they put into AI, according to data from McKinsey. The strongest returns aren’t coming from broad “let’s use AI everywhere” experiments. They’re coming from focused workflow automation aimed at one process at a time. Morgan Stanley‘s own tracking found the number of S&P 500 companies reporting measurable AI impact nearly doubled in a single year.

This post covers three things: what AI workflow automation actually is, what it’s already done for businesses across different industries, and what it actually costs.

What is AI workflow automation, really?

Simply explain:

Traditional automation (including most of what you’d call RPA)	AI workflow automation
follows a fixed rule. If a form field says “urgent,” route it to the urgent queue. It’s fast, it’s reliable, and it breaks the moment the input looks even slightly different from what the rule expected.	reads the input, not just the label, and decides. It can look at an unstructured email, a scanned invoice, or a customer message with no fixed format, understand what’s actually being asked, and take the appropriate next step, without someone having pre-written a rule for that exact case.

Ask where the process currently needs a person to read something and decide, rather than just tick a box. That’s the exact seam where AI-driven process automation earns its cost over a simple rule.

And no, it’s not the same as “someone on the team uses ChatGPT.” That’s real value, but it’s one person, one task, no memory between sessions, and nothing connected to your other systems. AI workflow automation is the same underlying capability wired into an actual process – triggered automatically, connected to your tools, running whether or not someone remembers to open a chat window.

Where AI actually fits: a framework for process automation

The single most common mistake isn’t picking the wrong AI tool. It’s picking AI for a task that never needed it, or under-building a task that genuinely does. Match the task to the category first:

If the task is…	You need…	What that looks like
The same steps, every time, no judgment calls	Basic automation (no AI needed)	Zapier, Make, or your existing platform’s built-in automation rules
Reading and judging unstructured input (emails, tickets, documents, call notes)	An AI agent	Automated lead scoring, ticket triage, document data extraction
Producing new content or messaging, not reacting to input	A generative AI workflow	Drafting first-pass reports, personalising outreach at scale, summarising long documents
Predicting what’s likely to happen next, based on historical patterns	A predictive model	Demand forecasting, churn prediction, budget forecasting
Spanning multiple systems and approval steps	A custom AI workflow build	Bespoke integration connecting your CRM, inbox, and finance tools with an agent making the calls in between
Real-time, high-stakes decisioning at volume	An advanced custom system	Purpose-built model for fraud detection, dynamic pricing, or similar

Most real workflows are hybrids, not one pure type. Invoice processing, for instance, is usually rule-based matching plus AI judgment on the exceptions that don’t match cleanly. It’s normal for one process to need two or three of the above working together.

Use cases: where AI workflow automation already pays off

A straight look at what this looks like in practice across business functions, so you can see where your own bottleneck might fit:

Business Function	What this looks like in practice	What the data shows
Customer service	From Automation Consulting’s own work: an AI consultant built for a major Australian flooring retailer answers product questions and recommends products with images and clickable links right in the chat, turning website visitors into booked quotes	10.86% conversion to quote; significant increase in leads
Finance & invoicing	Invoices are read, matched against purchase orders, and flagged automatically when something doesn’t line up	Processing time cut from 17.9 days to 3.4 days; 40–80% lower cost per invoice
Demand & inventory forecasting	Historical sales, seasonality, and market signals feed a model that predicts what stock levels will actually be needed	Cuts overstock costs by roughly 18% for mid-sized distributors
HR & recruitment	Resume screening, interview scheduling, and candidate FAQs are handled automatically, with a human still making the final call on who gets hired	Up to 50% faster time-to-hire and 75% of candidate communications automated; Nestlé has publicly reported saving roughly 8,000 admin hours a month this way
IT & internal support	Routine Level 1 tickets – password resets, access requests, standard troubleshooting – are triaged and resolved by an AI agent before they ever reach a person	Median resolution time of 4.4 hours with AI automation versus 71 hours without, measured across 50,000+ real tickets from 30+ organisations
Manufacturing & operations	Digital tooling, process redesign, and workforce retraining rolled out together across a plant’s operations	15–25% operational EBITDA improvement
Real-time fraud detection	Transactions are scored for risk in real time as they happen, instead of a fixed rule flagging anything over a dollar threshold	42% of card issuers and 26% of acquirers saved more than $5 million in fraud attempts over two years

These are seven functions where the pattern is well-documented, not the limit of where it applies. The same logic extends to any process where someone is currently reading, judging, or deciding by hand: procurement approvals, compliance checks, contract review, logistics scheduling. If you’re not sure whether your own bottleneck fits, that’s exactly the kind of thing we scope in a 20-hour free build – real work on your actual process, not a generic demo.

Where this leaves Australian businesses

The National AI Centre‘s most rigorous ongoing tracker puts SME AI adoption at 44% as of February 2026, other surveys range as low as 29% and as high as 84%, depending on how loosely “using AI” gets defined. Adoption and capability aren’t the same thing. Most of that 44% is someone using a chatbot occasionally, not a working system.

The more telling number sits inside that 44%: broad adoption, where AI is embedded across multiple parts of a business rather than one isolated task, just hit its highest level in seven months. Businesses that commit tend to expand their use rather than pull back. The real gap isn’t people trying AI and giving up. It’s the majority who haven’t started at all.

What’s actually stopping most Australian businesses from adopting AI workflow automation?

• Trust, by far the biggest one: Around 65% of non-adopting businesses cite distrust in AI decision-making or a preference to keep humans fully in control. This shows up the same way across business sizes and industries – it’s not a small-business-specific hesitation.
• Relevance – and this is the most fixable one: 54% of non-adopters say AI simply isn’t relevant to their business. The gap is stark by industry: fewer than 30% adoption in construction and agriculture, versus more than half of businesses already using AI in health, education, and services. That’s not a capability gap. It’s a lack of visible examples of what this looks like for a business like theirs – which is exactly the gap the use-case table above is meant to close.
• Not knowing where to start: 19% of SMEs say they don’t know how to apply AI to their business at all, up from the previous quarter. This group isn’t resistant, just without a clear entry point – which is a different problem to solve than trust or relevance, and usually the easiest one.
• Lack of in-house expertise: Some businesses just don’t have anyone on staff who knows how to evaluate a solution or a vendor.

Deloitte’s research on Australian AI adopters found something worth sitting with: SMEs that implement AI report productivity gains of 25–35%, notably higher than the 15–20% large enterprises report. In a smaller business, automating even one workflow lands harder – with fewer people wearing more hats, every hour saved is felt directly rather than absorbed into a large org chart.

Put together: the barrier isn’t that automation doesn’t work for smaller Australian businesses. It’s that most don’t have anyone in-house who knows where to start.

The number that makes moving now worth it: MYOB’s data shows AI-adopting SMEs are growing 2.8 times faster than the ones that aren’t. That gap is already showing up in revenue, not just survey answers.

If you want a clear-eyed read on where your own business sits, start with 20 hours free — real consulting work, no cost, before you commit to anything.

Common questions

Quick answer: Before any AI automation goes live, business owners should ask six questions: what systems does it connect to, what can it change, does it need internet access and for what, what happens if it makes a mistake overnight, is there a log of what it did, and when will its access be reviewed. Developers and vibe coders should run nine checks covering dedicated credentials, OAuth scope, network allowlisting, filesystem access, credential hygiene, blast radius, rollback capability, logging, and access review dates.

Over the past few weeks, AI security has been impossible to ignore.

Two incidents. One root cause.

OpenAI disclosed that two of its models broke out of a sandboxed testing environment, found their way to the internet, and independently identified and breached Hugging Face, carrying out more than 17,000 actions over several days. The Hugging Face CEO described it as “very weird and unprecedented.” OpenAI then found additional escapes when it investigated further.

Anthropic separately disclosed that its own model had gained unauthorised access to outside organisations in three different security evaluations conducted between April and July.

Both companies admitted the same underlying problem. Not that the AI was too capable. That the environments gave it more access than the task required, and neither company applied monitoring correctly.

Engineers made configuration mistakes. The AI did what it was built to do. Nobody was watching closely enough.

This is not a problem unique to AI research labs. Every business deploying a workflow automation makes the same decisions: what to connect it to, what it can do, and whether anyone is checking what it did. At Automation Consulting, we scope every automation we build for clients across retail, fintech, professional services, and real estate against these questions. These are the questions worth asking before your next one goes live.

If you are a business owner

Two AI security incidents made headlines this week. In both cases, the root cause was the same: the AI had access to more than the task required.

Most businesses will never face anything at that scale. But the question both incidents raise applies equally to a small business deploying a customer follow-up automation as it does to OpenAI running a security benchmark.

If you do not have a technical background, these questions are the ones to put to your tech partner before any automation goes live. You do not need to understand every answer in detail. You need to know that your partner can answer them clearly, and that the answers are in writing.

What systems does this connect to?

Every system the automation touches is a potential failure point if something goes wrong.

Ask your tech partner to list every integration by name: your CRM, email, file storage, accounting software, any external APIs. If they cannot give you a complete list, that is the first thing to fix before anything else.

What can it change, not just read?

Reading data is low risk. Writing, updating, deleting, or sending is where mistakes become expensive.

An automation that monitors your inbox is very different from one that replies to it. Ask your tech partner to separate read actions from write actions. If the automation can send emails, update records, or delete files, that list needs to be explicit. “It handles customer communications” is not sufficient. “It reads enquiry emails and creates a CRM record, it cannot send anything” is.

Does it need internet access? For what, specifically?

An automation that works entirely within your own systems has no reason to call external services. If it does need internet access, there should be a specific list of services it is permitted to call.

“It needs to reach the internet” is not an answer. “It calls the SendGrid API to send confirmation emails, and nothing else” is. If your tech partner cannot tell you exactly which external services the automation contacts, resolve that before deployment.

If it runs overnight and makes a mistake, what does it touch?

Automations often run without anyone watching. The question is not whether mistakes can happen, they can. The question is whether a mistake at 2am affects one record or ten thousand, and whether it can be reversed.

Ask: what is the worst realistic outcome of a bug in this automation? Can it be undone? If the answer is “it would update every contact in our database and we would not be able to reverse it,” that automation needs a human approval step before the irreversible action runs.

Can I see what it did?

If something goes wrong, you need to be able to look back and see exactly what the automation did, when, and to what.

There should be a log. Check how long it is kept and who can access it. If your tech partner cannot show you a record of what the automation did yesterday, that needs to change before it runs unsupervised in production.

When will its access be reviewed?

Automations outlive the problems they were built to solve. The access granted on day one may be more than is needed on day 365, because the workflow changed, the business changed, or the integration was only ever temporary.

Before sign-off, agree on a review date. Six months is a reasonable starting point. Put it in the project documentation, not just in someone’s memory.

What a good answer looks like

A tech partner who takes these questions seriously will give you specific, plain-language answers. They will be able to tell you exactly which systems are connected, exactly which actions the automation can take, and exactly what a mistake would look like in practice.

Vague answers, “it is all contained,” “that is handled on our end,” “do not worry, it is safe,” are not answers. They are reasons to ask again.

The goal is not to distrust your tech partner. It is to make sure that both of you are looking at the same thing before it goes live.

If you are building it yourself — developers and vibe coders

You have built something that works. Before it goes live, or before you hand it credentials and walk away, run through this list.

Most of these take under five minutes each. Together, they define the difference between an automation that fails cleanly and one that does real damage at 3am. This is not a guide for security engineers. It is for developers who built something fast, and for anyone building through vibe coding and AI-assisted development, who want to check it is scoped correctly before it touches production data.

Use a dedicated credential for this automation

Do not connect your automation using your personal login or a master API key. Create a service account or generate an API key specifically for this integration.

If the automation is ever compromised, or if you simply want to revoke access, you should be able to cut off that one credential without touching anything else. An automation connected under your personal account means revoking it disconnects you from everything else that account touches.

Check the permission scope before you connect

Most OAuth flows and API configurations let you restrict what an integration can actually do. Before you connect any service, check what permissions you are granting.

If your automation reads invoices, it needs read access to invoices, not admin rights to the whole account. Most developers accept the default scope without checking. The default scope is almost always broader than necessary. Check it, then reduce it.

If it needs internet access, define what it is allowed to call

An automation that calls one external API has no reason to make arbitrary outbound requests.

In n8n, Zapier, or any cloud platform, check what the workflow can actually reach. For self-hosted builds, consider an egress allowlist, a short list of specific domains it is permitted to call, with everything else blocked by default. If you cannot do that at the network level, at least document which services it is supposed to call so you have a baseline to compare against if something unexpected shows up in the logs.

For AI coding agents: restrict filesystem access to the project folder

If you are using an AI coding agent (Cursor, Claude Code, Copilot Workspace, or similar), configure it to operate only within the project directory before you start the session.

It should not have access to your home folder, your .env files, your SSH keys, or anything outside the project scope. Most tools have a setting for this. The default is often everything the current user can reach. That is not the setting you want.

Never put real credentials in a prompt

If your AI coding tool needs an API key to generate working code, use a placeholder in the prompt and inject the real value from your environment at runtime.

Prompts may be logged by the tool, by the platform, or by infrastructure you do not control. Anyone with log access can recover credentials stored in prompts. Use environment variables. Always.

Define the blast radius before you give it write access

Before any automation gets write access anywhere, ask: if this runs with a bug, what does it affect?

A single record, or all of them? One email, or ten thousand? A single file, or the entire directory? If the blast radius is large, add a human approval step before the irreversible action fires. The cost of one extra click is always lower than the cost of the cleanup.

Confirm you can roll back

For any automation that writes to a database, modifies files, or sends external communications: confirm you have a way to undo it before you deploy.

A backup is not enough on its own. You need to know which specific records were changed, when, and to what previous state. If you cannot answer that question, either add change logging before you deploy or restrict the automation to read-only until you can.

Build logging in from the start

Every production automation should write a log: what it did, when, what it changed, and whether it succeeded or failed.

In n8n this is largely automatic. In custom builds, you need to add it deliberately. Knowing what your systems are actually doing is the foundation of safe automation. Retrofitting logging after something has gone wrong is significantly harder, and you will always wish you had it. If you are building fast, logging is the one thing worth slowing down for.

Set a review date before you deploy

When you deploy, put a calendar reminder for six months out to review what the automation still has access to, and whether it still needs it.

Access accumulates. A workflow that connected to three services at launch often connects to six a year later. Permissions granted for a temporary task stay in place permanently unless someone explicitly removes them. A scheduled review is the cheapest governance mechanism available and almost nobody does it.

If someone non-technical asks whether your automation is safe, the honest answer has three parts: what it can read, what it can change, and what happens if it makes a mistake. Clear plain-language answers to all three usually means your scope is correct. If you hesitate on any of them, go back through this list before you hand it to production.

What both lists have in common

The incidents at OpenAI and Anthropic did not result from AI that was too intelligent or too autonomous. In both cases, the environments gave the AI more access than the task required, and the teams had not applied monitoring to the right scenario.

The same risks apply at any scale. The question is not whether to trust AI. It is whether your setup gives it only what it needs to do its job, and whether you would know if something went wrong.

These are the questions we ask before every automation we build for clients. They take less than an hour to work through. They are worth doing before the next one goes live.

Frequently asked questions

Claude Fable 5 returned on July 1, after the US government’s export-control directive pulled it offline for 19 days. It came back free on Pro, Max, and Team plans through July 19, and only up to 50% of your weekly usage. After that, it’s usage credits or nothing.

We covered what Fable 5 actually is when it first launched, and what the ban itself signalled for Australian businesses. This post is the practical follow-up: what can Claude Fable 5 actually do, and what’s worth building with it.

What Can Claude Fable 5 Actually Do?

Short version: it’s not a better chatbot. Claude Fable 5 is built to run for hours on one hard problem — deep coding, long documents, multi-step planning — and check its own work as it goes.

That’s not marketing language. It shows up in what people have actually shipped with it:

• Stripe used it to migrate a 50-million-line Ruby codebase in a single day — a job their own team estimated would take two months by hand.
• A game studio rebuilding HermesWorld (a live MMO) had Fable 5 find and fix six bugs in one afternoon that had accumulated over a month of work with Opus 4.8.

I'm having Claude Fable 5 redo HermesWorld 🚨

Spent the last month designing, building & prototyping HermesWorld with Opus 4.8 — a live MMO where humans and AI agents play together.

Fable 5 just found and fixed 6 bugs in one afternoon that took weeks to accumulate.

The game is… pic.twitter.com/M2LNB5fdRh

— Eric ⚡️ Building… (@outsource_) June 9, 2026

• Wharton professor Ethan Mollick gave it one shader prompt — an infinite gothic city drowned in stormy waves — then just said “make it better.” No spec, no follow-up detail. It nailed the aesthetic call on its own.

Fable: "create a visually interesting shader that can run in twigl-dot-app make it like an infinite city of neo-gothic towers partially drowned in a stormy ocean with large waves." "Make it better"

All of this is procedurally generated. https://t.co/rYai1s4yv2 pic.twitter.com/ky0q5ho643

— Ethan Mollick (@emollick) June 9, 2026

That’s the pattern worth noticing: the more open-ended and multi-step the task, the bigger the gap between Fable 5 and everything else.

Claude Fable 5 Use Cases Worth Trying

If you’re deciding what to actually run through it, these are the categories worth your usage cap:

A real audit of something you already shipped

Multiple users are pointing Claude Fable 5 at products they’ve been running for months and asking it to find what’s actually wrong. It spins up several agents, runs the full test suite, and catches bugs that Opus and GPT had already missed. In one case, it found a sign-out edge case that could leak one user’s data into another user’s account. That’s exactly the kind of quiet, expensive bug most teams don’t find until a customer does.

Fable 5 will hand you the list. Acting on it is the harder half, and that’s usually where it stalls — the findings sit in a doc because nobody owns the fix. If an audit turns up things you’d rather not sit on, that’s the work we do as an independent IT consulting engagement: review what’s actually there, then cost the fixes in the order they’ll pay you back.

A UI or UX pass with a real brief

If you want to see what Fable 5 is actually capable of, give it more to work with: your brand guidelines, a screenshot, a clear scope of what “done” looks like. That’s where the gap between a nice refresh and a genuinely sharp one shows up.

Comment
byu/No_Rip_7664 from discussion
inClaudeAI

Comment
byu/No_Rip_7664 from discussion
inClaudeAI

A plan another model executes

Fable 5’s edge is judgment, not typing speed. The highest-leverage pattern we’re seeing: have it draft the detailed plan — architecture, decisions, risks, open questions — then hand execution to Opus 4.8 or Sonnet. You get the reasoning without paying premium rates for the boilerplate.

Something that outlasts the model

Use Fable 5 to build things that keep paying off after the window closes: documented workflows, a cleaned-up prompt library, custom instructions in a Claude Project. It’s genuinely better at judging what’s worth documenting — spotting the patterns that repeat, catching edge cases a first draft misses, writing instructions clear enough for a cheaper model to follow later. Think of it as paying a senior person to write the manual once. Most people skip this one. It’s also the one with the real compounding return.

That’s also the difference between a clever prompt and a system you can rely on. Documented, running without you, still earning in twelve months — that’s what process automation actually is, and it’s the step most teams never reach because the day job wins.

What to Build With Claude Fable 5 If You Run a Business?

Translate the above into what it looks like on a Tuesday:

Marketing teams	Feed it your last quarter of campaign data, competitor positioning, and performance numbers, and ask for a single interactive dashboard you can actually review. The version that rebuilds itself every morning instead of being re-made by hand is reporting automation.
Sales teams	Hand it your call notes, CRM export, and lost-deal reasons from the last quarter and ask it to find the actual pattern in why deals stall — not a generic “improve your pitch” answer.
Operations	Point it at a workflow that’s always been “good enough” and ask it to find where it actually breaks under edge cases, not where it looks fine on a demo. What it finds is your shortlist for modernising the systems around it.
QA teams	Run the audit prompt across a whole product. It holds context long enough to catch issues that only show up when several parts interact.
Developers	Use it for the migration or refactor you’ve been putting off because it touches too many files to safely do by hand.

Automation Workflow Ideas Worth Stealing

This is the part that matters most if you’re trying to optimise workflows, break through a plateau, or solve a real bottleneck. Here are a few patterns we’ve seen from the community, translated into what they’d actually look like inside a real operation:

A session-memory skill, so nothing gets re-explained by Hans van Gent

He built /reflect — a skill that runs a three-phase review at the end of every Claude Code session, pulls out the durable facts and corrections, and writes them back into his config so the next session starts smarter instead of from zero.

=> Business translation: after every client call, audit, or campaign review, have Claude write back what changed into a shared brief — so the next person (or the next session) isn’t starting cold. Something like:

Summarise the decisions made and corrections given this session. Append anything worth treating as a standing rule to [shared doc]

You don’t need to build anything custom for this. It’s a standing instruction you type once — “at the end of every conversation, add a summary of what we decided to this document” — and Claude just does it from then on. No code, no developer required.

Overnight batch runs on your audit backlog by Christopher Duffy

He handed Fable 9 separate workstreams in a single evening — a knowledge-base audit, a CRM rebuild, and updates across dozens of his own skills — and it held all 9 without dropping the thread.

=> Business translation: most teams have a backlog of “should really get to this” audits — SEO, ad account structure, content, a competitor scan. Queue them as separate briefs and run them overnight instead of spacing them across a month of Tuesdays.

Automating the tool that has no API by Daniel

He needed to publish articles to Medium, which offers no public API. Fable 5 handled it anyway, via a Chrome extension running locally, driving the actual publish flow end to end.

=> Business translation: if a supplier portal, a legacy POS, or an old internal tool has no API, this is the workaround — Fable 5 (through Claude Code with browser tools) can watch the manual steps once and replicate them going forward. It’s the same trick behind pulling analytics out of platforms that were never built to share data.

You show it what you’d normally click through by hand, once, and it figures out how to repeat that on its own. This is more of a “get your IT person or us involved for an afternoon” task than something you’d DIY — but it’s worth knowing it’s possible before you assume a tool’s limitations are permanent.

Worth drawing the line, though. Browser automation is the right answer when there’s no API and the job is small. When the tool sits close enough to the money that a fragile workaround will eventually cost you an order, the fix isn’t a smarter script — it’s connecting the systems properly so the data moves without anyone clicking.

A standing assessment system instead of ad-hoc judgement calls by Rich Carr

He fed Fable 5 a multi-phase scope and had it hold that as the running spec, turning raw field data into scored records against a consistent rubric — with every correction becoming a standing rule rather than a one-off fix.

=> Business translation: this is a lead-scoring or supplier-scoring system that applies the same rubric every time, instead of whoever’s reviewing it that week making a slightly different call. No custom software needed — just write your rubric in plain English, hand over your raw data (a spreadsheet, form responses, call notes), and ask Claude to score every entry against it consistently. The consistency is the win, not the technology.

Support ticket root-cause mining

Point it at three to six months of support tickets and ask it to find the actual recurring cause behind your top complaint categories. Then ask it to draft the fix — a macro, a process change, a product tweak — for each one. Run it every 3-6 months and you’ve got a running record of what’s actually improving, what keeps resurfacing, and where the next bottleneck is quietly forming. Fable 5 earns its premium when you want it to run multiple passes on its own — cluster the patterns, then re-check each cluster against the raw tickets, then draft fixes — without its own categorisation drifting along the way.

Once you know the three issues generating a third of your tickets, the next move is stopping them reaching a person at all. That’s the job AI customer service does well — the repeat questions answered instantly, day or night, and everything else routed to someone who can actually help.

How to Use Claude Fable 5 Without Burning Your Whole Week

Two things worth knowing before you point it at anything important:

It burns usage fast: Anthropic itself calls it token-intensive by design, and multiple users have reported blowing through a meaningful chunk of a weekly cap in a single ambitious session. Scope the task before you start, not after.

The new safety classifiers are still over-tuned: Fable 5 automatically hands certain requests to Opus 4.8 when its filters trigger — cybersecurity, biology, chemistry-adjacent topics mostly. Anthropic says this affects under 5% of sessions; some users report it firing on ordinary technical work too. If a routine request suddenly feels different, that’s likely why — rephrase rather than argue with it.

Scoping the work before you start is most of the skill here, and it’s the same skill whether the job goes to a model or a person. If you’d rather not spend a week’s usage cap learning that the hard way, tell us what’s slowing you down — we’ll pinpoint the fastest-payback quick wins, and tell you honestly which of them need a model this expensive and which don’t.

Anthropic’s most capable model to date, Claude Fable 5 launched June 2026. Unlike previous releases, it’s designed to handle long, autonomous work without hand-holding – think multi-hour tasks, not just better chat.

Every few months, a new AI model drops and the internet goes into a frenzy. Usually it’s developers sharing things that are genuinely impressive but hard to connect to the reality of running a business or managing a team.

Right now that model is Claude Fable 5, and the hype is real. But so is the confusion.

So rather than tell you it’s the best thing ever, we want to share what we’re actually thinking about it – the opportunities, the complications, and what might be worth doing right now if you’re a manager or decision-maker who uses Claude in any part of your work.

What actually just happened?

Anthropic released two models simultaneously: Claude Fable 5 (available to everyone) and Claude Mythos 5 (restricted to select government and security partners through a program called Project Glasswing).

Here’s the thing most articles skip over: they’re the same underlying model. The only real difference is which restrictions are active. Fable 5 is Mythos 5 with safety guardrails on. Mythos 5 is for vetted institutions where some of those guardrails are lifted.

Where does Fable 5 sit in the lineup? Think of it as a new tier sitting above Opus. The Claude hierarchy now runs Haiku → Sonnet → Opus → Fable. Fable is the new ceiling for regular business users.

What does that actually mean in practice?

Less “slightly better at writing emails” and more “can handle a complex, multi-step project autonomously for hours — and check its own work along the way.” Stripe reportedly used it to complete a codebase migration in a single day that their team estimated would take two months by hand. An independent developer built and shipped an entire software library release in one day — work he estimated would normally take several days.

That’s not a marginal improvement. That’s a different category of usefulness – for the right kind of work. More on that below.

What Claude Fable 5 actually costs

This is the part that decides whether Fable 5 is worth it for your team.

Fable 5 isn’t included in every Claude plan the way Opus is. On Max plans, and on premium seats on Team and Enterprise plans, it’s a standard part of the plan – you can put up to half your weekly usage limit through Fable 5 at no extra cost. On Pro plans, and on standard Team and Enterprise seats, it isn’t included in your plan’s limits at all: it runs on pay-as-you-go usage credits you buy on top of your subscription. Through the API it’s billed at standard rates – $10 per million input tokens and $50 per million output tokens, roughly double what Opus costs.

The practical read: test before you budget. Run a narrow slice of your team’s real work through Fable 5 and see whether the output is genuinely better before you either hand over half a weekly usage limit or start buying credits. For most teams the honest answer will be that it earns its price on a handful of jobs and is overkill for the rest.

One thing worth noting on usage speed: Early users have reported Fable 5 burns through usage limits faster than previous models. This is something we’ve seen with every major Claude release – more capable models are more compute-intensive, which means they use more of your allocated usage per task. It does make sense given how much more reasoning the model does. Anthropic has signalled they’re working to improve this over time, but for now it’s worth factoring in if you’re on a plan with a weekly usage cap.

The part that might actually frustrate your team

This is something Anthropic is transparent about, but worth explaining clearly because it affects day-to-day usability.

Fable 5 doesn’t always respond as Fable 5.

Because the underlying model is exceptionally capable in areas like cybersecurity and biological research, every request runs through a layer of safety classifiers. When a request touches certain topics — cybersecurity, biology, chemistry — the system automatically routes the query to Opus 4.8 instead. You get told this is happening, but you can’t override it.

Even though Anthropic says this affects fewer than 5% of sessions on average, early user reports in the first 48 hours included some surprising examples – prompts about pulled pork shopping lists, basic biology questions, and even asking about the filters themselves apparently triggered a downgrade to Opus. That said, Anthropic designed the classifiers to be deliberately over-tuned at launch, with plans to reduce false positives over time

There’s one piece of good news here: you won’t be charged Fable prices for requests that get rerouted to Opus 4.8. So at least the fallback won’t cost you extra.

Where Fable 5 is actually worth it?

Fable 5’s edge isn’t in short, single-turn tasks. If your team is using Claude to draft emails, summarise documents, or answer quick questions, Opus 4.8 handles those perfectly well. The premium isn’t worth it for that.

Where Fable 5 is genuinely different: work that runs long, requires holding a lot of context, involves checking its own outputs, or needs to coordinate across multiple steps without hand-holding.

Anthropic describes it as built for “days-long, complex, and asynchronous tasks previous models couldn’t sustain” – running in agent harnesses, planning across stages, delegating to sub-agents, and checking its own work. That’s the real differentiator.

Here’s how that shows up across different roles:

Marketing managers and brand teams

Running a full campaign brief that requires synthesising customer research, competitive analysis, and performance data from multiple sources, then producing a structured, reviewable output in a single session. Fable 5 can carry start to finish while flagging its own uncertainties along the way.

Finance and operations leaders

Working through multi-stage scenario analysis where each step informs the next – reasoning through the implications, checking internal consistency, and producing a board-ready output. Early testing found it scored highest of any model on Hebbia’s Finance Benchmark for senior-level reasoning, with double-digit gains in document reasoning, chart and table interpretation.

Legal and compliance teams

Reviewing a stack of contracts or regulatory documents and producing a structured risk summary – reasoning about what it means and flagging inconsistencies across documents. In blind review, lawyers found its redlines matched or beat their existing model every time.

Project and operations managers

Handing off a complex brief – say, restructuring a supplier agreement or building an operational process document – and getting back a draft that’s genuinely ready to review rather than a starting point that needs significant rework. The model proactively fills in gaps rather than stopping to ask about them.

Retail and ecommerce teams

Post-campaign analysis that requires pulling together performance data, customer feedback signals, and market context then producing a clear “what worked, what didn’t, what next” synthesis. Particularly useful where the analysis needs to span multiple channels and data types in one coherent output.

Property and infrastructure teams

Tender or proposal preparation that requires synthesising project specs, compliance requirements, cost estimates, and precedent documents into a structured submission-ready document. The model’s ability to maintain coherence across a long, multi-part document is where the upgrade shows up.

The common thread: the more moving parts, the longer the task needs to run, and the more the output needs to be self-consistent — the more Fable 5’s improvements actually matter.

In most of those examples the model is the easy part. The value shows up when it’s wired into the systems the work already lives in – the CRM, the ERP, the document store – so the output lands where someone can act on it. That wiring is the workflow automation work we do every week.

The bigger shift worth watching

Something worth naming beyond just this model release.

For the first time, a frontier AI capability has been formally split into two versions – a public version with restrictions, and a restricted version for trusted institutions. Governments, approved security firms, and select research organisations have access to capabilities that are deliberately unavailable to everyone else.

This might be the right call. The arguments for it are serious and worth respecting. But it does mean AI advantage is starting to become partly a function of your relationship with the AI provider, not just your willingness to pay or your technical capability.

For most businesses today, this is background context. But it’s a pattern worth watching.

What to actually do about it?

Run your real workflows, not demo prompts. Pick the 10-20 tasks your team actually does in Claude every week and run them through Fable 5. Note what’s better, what falls back to Opus, and form a real view before committing. If picking those 10-20 tasks is itself the hard part, that’s a process-mapping exercise more than an AI one, and it’s where our process automation consulting work usually starts.

The model is genuinely impressive for the right kind of work. The rollout has some real rough edges. And there’s more to figure out about how businesses will actually use it once the dust settles.

We’re still working through that ourselves. If you’re doing the same, we’d be happy to think through it with you – we spend our days turning this kind of capability into systems that actually move revenue, and we’ll happily start with 20 hours of free work on a workflow you pick.

Common questions

Why the tool is rarely the problem

When a business reporting system is slow or inaccurate, the instinct is to look at the software. A better dashboard. A faster query engine. Or a new vendor.

In most cases, the tool is not where the failure happens.

Most reporting systems require a business user to convert a question into a structured request. That request is then passed to someone with technical access. From there, a report is built and interpreted before an answer comes back. That sequence is the translation layer. Every step introduces delay. Every step is a place the original question gets distorted.

By the time an answer lands, the decision it was meant to inform may already have been made. Or the context has changed.

The four steps where business reporting breaks down

The question step

A business user has a question but cannot query the data directly. The question gets written down, described in a meeting, or sent via email. As a result, precision starts eroding immediately.

The request step

A data analyst interprets the question and translates it into a query. However, their interpretation is not always what was meant.

The build step

A report is built against the query. This takes time. In many organisations, it spans days. The business user cannot see work in progress or course-correct.

The interpretation step

Once the report lands, if the answer is unexpected, it is not clear whether the data is wrong or the assumption was. As a result, a second round of requests begins.

No faster or more expensive BI tool addresses these failure points. Only removing the translation layer does.

What removing the translation layer looks like

Agentic AI applied to business reporting replaces the translation layer with direct, natural language access to data. A business user asks a question in plain English. The system queries the relevant data, runs the analysis, and returns an answer without a human intermediary at any step.

Tradeshift, an accounts payable and e-invoicing platform, replaced its in-house BI tool with an agentic AI system. Query response times improved by up to 30 times. Total cost of ownership fell by 40 per cent. Their analytics function, previously a cost centre, became a revenue-generating product.

The outcome was not a better dashboard. Instead, it was the elimination of the queue. The result is real-time analytics and reporting that scales without adding analyst headcount.

What this looks like across industries

The translation layer shows up differently depending on the business, but the structural failure is the same.

Retail and ecommerce

The data questions a retail or ecommerce team asks are operational, not analytical. Sell-through rates, stock levels by location, margin by SKU, return rates on last week’s promotion. These are not questions that can wait three days. They have trade windows. A markdown call made on Tuesday about stock that should have moved on Saturday is a missed margin recovery. A reorder trigger that fires a week after sell-through data was available is a stockout. Most retail businesses are making these decisions on instinct, or on data that no longer reflects current conditions, and they have blamed their BI tool for it. The tool is not the problem.

Banking and fintech

In financial services, the cost of the translation layer is higher than elsewhere. A risk team wanting to know current portfolio exposure is not limited by its dashboard. It is limited by the time it takes a data analyst to build a query against last night’s data. A compliance team that needs a transaction anomaly report to meet a regulatory deadline is waiting on a queue, not a tool. In fintech specifically, the problem compounds: fraud patterns change, customer behaviour shifts, and a reporting stack that requires a three-day translation cycle cannot surface signals quickly enough for them to be acted on. Reporting that lands 48 hours after a question was asked is not slow. In this context, it is structurally useless.

Real estate

Property management and real estate businesses sit on significant operational data: vacancy rates, lease expiry schedules, maintenance costs by asset, rental yield by location. The problem is not a shortage of data. Rather, it is access to it. A portfolio manager wanting to know which properties have leases expiring in the next 90 days, and what comparable market rents look like, will typically wait two to three days for an answer. By the time the report lands, renewal conversations may already have started without the market rate data. The translation layer does not just slow the answer. Instead, it means the decision is made without the information that existed to support it.

Professional services

Consulting, accounting, legal, and engineering firms run on utilisation, margin, and pipeline. A principal wanting to know current utilisation across a division, or whether a specific engagement is tracking to budget, typically waits until the next weekly finance review. The resourcing decision it was meant to inform needed to be made mid-week. It arrived on Friday. The firm may have a practice management platform, a project accounting system, and a BI tool. None of those investments address the translation layer, because the layer exists in the process, not the software. However, hiring another analyst increases capacity within the layer. It does not remove it.

Across each of these industries, the pattern is the same. The fix is real-time analytics and reporting that removes the intermediary from the loop.

How to audit your own reporting stack

Before evaluating any new tooling, map one data request from the past week. Work through four questions:

Who originally asked the question? Who else had to touch it before an answer was produced? How long did it take from question to answer? Does the answer that arrived match the question that was originally asked?

If the request required more than two people or more than 24 hours, a translation layer is present. Yet changing the BI tool will not solve it. Run this as a workflow audit. It takes under ten minutes and tells you whether the problem is structural.

If you want to know what removing that layer would look like in your specific stack, that is the scope of our 20 hours free programme. We map the reporting workflow, identify where the translation layer sits, and show you exactly what removing it requires. No cost.

A good technology partner makes your business more capable and independent — whether you keep working with them or not. This is a practical guide to how to evaluate a technology partner: seven principles, the specific questions to ask, and the evidence to demand before you sign. Use it on any vendor before you commit.

Most technology partners look identical at the pitch stage. Every firm arrives with a polished deck, a set of impressive logos, and confident language about outcomes. The pricing structures are hard to compare. The case studies are vague. And the questions you don’t know to ask are usually the ones that matter most.

Knowing how to evaluate a technology partner for the first time is genuinely difficult. You can’t benchmark what you haven’t seen before — and most evaluation guidance either comes from the vendors themselves or treats all technology services as interchangeable. They aren’t. IP Australia’s guidance on IP ownership in contracted work is a useful starting point, but the commercial and operational risks go further than IP alone.

The framework below is what we use with clients who ask how to evaluate a technology partner — whether they’re comparing options for AI automation, workflow automation, or strategic technical oversight. We give it to them before they’ve made a choice, and we invite them to use it on us. Every principle traces back to an outcome for the business, not a feature of the vendor. Marketing decks look identical. Outcomes don’t.

Two ways to use each principle: the Ask them question opens the conversation. The Make them show you items close it. Anyone can answer a question well in a pitch meeting. Not everyone can produce the evidence. Push every vendor from telling to showing — that’s where the differences become visible.

01. They protect what makes you defensible

The outcome you want: Your IP stays a moat. Nothing that makes your business valuable leaks, gets copied, or sits exposed on someone’s laptop.

Most technology builds accidentally erode the thing they were meant to protect. A rules engine gets ported to a browser. A calculation gets exposed through a public API. A customer-facing document reveals the logic that produces it. By the time you notice, competitors have caught up, and what once separated you is now the industry baseline.

A good partner filters every architectural decision through whether it exposes your IP. Rules engines run server-side. Customer-facing outputs are flattened, watermarked, and signed. Customers see the result, not the derivation. Access is role-based and audit-trailed by default, not bolted on after the fact.

Watch for: Vagueness about IP protection. Any suggestion that calculation logic will be exposed to a browser, a customer, or a third-party integration. “We’ll figure out security later.” No distinction between what the platform shows internally and what it shows externally.

How to Evaluate a Technology Partner: Ask Then Make Them Show You

Ask them: “Walk me through the specific architectural decision that keeps our IP from leaving the building.”

Make them show you:

• A redacted architecture diagram from a previous build showing where the sensitive logic lived and how it was isolated. If they can’t produce one, they haven’t done this before.
• A reference call with a client whose IP they protected. Ask that client directly: did anything leak? What did the vendor do when a design decision risked exposure?
• Their standard contract clauses on IP ownership and confidentiality — before you ask for them.

02. They amplify your people, not replace them

The outcome you want: Your top experts do more of what only they can do, and less of what shouldn’t require them. The bottleneck shifts, or dissolves entirely. The people who make your business valuable stay valuable — and get to spend their time on work that actually needs them.

Most knowledge-heavy businesses hit a ceiling set by one or two people’s calendars. The tempting move is to build a platform that routes around the bottleneck — automating the expert out of the loop. That decision fails every time. The expert is still needed; you’ve just made them harder to reach.

A good partner designs for your experts as first-class users. They understand the difference between routine work (which should flow through the platform) and judgement work (which should route to the expert with everything they need to decide in minutes, not hours). They give your experts control over the rules that govern that routing.

Watch for: Any suggestion the platform will “handle approvals” or “automate expert review.” Any workflow that still requires your expert to sign off on every routine transaction, leaving the throughput cap unchanged. Any design that hides the expert’s contribution behind the platform rather than making it visible.

Ask them: “What does our expert’s day-to-day workflow look like after the platform is live? Walk me through it.”

Make them show you:

• A reference call with a client’s actual expert — the person whose workflow changed, not the CEO who signed the deal. Ask the expert directly: is your day better or worse than before the platform?
• A case study from a build where a key person was the bottleneck and what their role looks like now. If every case study is about headcount reduction, that tells you their philosophy.
• A before-and-after workflow diagram from a real engagement showing where the expert sat in each.

03. They share the delivery risk with you

The outcome you want: You pay for delivered work, not for promises. You can see exactly what you’re paying for and why — line by line, month by month. If the vendor stops delivering, you stop paying. Neither side is locked in.

The traditional consulting commercial model transfers all delivery risk to the client. Time-and-materials with no cap. Fixed-fee that quietly becomes variable when scope shifts. Large upfront payments before value comes back. Opaque invoices where you can’t tell what you actually bought. The vendor gets paid whether or not the work is delivered on time, to spec, or to standard. That is not a partnership.

A good partner structures things so their business only works if they keep delivering. Every invoice is traceable to a specific piece of work, agreed in advance. Acceptance criteria set before the build starts, not after. Clear exit terms with modest notice periods. If the work stops delivering, either side can walk without penalty.

Watch for: Time-and-materials with no cap. Large upfront payments before delivery begins. Fixed-fee contracts where every scope discovery becomes a change-request invoice. Invoices that arrive as a single line item with a large number. Any arrangement where you cannot clearly connect a payment to a deliverable.

How to Evaluate a Technology Partner: Ask Then Make Them Show You

Ask them: “If we stopped seeing value from your delivery in month three, what would happen commercially? And can you walk me through exactly how your invoicing works — what we’d be paying for and when?”

Make them show you:

• A redacted invoice from a real engagement. Can you understand it without the vendor explaining it? Line items, team allocation, what was delivered that month?
• An example — a real one, with dates — of an engagement where they paused, reduced, or refunded because delivery slipped. If it’s never happened, either they’re perfect or the contract never allowed it.
• Their standard exit terms in writing, before negotiation starts.

04. They design for change, not around it

The outcome you want: When your business evolves, the platform bends. Scope changes get absorbed, not weaponised. You’re never held hostage to a mid-flight decision.

Additionally, most builds hit scope changes six weeks in. Either the vendor discovers new complexity, or you learn something you didn’t know at the start. A rigid partner turns that moment into a negotiation, and every adjustment becomes an invoice. A good partner expects it.

A good partner builds in small, self-contained units. Scope locks at each unit’s start, but honesty runs throughout. They tell you when a change is small enough to absorb and when it’s large enough to warrant a proper conversation, in writing, before anything moves. They surface complexity as soon as they see it — not after the invoice cycle.

Watch for: Any change process that turns every scope conversation into an invoice. Rigid arrangements that punish adjustment. Vague language about “we’ll re-plan” without a defined mechanism. Vendors who go quiet when complexity emerges and resurface with a change order.

How to Evaluate a Technology Partner: Ask Then Make Them Show You

Ask them: “What happens if we discover more complexity halfway through the build? Give me a specific example of how that played out with a previous client.”

Make them show you:

• A change log from a real engagement showing which changes were absorbed at no charge and which were re-scoped. The ratio tells you their real philosophy.
• A reference call with a client whose scope shifted materially mid-build. Ask them: how did the conversation go? Did it feel collaborative or transactional?
• Their written change-management process, if one exists. No written process usually means the process is “whatever the vendor decides at the time.”

05. You own the outcome, top to bottom

The outcome you want: The code, the IP, the platform, the data. Yours. You can extend it, replace it, or take it elsewhere. You are never renting access to your own asset.

Some technology partners build platforms that only they can maintain. This arrangement makes the client technically the owner but practically the tenant. Six months in, extending the platform means going back to the same vendor, at the same rate, without any alternative.

A good partner delivers full source code ownership from the start. A shared repository with your team credentialled from day one. Documentation produced as a work artefact, not an afterthought. Another partner could pick up the codebase within a week if you needed them to.

Watch for: Any licencing arrangement where you rent access to your own platform. Code that lives only on the vendor’s infrastructure. Exit terms that make leaving expensive, slow, or contingent on the vendor’s cooperation.

How to Evaluate a Technology Partner: Ask Then Make Them Show You

Ask them: “If we ended the engagement tomorrow, what could we take with us and what would stay?”

Make them show you:

• The repository access structure from a current engagement (redacted). Who has access? Is the client’s team credentialled, or is access “available on request”?
• A sample of their documentation from a previous build. Could a new developer, with no contact with the vendor, understand it?
• The strongest proof there is: a reference call with a client who left them and took the platform to another partner — and whether the vendor gave that reference willingly.

06. They fit into your existing ecosystem

The outcome you want: The vendors, tools, and partners you already trust keep working. The new platform doesn’t ignite turf wars with your incumbents. Your business runs while the platform is being built, not in spite of it.

Moreover, very few technology decisions happen in isolation. Most businesses already have an ERP, a CRM, an incumbent development partner, existing licences and contracts. A partner that ignores that ecosystem isn’t proposing a technology solution — they’re proposing a disruption.

Additionally, a good partner maps your existing ecosystem during discovery. They define the integration boundary with your incumbents in writing before the build starts. Where their scope overlaps with someone else’s, they clarify who owns what — and put it in the contract.

Watch for: Any suggestion that your existing vendors need to be replaced. Vagueness about integration boundaries. “We’ll take over that work.” Refusal to engage directly with your incumbents. Any pattern of the vendor complaining about an incumbent to you rather than solving it with them directly.

Ask them: “How do you plan to coordinate with our existing vendors during this build?”

Make them show you:

• The name of an incumbent vendor they’ve worked alongside on a previous engagement — then call that vendor, not just the client. The incumbent’s view of them is the least-varnished reference you’ll get.
• A written integration boundary document from a previous build. If they’ve never produced one, the boundaries were never defined.
• An example of a scope overlap with an incumbent and how it was resolved — specifics, not principles.

07. They stay after the build

The outcome you want: Someone answers when something breaks. Support is a model with names, response times, and a price — not a favour you have to negotiate at 5pm on a Friday. The team that built your platform doesn’t vanish the day it goes live.

Furthermore, most consultancies specialise in the build phase only. The engagement ends, the team rolls onto the next client, and six months later — when something breaks, or a browser update kills a feature, or you need one small addition — you are starting a new commercial conversation with no guaranteed outcome.

When you evaluate a technology partner, one of the clearest signals is what their post-build model looks like. A good partner puts this in the proposal, not in a follow-up conversation. Named support contacts, defined response times for different severities, a clear price for ongoing support versus warranty — in writing, before you sign.

Watch for: No mention of what happens after go-live. Support “available on request” with no defined model. Warranty terms that are vague or absent. Any vendor whose proposal ends at the launch date. A support price that only appears after you’ve signed the build contract.

Ask them: “It’s six months after go-live and something breaks on a Friday afternoon. Who do I call, what happens next, and what does it cost?”

Make them show you:

• Their standard support agreement — response times, severity definitions, pricing — before you sign the build contract, not after.
• A reference call with a client who is 12 or more months post-launch. Ask them: what happened the last time something broke? How long did it take? What did it cost?
• The name of the person who would own your account after go-live. If the answer is “we’ll assign someone,” the model doesn’t exist yet.

How to Evaluate a Technology Partner Using This Framework

To get the most from this guide on how to evaluate a technology partner, take the “ask them” question from each principle and sit down with every vendor you’re considering. Ask the same questions, in the same order. Do not fill in silences. Do not accept marketing generalities in place of specific answers.

Then push past the answers. Every principle carries a “make them show you” list — references you can actually call, artefacts they can actually produce, clients who were in your position 12 or 18 months ago. Anyone can answer a question well in a pitch meeting. The evidence is where vendors separate.

Two questions worth asking every vendor, regardless of principle:

“Can you show me a client who is no longer working with you, and would they take a call from me?”

“What would you build differently if you knew from day one that we might not renew?”

In practice, the differences in how partners respond to these questions will be diagnostic. Any partner who is uncomfortable with them is telling you something about what the rest of the engagement will feel like.

You are welcome to use this framework on us.

If a partner hesitates to be evaluated against it, that hesitation is itself an answer.

The one-sentence version

Every principle in this guide to how to evaluate a technology partner is a version of the same question.

Does this partner make your business better off, whether you keep working with them or not?

Typically, the vendors who fail this test optimise for lock-in: of your IP, your capital, your expertise, your ecosystem. Every commercial and architectural decision is quietly designed to make leaving harder. However, the vendors who pass it optimise for your leverage. You should end the engagement stronger, more capable, and freer than you started.

If they have done their job well, you should have more options at the end, not fewer.

If you are trying to work out how to measure AI ROI, Uber’s COO Andrew Macdonald gave the clearest answer by accident, in a May 2026 Rapid Response interview that most companies are quietly living but nobody says out loud. The business had burned through its entire AI coding budget in four months. His conclusion: higher token usage did not translate into a proportional increase in useful consumer features. The link between spend and value, he said, was genuinely hard to draw.

Most companies are in the same position. Their dashboards show adoption climbing, spend growing, prompts running. None of those numbers answer the question that matters: compared to before AI, what actually got better?

The reason is structural. A token-usage dashboard is a school attendance record. It tells you whether students showed up. A school with 98% attendance and no learning outcomes is not a good school — it is a very good roll-call system. Most AI programmes work exactly the same way.

The fix is not a better dashboard. It is running the sequence in the right order.

The short version

• Token dashboards measure activity, not outcomes. Spend climbing is not value growing.
• The correct sequence is literacy, then adoption, then ROI — in that order. Most companies have inverted it.
• Each step has a concrete test. If you cannot pass the test for step one, step two’s numbers are meaningless.
• ROI must be measured against a pre-AI baseline. Not tokens consumed. Not hours saved as self-reported.
• A metric that only exists because AI exists cannot tell you whether AI worked.

The $1,000 version

A COO at a company roughly the size of a serious Australian SME set a KPI around AI token usage: spend per engineer. The usual instinct once a number starts climbing and nobody can explain why.

He spent $1,000 in API costs solving two issues. On a dashboard, that looks like adoption working. But look closer. The $1,000 was on top of his own time: prompting, re-prompting, checking, correcting. The task took roughly the same time it would have taken without AI. He used it anyway, because the company needed the metric to move.

The spend was not buying capability or productivity. It was buying attendance records at API prices. The roll-call looked perfect. Nobody asked whether the class had learned anything.

This is not an isolated case. According to Writer’s 2026 Enterprise AI Survey, 59% of enterprises invest at least $1 million a year in AI. Only 29% report significant ROI. PwC’s 29th Global CEO Survey found just 12% of CEOs could identify both reduced costs and grown revenue from AI in the past twelve months.

The gap between spenders and earners is not technology. It is sequence.

The sequence that actually works

The order matters. Almost no one follows it.

Step 1: Literacy

What it means:

The people using AI know how to use it well. Not whether they use it — whether they use it well. A team that prompts poorly, cannot verify outputs, and does not know when AI is the wrong tool is a spending team, not a capable one.

Why it comes first:

A team with low AI literacy spending confidently looks identical, on a dashboard, to a team with high AI literacy spending confidently. The dashboard cannot tell them apart. This is the same problem software engineers faced a generation ago when they were paid by lines of code written. The engineer who solved a problem in 50 lines got penalised against the one who wrote 500. Precise prompting uses fewer tokens. The dashboard rewards volume. It cannot see quality.

How to test it:

Pick one task your team runs regularly. Run it with AI. Compare output quality and time taken against your pre-AI baseline. Three questions:

• Did the AI-assisted output meet the same quality bar as the manual version?
• Did it take materially less time, accounting for prompting and verification?
• Did the person doing it feel in control of the output, or were they hoping it was right?

If the answer to any of these is no, literacy is the constraint. Do not move to adoption metrics until this passes. A skills session, a prompt library, or a structured review of how the team is actually using the tools will do more than any dashboard.

Step 2: Adoption

What it means:

Once literacy is real, adoption tells you how much of the potential is being captured. Before that point, adoption is spend with better attendance records.

Why it comes second:

High adoption across a low-literacy team is a cost problem disguised as a progress metric. You are paying for scale before you have proven the thing scales well. The number goes up. The outcome does not follow.

How to measure it meaningfully:

Adoption only means something when measured against a specific workflow with a known literacy baseline. The question is not “what percentage of the team used AI this week.” The question is “what percentage used AI well on the tasks where we know it should help?” Two things to track once literacy is established:

• Workflow coverage: For the tasks where AI has been proven to work, what percentage are being run through it consistently?
• Reversion rate: How often do people complete a task with AI and then redo it manually? Reversion is the most honest signal that literacy is not yet there, regardless of what the adoption figure says.

If reversion is above 20% on a given workflow, treat that as a literacy problem, not an adoption problem. More prompting to use the tool is not the fix.

Step 3: ROI

What it means:

A measurable change in a business metric that existed before AI did. Cycle time. Error rate. Revenue per person. Customer response time. Defect rate. Not tokens consumed, not prompts run, not hours saved as self-reported.

Why it comes last:

A metric that only exists because AI exists cannot tell you whether AI worked. The comparison must be to before — which requires having recorded what before looked like.

How to measure it:

Three steps.

Set the baseline first. Before any new AI rollout, record current performance on the workflows you intend to change. This takes an afternoon. Reconstruct from historical data if you missed it: project management tools, email timestamps, invoicing records, support ticket logs.

Run a 30-day comparison. Once AI is operating on the workflow, measure the same metrics over 30 days — not a new set of metrics designed to make the comparison easier. Compare directly.

Be honest about confounding factors. If the team changed their process at the same time as adopting AI, you cannot cleanly attribute the outcome. Note the confounds and account for them.

If the outcome metric improved, you have a case for continued investment. If it did not, the constraint is usually literacy, not the tool. Buying more access before addressing literacy does not fix the problem.

This is where most AI automation investments quietly disappoint — not because the tools do not work, but because the measurement framework was wrong before the first prompt was written.

How to measure AI ROI in practice: a 90-day plan

For a business starting from scratch, here is what running the sequence actually looks like.

Days 1 to 30 — Literacy sprint. Pick one team, one workflow. Run the literacy test. Identify gaps. Run one targeted training session or build a shared prompt library for that workflow. Re-run the test. Do not move forward until the team passes it.

Days 31 to 60 — Adoption measurement. With literacy established on that workflow, measure adoption and reversion. Set a target: 80% consistent adoption, under 20% reversion. If you hit it, the workflow is ready for ROI measurement. If not, go back to literacy.

Days 61 to 90 — ROI measurement. Compare the 30-day AI-assisted performance against the pre-AI baseline on your chosen metric. Document the result. Use it as the template for the next workflow.

At 90 days, you have one workflow with a defensible ROI number and a repeatable process for the next one. That is more useful than six months of token dashboards across the whole business. If you want a structured approach to this across your organisation, our technology strategy service is built around exactly this kind of diagnostic.

What Uber’s problem actually was

Uber’s problem was never that the budget grew. Budgets for capable things grow.

The problem is not having an answer, four months in, to the older and far less exciting question: compared to before, what actually got better, and by how much?

Andrew Macdonald’s test was exactly right: how many projects on the cutting room floor got moved forward because AI accelerated the engineering work? The answer, he said, was hard to draw a clean line to — even when token usage was trending astronomically.

Counting tokens spent is not the same as counting problems solved. The dashboard has perfect attendance. It just cannot tell you whether the business got smarter.

If you want to run this diagnostic with support, start with 20 hours free.

Common questions

Fable 5’s free-access window has been extended to July 19, 11:59:59 PM PT. After that, it’s usage credits at $10/$50 per million tokens, double Opus 4.8. We covered what to build before the deadline here. This post is about making whatever time you’ve got left go further.

None of what follows is “just use it less.” These are six specific, sourced techniques people are actually running, with the real numbers.

The short version:

• Drop the effort level: Most tasks don’t need max effort, the accuracy gap is smaller than the cost gap.
• Let Fable plan, let a cheaper model execute (and vice versa for research): Anthropic’s own advisor tool cuts cost 11.9–85% depending on the pairing; for anything needing current information, have a cheaper model research first via /deep-research, then hand the findings to Fable to plan.
• Try pxpipe: a free proxy that renders your background context (not your live message) as images, ~59–70% lower bills, but lossy for exact strings buried in that history.
• Add Ponytail: a “write less code” skill, ~54% less code and ~20% lower token cost, independently corrected down from an inflated first claim.
• Clean up your inputs: compress noisy output, route by model, /compact often; one developer cut usage ~40–70% doing this alone.
• Fix your file formats: Markdown over PDF saves 65–90%; crop screenshots instead of uploading them full-size.

Method	Real saving	Best for	Watch out for
Lower the effort level	Up to ~5x cheaper at similar accuracy on easier tasks	Everyday tasks, not genuinely hard problems	Real accuracy drop on the hardest tasks
Advisor / architect pattern	11.9–85% cheaper depending on model pairing	Long agentic sessions, coding, and research-heavy planning	Only helps if the cheaper model can genuinely handle its half of the split
pxpipe (image-context proxy)	59–70% lower end-to-end bill	Heavy Claude Code sessions with dense text/code	Lossy on exact IDs, hashes, long numbers
Ponytail (write-less skill)	~54% less code, ~20% lower token cost	Coding tasks prone to over-building	Gains near zero on already-minimal code
Context hygiene (RTK, repomix, /compact, model routing)	~40–70% combined, per one documented workflow	Anyone running long or repeated sessions	Takes setup time upfront
Markdown over PDF	65–90% cheaper per document	Any document-heavy workflow	Complex visual layouts can lose fidelity in conversion

1. Drop the effort level. Seriously!

By default, Fable 5 runs on a fairly high effort setting, and most people never touch it. Anthropic’s own benchmark data shows why that’s expensive: on FrontierCode Diamond, accuracy climbs from about 11.5% at low effort to roughly 30.9% at extra-high – real gains, but not gains that every task needs. On SWE-bench Pro, the spread is smaller: 75.0% at low effort versus 80.4% at extra-high.

That means: if your task isn’t genuinely hard — a web tweak, a straightforward edit, a routine question — running it on max effort is paying architect rates for a job that doesn’t need one. Drop to medium or low with /effort and see how the output holds up first.

2. Make Fable the architect, not the typist

Anthropic has an actual feature for this: the advisor tool. Instead of running Fable 5 for an entire session, you let a cheaper model (Sonnet or Haiku) execute the task end-to-end, and only escalate to a stronger model when it hits something it can’t resolve alone.

The published numbers are real and specific: Sonnet with an Opus advisor cost 11.9% less than running Opus solo while scoring slightly higher on SWE-bench Multilingual.

Haiku with an Opus advisor cost 85% less than running Sonnet alone, while roughly doubling Haiku’s score on a hard benchmark.

In Claude Code, this is /advisor — or the related /model opus-plan, which runs planning on the stronger model and execution on the cheaper one automatically. The same logic applies to Fable 5: let it plan and make the hard calls, hand the actual typing to Sonnet.

The reverse pattern works tooFable 5’s knowledge cutoff isn’t yesterday, so if a plan needs current information — recent docs, a changelog, competitor pages — that’s not a job that needs Fable-level reasoning, it just needs someone to go and look. Claude Code’s built-in /deep-research workflow fans out web searches across a cheaper model, cross-checks the sources against each other, and hands back one cited report — which you then feed to Fable 5 to actually plan against. Cheap model gathers the facts, expensive model reasons over them. Running that same fan-out research on Fable 5 itself would blow through your usage cap for a step that doesn’t need its reasoning at all.

3. Try pxpipe — turn your context into pictures

This one sounds like a joke and isn’t. pxpipe is a free, open-source local proxy that intercepts requests to Claude Code and converts the bulky, repetitive parts — your system prompt, tool documentation, older conversation history — into PNG images before they’re sent to the model. Claude reads the image back with its vision capability instead of reading it as text.

What it doesn’t touch matters as much as what it does. Your actual current message and everything the model outputs stay as plain text throughout — pxpipe only targets the static, repetitive background context that gets re-sent unchanged on every turn. That distinction is the whole reason this is usable in practice: the parts where getting the answer exactly right matters most (your live question, its live response) are never run through the lossy part at all.

The reason it works: Anthropic prices images by pixel dimensions, not by how much text is packed inside them. Dense content like code or JSON can fit roughly 3 characters per image-token, versus about 1 character per text-token. The developer’s own published numbers: a real session that cost $42.21 running as plain text cost $6.06 through pxpipe — a genuine, documented 59–70% reduction on production workloads.

Two lines to try it:

npx pxpipe-proxy
ANTHROPIC_BASE_URL=http://127.0.0.1:47821 claude

4. Add a “write less” skill

Ponytail is a free Claude Code skill built around one idea: install a “lazy senior developer” mindset that asks, before writing anything, “does this need to exist at all?” It stops agents from over-building — reaching for a library and a wrapper component when a native browser feature would do.

Worth knowing the full story here, because it’s a good lesson in checking numbers rather than trusting a headline: Ponytail’s first published benchmark claimed 80–94% less code. A user pointed out the comparison was unfair — the baseline being compared against wasn’t given the same instructions, so part of the gap was an artifact of that mismatch. The author accepted the criticism and re-ran it properly. The corrected, defensible number: about 54% less code on average, with roughly 20% lower token cost and 27% faster runs, tested on a real FastAPI/React repository, with zero drop in security or error-handling scores. Independent testing on Opus found even better results than the original Haiku-based benchmark.

That’s a more honest number than the first version, and it’s still a real saving. Install it in Claude Code:

/plugin install ponytail@ponytail

5. Clean up what you feed it before you feed it (the save-tokens-in-Claude-Code stack)

This is the boring one and probably the highest-leverage one. A developer running a heavy Claude Code workload every day documented the stack that got him a 60–70% reduction versus running everything raw:

• Compress noisy CLI output before it reaches Claude: A tool like RTK dedupes repeated lines from grep or git diff output — real numbers cited: 76% efficiency on one session.
• Ship a curated project snapshot, not the whole repo: Tools like repomix (23k GitHub stars) or code2prompt (7k stars) strip lockfiles, build output, and generated code before Claude ever sees the project.
• Route by task, not by habit: Save the expensive model for planning and genuinely hard problems; let Sonnet handle file-by-file edits. One developer reported this alone cut weekly usage by roughly 40% with no quality drop he could feel.
• /compact aggressively, or just start a new session: Long conversations get re-read in full on every turn — token cost grows close to quadratically the longer a session runs.
• Write terse prompts for trivial stuff: The so-called “caveman” style — dropping pleasantries and background context for quick lookups — trades some nuance for a real cut in input tokens. Save full sentences for anything touching production.

6. Format is a cost decision, not just a preference

This one’s about what you feed it, not how you run it.

Markdown beats PDF, and it’s not close. A PDF page can cost Claude roughly 1,500–3,000 tokens, because it’s not just reading your content — it’s processing embedded fonts, layout instructions, and rendering noise you never see. The same content saved or converted as plain Markdown can cut that by 65–90%. If you’re regularly uploading reports, contracts, or proposals as PDFs, converting them first (Microsoft’s free, open-source markitdown tool does this in one step) is one of the cheapest wins available.

If you are working with screenshots, crop them. A 1000×1000px image costs roughly 1,334 tokens; a cropped 200×200px region of the same image, showing only what matters, costs about 54 tokens — a 25x difference for the same useful information.

What we’d skip

Not every “hack” making the rounds is worth your time:

• Custom tokeniser tricks: Fragile, save pennies, break with the next model update.
• Prompt-shortening middleware “agents.”: Often add latency and make output worse, not better.
• Switching providers mid-task to save a few cents: The context you lose costs more than what you saved.

A word on timing

Anthropic themselves have said this exploit-the-pricing-gap approach (pxpipe specifically) is unlikely to stay open indefinitely — if enough people lean on it, expect the underlying pricing to move. Treat the specific tricks in this post as a current window, not a permanent floor. The habits — right-sized effort, right model for the job, clean context — are durable regardless of what Anthropic changes next.

Common questions

Further reading in this series:

Claude Fable 5 use cases

What Claude Fable 5 means for your business