Name: Is it worth the time?
Creator: Kraken

Our AI doctrine: when to use AI, when to automate, and when to do neither

August 18, 2026

How we use AI to think more, not less, and outsource the task, never the decision.

TL;DR

At Payward, we use AI as a powerful tool that enables us to think more and do more, always outsourcing the task, never the decision. This doctrine lays out when to reach for AI, when to automate instead, and when the honest answer is doing neither.
The core distinction: AI is excellent for thinking through a problem, brainstorming, drafting, and proving out an idea. It’s usually the wrong tool for a recurring task, live data, or a published dashboard.
The tool ladder: For anything durable, use the simplest tool that does the job reliably. Native automation before n8n, n8n before anything bespoke, and AI only as the one judgment step inside that automation.
Before you build: Ask whether it’s even worth it, who will actually use the output, and whether someone has already built it.
Whose login is it: Anything that runs unattended, isn’t on your own machine, gets shared, or serves many teams needs a service account, not a personal login.

That’s the one rule underneath everything else here: build the plumbing deterministically, and use AI for the judgment and creative parts, not as the thing that runs on its own. We don’t let AI do our thinking for us so we can switch off; we use it so we can think more, not less. This is the framework we actually use internally at Kraken to decide when AI is the right call, when the answer is automation, and when the honest answer is neither.

The core idea

Almost every task produces one of two kinds of outcomes, and that single distinction decides which tool to reach for.

Deterministic. The same input should always produce the same output: moving a ticket when a field changes, posting a report on a schedule, totaling a column. These belong to rules and automation.

Probabilistic, or judgment-based. The “right” output varies and needs interpretation or generation: summarizing a thread, drafting copy, deciding tone, structuring messy notes. This is where AI earns its keep.

AI’s real job is to help you work out what to build and how. It’s a thinking partner and a prototyper. It can sketch a process, suggest how to visualize something, draft a first version, and prove a concept works. That’s a different job from being the engine that runs the thing every day. The moment a task becomes “this should happen reliably, on a trigger, forever,” AI alone stops being the answer and becomes, at most, one step inside proper automation.

Use AI to design the machine, not to be the machine. It does the task; you keep the decision.

First, is it even worth it?

Before reaching for AI or automation at all, check the payoff. Time spent making a task faster only pays back if you do the task often enough, and save enough each time. Some tasks are so rare, or so quick, that automating them takes more time than it will ever save.

The table below shows roughly how much total time is worth spending, over five years, making a routine task faster before you’ve spent more than you’ll ever save back. Read down the left column for how much time you shave off each run, and across the top for how often you do the task.

Roughly how much total time is worth spending over five years to make a routine task faster, by how often you do it and how much time you save each run.
Time saved per run	50/day	5/day	Daily	Weekly	Monthly	Yearly
1 second	1 day	2 hours	30 minutes	4 minutes	1 minute	5 seconds
5 seconds	5 days	12 hours	2 hours	21 minutes	5 minutes	25 seconds
30 seconds	4 weeks	3 days	12 hours	2 hours	30 minutes	2 minutes
1 minute	8 weeks	6 days	1 day	4 hours	1 hour	5 minutes
5 minutes	9 months	4 weeks	6 days	21 hours	5 hours	25 minutes
30 minutes	Never	6 months	5 weeks	5 days	1 day	2 hours
1 hour	Never	10 months	2 months	10 days	2 days	5 hours
6 hours	Never	Never	Never	2 months	2 weeks	1 day
1 day	Never	Never	Never	Never	8 weeks	5 days

Table source: xkcd, “Is It Worth the Time?”

Cells marked Never are combinations that can’t happen — the task would take more time than there is in the day.

A general rule of thumb: if your automation budget is over a day, it’s worth automating. If it’s under an hour, just do it with AI, or by hand.

Takeaway: if a task happens yearly and saves you a minute, your entire budget to “fix it forever” is about five minutes. Don’t spend an afternoon building a tool for it. Just do it by hand. The same logic kills a lot of tempting AI and automation projects before they start.

The tool ladder for durable work

Once a task is worth doing repeatedly, pick the simplest tool that does it reliably, not the fanciest. Work down this list and stop at the first one that fits. The bar rises with reach: a task one person runs now and then can stay simple, but something many teams will depend on deserves a sturdier, more deliberate build.

Native automation, first. Tools like Jira, Confluence, Slack, and Google Workspace all have built-in automation rules. They’re reliable, maintained for you, and already integrated, and they cover a lot: transitions, updates, scheduled triggers, notifications, simple branching, even posting to a channel from a rule. If a native rule can do it, use it rather than reaching for something heavier.
A cross-system tool, when you cross systems. Reach for something like n8n when you need to connect multiple systems, do real branching or looping, call external APIs, transform data, or run on a schedule outside a single product. This is the workhorse for cross-system or complex automation.
AI as a node, not the whole thing. When a workflow needs one step that takes judgment or generation (summarize this, classify that, draft that), add an AI step to do only that slice. The trigger, the data gathering, the routing, and the posting all stay deterministic. You’re wrapping AI inside automation, not replacing automation with AI.
Bespoke builds and agents, last. Multi-agent orchestration and custom code are powerful, but heavy to build and maintain. They’re justified only when the judgment genuinely can’t be broken into rules plus a step or two of AI. Most tasks never get here.

You don’t “graduate” from automation up to AI. The scaffolding always stays deterministic. AI lives inside it.

Whose account is it? Individual access vs. service account

This is the part people miss until something breaks.

When you use an AI tool, it acts as you. It uses your credentials, your personal access tokens, your context. That’s fine for personal, in-the-loop work. It becomes a problem the moment you want something to run unattended, be shared, or be published.

Publishing on personal keys is fragile. If you build something on your personal tokens (a dashboard, an integration, a bot), it’s tied to you. It breaks when you rotate a token, change roles, or leave. Often it can’t be published at all, because it’s authenticated as a person rather than a service. Anything meant to live beyond your own session needs a dedicated service account.

The visibility tradeoff runs both ways. A service account is the right call for scale, but it deliberately won’t see your personal context: your private messages, your private channels, files only you can open. That’s by design. A workflow that summarizes “everything I can see” behaves very differently as a service account than it does as you. Decide which identity the task actually needs before you build it.

Even for your own work, connections that log in as you tend to time out after a few days. For something you run often, a tool with a long-lived token is steadier.

Rule of thumb: prove it with your own credentials, productionize it with a service account. Personal login for exploration and one-offs. A dedicated service account or bot for anything that runs at scale, on a schedule, serves many teams, or gets shared.

Anti-patterns: when not to reach for AI

These are the tempting moves that look fine in a demo and create problems later. Each one has a better path.

Common AI anti-patterns, why each one backfires, and the better path to take instead.
Pattern	Why it backfires	What to do instead
Generating multi-page output nobody reads	Using AI to fill pages for the sake of volume produces length without value. A long document no one absorbs is worse than a short one that lands.	Decide who will actually read this and what they need to take away, then have AI produce only that. Edit it yourself, and don’t share anything you haven’t read.
Feeding AI junk or limited context	Garbage in, garbage out. Vague prompts, stale documents, and irrelevant context produce confident, well-formatted nonsense that looks right and isn’t.	Curate the inputs. Give it specific, current source material, scoped tightly to the task. If you wouldn’t trust the source yourself, don’t trust the output built on it.
Building a dashboard in an AI chat from a CSV	There’s no live data sync. Every refresh means re-exporting and re-generating, so you get a snapshot, not a dashboard, and it’s built on your personal access.	Build it in a proper BI tool with a live connection to the data warehouse, so it refreshes itself. Use AI for the design phase, deciding which metrics matter and how to lay out the charts, then hand the build to a tool that stays connected to the source.
Having AI summarize a chat channel just to post the summary back to that channel	It won’t run on its own. It re-reads the whole channel every time and leans on the model to fetch and route, which is the part it’s least reliable at. It’s tied to one login, and the output drifts in shape and quality from run to run.	Use AI to prove the idea and tune the prompt, then move it into a proper workflow tool with a dedicated service account and bot.
Rebuilding something that already exists	Either a native rule already does it deterministically, so an AI-driven version is just more moving parts for a less reliable result, or a colleague already built it, but everyone keeps spinning up their own, so duplicates pile up and get harder to navigate.	Look before you build. Check the platform for a native rule, and search your team’s existing tools and knowledge base for prior work. If something close exists, use it, extend it, or join it rather than starting over.

The throughline, once more: use AI to think more, not less. Outsource the task, never the decision. Look for what already exists before you build, keep your inputs clean, and don’t ship anything nobody will read. It’s a simple discipline, but it’s saved us from rebuilding the same fragile thing more than once.