They were no longer just autocomplete. They could write real features, move around a codebase, debug build errors, reason through deployment problems, and take a vague product idea surprisingly far.

But there was still a more interesting question:

Could AI help build an actual production application?

Not a landing page. Not a toy demo. Not a vibe-coded prototype that works once on localhost and falls apart the moment a real user touches it.

A real product, with accounts, data, imports, SEO, public pages, deployment, edge cases, and enough polish that it felt like software instead of an experiment.

That was the real question behind Save.Cooking.

I wrote the original launch post as a holiday tech support story. Six months later, the more useful version is not really about recipes. It is about what AI was good at, where it was misleading, and what the project taught me about the future of software development.

The project started with a small real problem

The original problem was simple: my parents had years of recipes trapped in MasterCook, an old recipe application that was being decommissioned. They needed a way to move that archive somewhere else.

That could have been a utility script. It could have been a one-time migration. Instead, it became a full recipe-management app because AI made the cost of building the bigger version feel dramatically lower.

That is one of the first lessons.

AI changes the perceived cost of trying things. When implementation feels cheaper, bigger ideas become tempting. Sometimes that is great. Sometimes it is dangerous.

Save.Cooking became a useful proof point because it went far beyond the “make me an app” demo. It had legacy imports, public recipe pages, user accounts, search, recipe browsing, sharing, structured content, and a Chrome extension for saving recipes from other sites. It looked and behaved like a real product.

But the more interesting question is not “what features did it have?”

The more interesting question is: which parts did AI actually help with, and which parts still required human judgment?

AI was excellent at implementation drag

The biggest win was momentum.

A production app is mostly the boring middle: weird data formats, metadata, fallbacks, layouts, permissions, routes, configuration files, deployment failures, and the hundred small details that make the difference between a demo and something people can use.

AI was genuinely helpful there.

A good example was the MasterCook import problem. MasterCook’s export format was not a clean, well-documented modern API. It was an old file format that needed to be inspected, guessed at, parsed, tested, and mapped into a database-oriented structure.

That could have become a deep manual time sink. Instead, the AI could open the files, look for patterns, infer the structure, write parsing code, test assumptions, and iterate until the recipes imported correctly.

That is exactly the kind of work where AI feels like magic. Not because it has product taste, but because it is willing to grind through the messy mechanical parts faster than a human wants to.

The same was true for a lot of SEO plumbing.

With the right prompting, I could push the AI into implementing things like structured recipe data, clean HTML, alternate markdown-style recipe formats, Open Graph metadata, canonical URLs, and even the small operational files like robots.txt that help search engines understand what to crawl.

Those are not glamorous features. They are also not optional if the goal is a public content-driven application.

AI made them cheap enough to do.

But AI did not magically know what “good SEO” meant

This is where the nuance matters.

If you naively ask an AI system for “SEO,” you will usually get shallow advice: use headings, write good titles, add keywords, make sure the page has structured HTML.

That is not wrong, but it is not enough.

For a recipe site, real SEO includes things like Recipe schema, canonical pages, social metadata, crawl behavior, internal linking, public indexable pages, image metadata, and content formats that machines can understand. You need to know enough to ask for those things, or at least to recognize them when the model points in that direction.

The AI was helpful once the target was clear. It was much less useful when the target was vague.

That is a pattern I keep seeing with AI software work. The model can produce a lot of code, but the quality of the result depends heavily on whether the operator knows the language of the domain.

You do not need to personally write every line anymore. But you still need enough background to ask for the right system.

AI was too optimistic about the business

The part AI did not help with was strategic judgment.

It never really pushed back on whether a recipe website was a good business idea.

And in hindsight, that is the obvious weak spot.

In the age of AI, why does someone need a recipe website for many everyday cooking use cases? If you need a Caesar salad for two people, you can ask ChatGPT, Claude, Gemini, or whatever assistant is sitting on your phone and get a custom answer instantly.

The entire category of recipe websites is getting squeezed from multiple directions: search changes, AI answers, Pinterest fatigue, ad overload, and the fact that on-demand generation is often more convenient than browsing.

That does not mean recipe tools have no future. But it does mean the default “recipe site with public pages and SEO traffic” strategy is much less attractive than it used to be.

AI did not steer me away from that.

It was happy to help build the thing. It was not especially good at saying, “This category might be structurally declining, and the business case is weaker than the implementation plan makes it feel.”

That distinction matters.

AI can make the cost of building something much lower. It does not automatically make the thing worth building.

The human job moved up a layer

The real lesson from Save.Cooking is not that AI can write code. That part is increasingly obvious.

The lesson is that AI can tackle meaningful software problems, but the operator still needs to know what to ask for, what to inspect, and what “good” looks like.

A non-technical person can absolutely get further than ever before. That is real. AI can fill in gaps, explain concepts, write scaffolding, and produce working software from plain-English direction.

But production code contains a lot of “you don’t know what you don’t know.”

Security. Data modeling. SEO. Deployment. Background jobs. Auth. Permissions. Crawlability. Performance. Observability. Error handling. Content formats. Migration paths. Maintainability.

If you do not know those categories exist, you may never ask for them. If the AI gives you a plausible answer, you may not know whether it is actually right.

That is why software engineering experience still matters. Computer science still matters. Product judgment still matters. The value moves from typing code to directing systems.

This is also why I have been thinking more about agentic-first development. As agents become more capable, the bottleneck becomes less about whether a model can implement a function and more about whether a human can structure the work, define the right boundaries, and keep the system coherent.

The codebase got bigger than one person should want

There is another uncomfortable lesson here.

AI can generate an order of magnitude more code than one person would normally choose to write and maintain.

That sounds like productivity. And it is.

But it also creates a new maintenance problem.

If one person can produce the surface area of a small team, someone still has to understand that surface area later. Someone has to debug it, refactor it, secure it, migrate it, update dependencies, handle production issues, and decide what should be removed.

In a world where AI keeps accelerating software creation, I do not think we need fewer software engineers.

We may need more of them.

Not necessarily more people typing boilerplate from scratch, but more people who can keep AI-built systems working. More people who understand architecture, tradeoffs, debugging, production reliability, and how to translate a business problem into the right technical shape.

The job changes. It does not disappear.

Six months later

Looking back, Save.Cooking feels like a snapshot of a specific moment in AI development.

At the time, building a full-stack product this way felt like a frontier experiment. Six months later, the tools are already better and the expectations are higher.

The takeaway is not “everyone should build a recipe app.”

The takeaway is that AI can now absorb a massive amount of implementation drag. It can reverse engineer old formats. It can scaffold real products. It can implement complicated technical requirements when the operator knows how to describe them. It can help a single builder push far beyond what would have been reasonable a few years ago.

But it still needs direction.

It still needs judgment.

It still needs someone who knows when the answer is plausible but shallow, when the architecture is getting messy, when a feature is technically correct but strategically pointless, and when the business problem has changed underneath the software.

Save.Cooking may have started as a recipe project, but the real experiment was bigger than recipes.

It was a test of what happens when AI turns implementation from the bottleneck into raw material.

That is powerful. But it makes taste, experience, and technical judgment more important, not less.

Not the product manager. Not the developer. Not even the AI model doing half the implementation.

The word agent is still too fluid. Sometimes it means a chatbot. Sometimes it means a background job with an LLM call in the middle. Sometimes it means a coding assistant with tools. Sometimes it means a workflow that can make decisions, call APIs, and keep going without a human clicking every button.

That makes it hard to build software for agents.

If you tell a coding agent, “make this more agentic,” you will often get something vague. Maybe it adds an API endpoint. Maybe it adds a prompt. Maybe it writes a README. Maybe it creates a single hard-coded instruction like “analyze this data and return insights.”

That is not enough.

The better question is more practical:

How would an agent actually use this feature five minutes after it was built?

That question changes the development loop.

The old loop is too human-centered

Most application development still assumes a human user.

You build a feature. You open the browser. You click around. You see if the form works. You check the page. You fix the obvious bugs. Eventually you may add API endpoints, documentation, admin commands, or automation hooks around the edges.

That works if the primary user is a person with a screen, patience, and enough context to infer what the software is supposed to do.

Agents are different.

An agent does not “just know” that the button in the top-right corner starts the workflow. It does not automatically understand which endpoint is safe, what order commands should run in, which fields are optional, or how to recover from a partial failure.

A human can poke around and build a mental model.

An agent needs that mental model handed to it.

That is why building AI-operable systems is not just about exposing a few commands. The software has to be shaped so an agent can discover it, operate it, verify its work, and recover when something goes wrong.

Agentic-first development means testing with an agent immediately

The loop I have been using is simple:

1. Build the feature.
2. Build the API, CLI command, or skill that describes how an agent should use it.
3. Ask an agent to use the feature immediately.
4. Watch where it gets confused.
5. Improve the feature, the interface, and the skill together.

The important part is timing.

Do not wait until the feature is “done” and then bolt agent support onto it later. The best feedback happens while the implementation context is still fresh. The model knows what was just built. The developer knows what tradeoffs were made. The rough edges are still visible.

So after a feature lands, ask the agent something like:

Use the feature you just implemented as if you were an agent trying to complete a real task. Do not explain how it should work. Actually exercise it. Tell me where the interface, API, command output, docs, or skill file made your job harder.

That prompt surfaces a different class of bug.

Not just “does the endpoint return 200?”

More like:

• Could the agent find the right command?
• Did the command output include enough context?
• Was the failure mode understandable?
• Did the skill explain the safe path?
• Was there a dry-run option before a destructive action?
• Did the agent know how to verify success?
• Did the API require hidden knowledge from the developer’s head?

That is the kind of feedback normal QA often misses.

The skill is part of the feature

This is the part that took me a while to appreciate.

If an agent is going to use your software, the skill file is not documentation after the fact. It is part of the product surface.

A human-facing feature might include:

• UI
• copy
• error messages
• onboarding
• docs

An agent-facing feature needs its own equivalent:

• tool descriptions
• command examples
• safe operating rules
• expected outputs
• verification steps
• known pitfalls
• recovery instructions
• examples of good and bad usage

That context is not decorative. It is how the agent becomes competent.

This is the same pattern behind bring your own agent. The useful part is rarely one magical prompt. The useful part is the accumulated operating system around the work: the tools, memory, examples, rubrics, and habits that let an agent perform reliably in a specific environment.

So when you build a feature, build the skill at the same time.

If the feature has an admin command, the skill should explain when to use it, which flags matter, what a successful result looks like, and what to do if it fails.

If the feature has an API, the skill should show real request and response examples.

If the feature triggers background work, the skill should explain how to check job status, inspect logs, and retry safely.

If the feature can modify production data, the skill should include dry-run behavior and warnings.

The skill is the agent’s onboarding document.

Write it like the next user has no memory of the conversation that created the feature. Because usually, that is exactly what will happen.

Fresh-context testing is where this gets useful

The first version of this loop can happen in the same chat where the feature was built.

That is useful, but it is not enough.

The agent that just wrote the feature has a huge amount of implicit context. It remembers the architecture discussion. It remembers the files it edited. It remembers the assumptions. It may know how to use the feature because it just created it.

A real future agent will not have that advantage.

A better test is to create an isolated subagent and give it only the skill plus the repo or application access it would normally have.

Then ask it to complete a task.

For example:

Spawn a fresh subagent. Give it the new skill and no extra explanation. Ask it to use the feature to accomplish a realistic task. Report where it got stuck, what context was missing, and what would have made the skill easier to use.

That isolation is valuable.

It simulates the reboot problem. It shows what happens after the development context disappears and all that remains is the actual product surface you created for agents.

If the subagent can use the feature from the skill alone, you probably have something durable.

If it cannot, that is not a failure of the agent. That is product feedback.

Build the context harness, not just the prompt

There is a second side to agentic-first development: building software that contains agents as features.

This is where the terminology gets even less helpful.

If you ask a coding agent to “add an agent that audits this data,” it may create a function with a prompt like:

Analyze this data and return recommendations.

That is not an agent. That is a sentence.

A useful internal agent needs the same thing a new employee would need: context, instructions, examples, constraints, access to the right data, and a definition of good work.

The framing that works better is this:

Build this as if we are delegating the task to a smart junior employee who is new to the company. Give them enough context to act like a senior employee. Do not be afraid of a large prompt. Use dynamic, templated context pulled algorithmically from the application where possible.

That produces a different implementation.

Instead of a tiny hard-coded prompt, you start building a context harness:

• current user or account context
• relevant records from the database
• recent activity
• available tools and actions
• policy or brand rules
• examples of high-quality output
• domain-specific terminology
• constraints and safety rules
• scoring rubric or acceptance criteria
• exact output schema

Some of that context should be static. Some should be templated. Some should be pulled from the application at runtime.

The important distinction is that context assembly should be mostly algorithmic, not another vague agentic step. The software should know where to retrieve the account details, prior activity, relevant documents, and configuration. Then the LLM receives a rich work packet instead of a bare instruction.

Modern LLM context windows can hold a lot. That does not mean you should dump everything in blindly, but it does mean developers should stop being afraid of giving the model enough information to do the job well.

A one-sentence prompt is rarely delegation.

It is more like shouting a task at somebody as they walk past your desk.

Treat agents like employees, not magic functions

The employee analogy keeps helping.

If you hired a junior employee and said, “audit this customer account,” you would not expect great work unless you also gave them:

• what the company does
• what the customer is trying to accomplish
• what tools they can use
• what good and bad accounts look like
• where to find the data
• what risks to watch for
• what format the answer should take
• when to escalate

Agents need the same treatment.

This does not make them human. It just gives developers a better abstraction.

A function needs parameters.

An agent needs context.

A function returns a value.

An agent performs work against a goal, using judgment inside constraints.

If you build the feature as if the agent were a function, you tend to under-specify the work. If you build it as if you were delegating to a new employee, you naturally include the missing context.

That is the difference between “LLM integration” and an actually useful agentic feature.

Two kinds of agentic-first software

There are really two related ideas here.

The first is software an agent can use.

That means APIs, CLI tools, skills, structured outputs, safe commands, dry runs, logs, and verification steps. It means the application is operable by an AI assistant in the same way it is operable by a human.

The second is software that uses agents internally.

That means LLM-powered audits, cleanup jobs, recommendations, workflows, summaries, monitors, and decision-support features. It means the application itself can delegate pieces of work to model-driven components.

Those are different design problems, but they reinforce each other.

When you make a feature easier for an external agent to operate, you often make it easier for your internal agents to call safely too. When you build richer internal context harnesses, you often expose clearer concepts that external agents can use.

This is where agent teams and adversarial review loops become more than a creative workflow. The same idea can apply inside software development: one agent builds, another exercises, another reviews, and the product improves because the agents are forced to use the thing rather than merely describe it.

What this looks like in practice

A practical agentic-first feature might ship with a checklist like this:

1. Human UI works.
2. API endpoint exists.
3. CLI command or tool wrapper exists.
4. Command output is structured and includes enough context.
5. Errors include recovery suggestions.
6. Destructive actions support dry-run.
7. A skill explains how and when an agent should use the feature.
8. A fresh subagent can complete a realistic task using only that skill.
9. The built-in LLM prompt uses a rich context harness, not a one-line instruction.
10. Verification steps prove the work succeeded.

That checklist is not complicated.

But it changes what “done” means.

Done is no longer only “a person can click it.”

Done becomes “a person can click it, an agent can operate it, and the application’s own agents have enough context to use it intelligently.”

The terminology will catch up later

Right now, everyone is still inventing words for this.

Agentic support. AI-native software. Agent-operable systems. LLM-powered workflows. Human-in-the-loop automation. Delegated intelligence.

The names are messy because the category is still forming.

That is why the practical loop matters more than the vocabulary.

Build the feature. Build the skill. Ask an agent to use it. Isolate the test. Watch where it fails. Improve the interface and the context harness. Repeat.

That loop creates better software even if nobody agrees on the perfect terminology.

The applications that win in the next phase will not just have AI sprinkled on top. They will be designed around the reality that some users are human, some users are agents, and some features are agents doing work on behalf of both.

That is what agentic-first development means in practice.

Not “add an agent.”

Build the application so agents can understand it, operate it, and meaningfully participate in the work.

They have an attention problem.

The numbers are already somewhere — Shopify, Triple Whale, Looker, a spreadsheet somebody updates on Fridays, a finance model only one person fully understands. The issue is not access. It’s whether anyone is still looking at the right number often enough to matter.

That’s where AI can be useful.

Not as a replacement for judgment. Not as some magic strategy layer. Just as a way to keep one important business number visible every day, without relying on memory or good intentions.

That sounds small.

It isn’t.

In an operating business, the difference between “we noticed it early” and “we noticed it too late” can be expensive.

The real problem is drift

Here’s what usually happens.

When a company is small, the important numbers are close enough to the surface that you can feel them.

Spend goes up. Sales move. Repeat orders change. Margins tighten. You can usually tell when something is off.

Then the company gets more complex.

More channels. More campaigns. More SKUs. More meetings. More people touching the numbers. More noise.

The KPI doesn’t disappear. It just gets crowded out.

That’s when drift becomes costly.

CAC creeps up for a few weeks before anyone reacts. Retention softens, but revenue still looks fine. Margins compress in a way that seems temporary until it isn’t.

Usually it’s not one dramatic mistake.

It’s a series of ordinary misses that compound because nobody stayed close enough to the basics.

That’s the opportunity here: use AI to make the important number harder to ignore.

A concrete example: CAC-to-90-day-LTV at Psychedelic Water

At Psychedelic Water, one useful workflow is a daily Slack report on one relationship:

CAC to 90-day LTV

That number tells you whether growth is healthy or just getting more expensive.

If CAC rises while 90-day LTV stays flat, the business is becoming less efficient. If LTV improves while CAC stays stable, you have room to push. If both move the wrong way, you want to know immediately.

So instead of relying on someone to remember to check it, we automated the update.

AI pulls the relevant numbers, formats a short summary, and posts it in Slack. It follows the same logic behind mini AI automations: automate the repetitive part, then make the output easy for a human to use.

Not a dashboard with ten charts. Not a memo nobody reads. Not a raw data dump.

Just the metric, the comparison, and a plain-English note about what changed.

That’s the point.

AI isn’t “running the business” here. It’s protecting the operating rhythm around one number that matters. It is really an example of building AI-operable systems instead of relying on isolated prompts.

Why this works better than another dashboard

Dashboards are passive.

They wait for someone to remember to check them.

A daily AI report is active.

It shows up on its own.

That small difference changes behavior.

A metric buried in a dashboard competes with everything else on someone’s list. A metric that lands in Slack becomes part of the daily environment. It stays visible. It stays discussable. It has a better chance of shaping decisions while there’s still time to do something about it.

Most businesses don’t fail from a lack of information.

They fail because the right information never becomes part of the operating cadence.

The best system is usually the one people actually see, trust, and use.

For one team, that might be Slack. For another, email, a text summary, a Notion page, or a morning note in a leadership channel.

The channel matters less than the habit.

Start with one KPI, not a reporting empire

If you want to build something like this, don’t start by monitoring everything.

Start with one KPI that genuinely matters.

A good test is simple:

If this number moved against you for two weeks and nobody noticed, would that create a real business problem?

If the answer is yes, you’ve got a candidate.

Depending on the business, that KPI might be:

• CAC
• 90-day LTV
• Churn
• Gross margin
• Fill rate
• Conversion rate
• Inventory weeks on hand
• Average order value
• Contribution margin by channel

The right KPI is not the one that sounds smartest in a meeting.

It’s the one that changes your decisions.

That’s the number worth putting in front of the team every day.

What the report should actually include

A useful daily AI report should be short enough to read in under a minute.

At minimum, it should answer three questions:

1. What happened?
   Show the current number.

2. How does it compare?
   Show yesterday, last week, or the relevant baseline.

3. Why does it matter?
   Add one line of plain-English context.

For example:

CAC-to-90-day-LTV today: 2.8x
7-day average: 3.1x
Driver: higher paid social CAC while repeat purchase rate held flat
Action: watch closely if this trend continues

That’s enough.

The goal is not a polished memo.

The goal is to reduce friction, keep the number visible, and catch drift early.

The hidden value is discipline

The obvious benefit of this kind of system is speed.

The less obvious benefit is discipline.

Once the report exists, the business has a daily moment of truth.

Nobody has to remember to pull the numbers manually. Nobody has to stitch together an update from four tabs. Nobody gets to say, “I hadn’t looked at that in a while.” I wrote recently in what you’re really avoiding isn’t the work about how visibility lowers the friction around hard operational work. The same thing happens here.

That sounds boring. It is boring.

But boring is underrated.

A lot of expensive business problems start small:

• a metric slips a little
• the slip gets rationalized
• the team waits for more data
• the delay becomes normal
• the habit becomes a miss

A daily AI report interrupts that sequence.

And in an operating business, earlier is usually cheaper.

The part people skip: the basics

This is where a lot of AI projects go sideways.

People get excited about prompts, agents, and automation before they’ve handled the operating basics.

Those basics matter more than the tooling:

• Is the KPI defined clearly?
• Is there one trusted source of truth?
• Does the report arrive at the same time every day?
• Is it short enough that people will read it?
• Is there a clear owner when the number moves the wrong way?
• Is there a threshold that triggers action?

If those basics are weak, AI doesn’t fix the process.

It scales the mistake.

A broken reporting process with AI attached can feel sophisticated while making the business slower and sloppier. The number gets delivered every day, but it’s the wrong number, the wrong definition, or the wrong interpretation.

That’s worse than no automation.

AI should strengthen a clear operating system, not cover up a messy one. That is also why making the right context easy to surface matters so much: retrieval only helps when the underlying source of truth is clear.

A simple setup any operator can copy

If you want to build this, keep it simple.

1. Choose one KPI

Pick the number that matters most right now.

2. Define the source of truth

Make sure the report pulls from one reliable place, not three competing versions of reality.

3. Decide the comparison window

Use yesterday, a 7-day average, last week, or target. Pick the benchmark that helps people make better decisions.

4. Keep the output tight

One metric. One comparison. One short explanation. One action note if needed.

5. Deliver it where the team already works

Slack is great if that’s where attention lives. If not, use the place people already check.

6. Add an action rule

If the KPI crosses a threshold, who gets pulled in? What gets reviewed? What decision gets made?

That’s the system.

You do not need a giant AI initiative to make this useful.

You need a reliable loop around one important business number.

The broader takeaway

The best AI workflows in an operating business are usually not the flashy ones.

They are the ones that quietly keep the company close to reality.

They make it harder to miss the obvious. They reduce the lag between signal and response. They protect attention around the basics.

And the basics matter more than people want to admit.

Most businesses don’t lose because they lacked advanced tools.

They lose because they stopped watching the number that would have told them something important was changing.

So the useful question is not:

How can AI help with everything?

It’s this:

What is the one number this business cannot afford to stop watching?

Start there.

Then use AI to make forgetting it much harder.

Reader exercise

Take 10 minutes and write down:

• the one KPI that matters most in your business right now
• where that number currently lives
• how often it is actually checked
• who needs to see it
• what should happen if it moves the wrong way

Then answer one final question:

What is the simplest daily AI report that would make this number hard to ignore?

If you can answer that clearly, you’re probably closer to a useful AI workflow than you think.

First the commute. Then the device. Then the office.

Now the next shift is starting to emerge: bring your own agent.

Ten years ago, bring your own device was a workplace trend. Employers increasingly expected people to have their own phone, their own laptop, and their own hardware wrapped into the company’s workflow.

Then remote work pushed the idea further. For a lot of people, it effectively became bring your own office. Your internet. Your desk. Your extra monitor. Your spare bedroom. Your heat. Your coffee. The company still got the output, but more of the working environment moved onto the employee.

If you go back even further, you can find older versions of the same pattern. In some industries, even getting to work used to be part of the system. Over time that became your car, your gas, your commute, your problem.

That is why bring your own AI matters.

Not because it is a catchy acronym, but because it fits a long-running pattern: productive assets keep moving outward from the company and into the hands of the worker.

And unlike a laptop or a phone, an agent stack is not just a tool. It is accumulated capability.

This is more than “use ChatGPT at work”

A lot of people still think AI adoption means opening a chatbot and asking it a few questions.

That is the beginner version.

The real edge starts when someone builds a private operating system around their work:

• prompt libraries refined over months
• little scripts that clean data, generate reports, or move work between tools
• retrieval systems and notes that give the model better context
• review workflows for checking accuracy, tone, and quality
• persistent agents that can wake up, monitor things, and keep moving
• multi-agent setups where different models play different roles

That stack compounds.

I’ve written before about how I use AI to write and publish blog posts and about building AI-operable systems instead of isolated prompts. The same pattern keeps showing up: the value is rarely in one prompt. The value is in the system around it.

When somebody builds that system on their own time, on their own machine, with their own habits and history baked into it, they are not just bringing labor to a company anymore.

They are bringing infrastructure.

The moat is not the model. It is the context.

This is where bring your own agent gets much more interesting than bring your own software.

Software licenses are easy to understand. A company can buy a seat and hand it to anyone.

An agent stack is different because the most valuable part is often personal.

The memory lives in your account. The prompt files live in your folders. The judgment about how to scope a task, which tools to call, what good output looks like, and how to audit the result lives in a thousand small decisions you have already made.

Even the context itself becomes an asset.

A personal AI system gets better when it has access to your notes, your past work, your frameworks, your examples, your definitions of quality, and the patterns you have trained yourself to follow. That is part of why I built a personal knowledge base over everything I’ve made. The context is not a side detail. It is the advantage.

That creates a strange boundary.

If an employee becomes dramatically more productive because of a personal agent stack, how much of that should transfer to the employer? Should the company expect access to the whole system? The prompt library? The memory? The scripts? The evaluation harnesses? The accumulated context?

That is not a normal software procurement question. It starts to look more like asking someone to show up with their own miniature company attached.

In software, this is already happening

The clearest example is coding.

A growing number of AI-assisted developers are no longer staring at code in the old way all day. They are orchestrating systems that can:

• write code
• explain code
• edit code across multiple files
• run tests and interpret failures
• audit for security, style, and performance
• generate documentation
• compare different implementation paths
• review each other and challenge each other

I’ve written about persistent agents needing a heartbeat and about adversarial agents improving the quality of creative and analytical work. Once you start using these systems seriously, it stops feeling like one person with one tool and starts feeling like one person directing a small team.

That matters.

Because when a company hires that person, it is not only hiring judgment and taste. It is hiring the ability to mobilize an entire stack of capability on demand.

And this is not going to stay inside software.

Marketing teams will bring campaign-generation systems. Salespeople will bring prospecting and follow-up agents. Operators will bring reporting workflows. Researchers will bring literature-review agents. Writers will bring editorial pipelines. Scientists will bring experiment design and analysis harnesses.

Whatever the domain is, the pattern is the same.

The worker who knows how to build and run agents does not arrive alone.

Better systems create an awkward compensation problem

From the worker’s side, this is obviously powerful.

If one person can produce the output of five or ten people because they have better systems, that is a real hiring advantage. It creates independence. It creates negotiating power. It changes what one person can realistically promise to deliver.

But from the employer’s side, it creates a compensation problem.

If an employee brings 10x output but gets paid on a normal salary band, most of that upside is captured by the company.

And in many cases the worker is paying part of the bill.

They may be covering model subscriptions. They may be covering API costs. They may have spent hundreds of hours building the prompts, scripts, notes, and workflows that make the system useful. They may even be floating the cost for a while and getting reimbursed later, imperfectly, or not at all.

That is what makes BYOA different from an ordinary productivity tip.

What looks like a simple efficiency story is also a story about ownership.

Who paid to build the system? Who owns the context? Who keeps the prompts? Who captures the gains?

BYOA fits freelancing better than salaried work

This is why I think bring your own agent will push more people toward freelancing, consulting, and one-person businesses.

If your real moat is a personal stack of AI systems, then selling outcomes starts to make more sense than selling hours.

A freelancer can say: here is the result, here is the speed, here is the quality, and here is the price.

That framing fits AI-powered work much better than a salary band does.

It also gives the worker a cleaner way to protect the asset.

Instead of donating their entire operating system into an employer’s workflow, they can keep the system private and sell the output. They can price in the tooling costs. They can improve the stack over time and keep more of the upside for themselves.

This does not mean normal jobs disappear overnight. But it does mean the center of gravity shifts.

If companies are trying to hire fewer people and get more output from each one, and if high-performing workers are building private agent systems that dramatically raise what they can do, the natural meeting point is not always full-time employment. Often it is some form of entrepreneurial freelancing.

That may end up being one of the most important second-order effects of AI at work.

Companies should get ahead of this now

Most businesses are still treating AI adoption like a tooling question.

Should we buy seats? Which model should we use? What policy should we write?

Those questions matter, but they are not the whole thing.

The deeper questions are organizational:

• What should be company-owned versus worker-owned?
• Are employees expected to use personal agent stacks?
• If so, who pays for them?
• If someone builds a workflow that makes them radically more productive, how should that show up in compensation?
• Should critical workflows live in personal accounts and private folders at all?
• What happens when the most productive person on the team leaves with the entire system in their backpack?

Those questions are going to get louder.

Because BYOA is not just a work habit. It is a form of capital formation at the edge of the company.

The employee is accumulating productive assets outside the business, then deciding how much of that power to rent back in.

The shift nobody is naming yet

Bring your own device felt normal. Then bring your own office started to feel normal. Bring your own agent sounds strange today, but probably not for long.

The people who will create outsized value over the next few years will not just be good at AI.

They will know how to build agents, manage context, collect tools, define evaluation loops, and orchestrate systems that keep getting better.

In other words, they will have built a private factory for thought work.

That is an amazing opportunity for workers.

It is also a warning sign.

Because if people are expected to show up with their own devices, their own office, and now their own agent infrastructure, the obvious next question is this:

Why rent all of that capability to an employer at a discount?

The real question is not whether people will bring their own agents to work.

It is who pays for them, who owns them, and who captures the upside when they do.

It isn’t a new notebook, a better calendar, or a more elaborate morning routine either.

It’s having someone ask good questions on a regular basis.

That’s the real value of executive coaching. A good coach helps you decide what matters, pushes back when your priorities drift, notices your patterns, and creates enough accountability that you actually follow through.

The problem is that real executive coaching is expensive. Really expensive.

For a lot of founders, operators, and ambitious people working on their own stuff, it’s hard to justify spending thousands of dollars for occasional calls, even if the upside is obvious.

So I started with a simple question: what if AI could deliver even 20% of the value?

Not by pretending to be a perfect human executive coach. Just by handling some of the repeatable parts well enough to matter.

What I actually wanted from a coach

I wasn’t looking for motivational speeches.

I wanted help with the things that quietly break productivity over time:

• picking the wrong priorities for the day
• letting uncomfortable tasks slide for too long
• spending time on interesting work instead of important work
• losing sight of quarterly goals in the chaos of a normal week
• repeating the same self-defeating habits without noticing

A strong coach is useful because they create a rhythm around all of this. There’s a cadence. A check-in. A follow-up. A little bit of pressure. A little bit of perspective.

That seemed reproducible.

The first step was research, not code

Before building anything, I asked AI to go research executive coaching properly.

Not the vague internet version. The actual practice.

I had it pull together material on:

• coaching best practices
• common question frameworks
• behavioral science and accountability research
• how executive coaches structure sessions and follow-up
• the difference between good coaching and generic advice

What came back was a much more structured picture than I expected. The useful parts of coaching are not mysterious. A lot of it comes down to repeatable practices:

• daily check-ins
• honest prioritization
• regular self-scoring and reflection
• end-of-day accountability
• weekly and quarterly reviews
• pattern recognition over time

That became the foundation for the system.

What made it work was not the intelligence. It was the design.

The breakthrough wasn’t simply “build a chatbot.”

Plenty of chatbots are smart enough to answer questions. That is not the hard part.

The hard part is creating the conditions where accountability feels real.

Three design choices mattered a lot.

1. It had to live in chat

I already knew from building other systems that a normal chat interface has a very different feel from opening a blank browser tab.

If something lives in Telegram, it comes with you. It’s on your phone. It’s in the same place as real conversations. You don’t have to remember to open the app that is supposed to help you. It shows up where you already are.

That sounds minor. It isn’t.

A lot of self-improvement software fails because it depends on you having enough discipline to go use it at exactly the moment you’re least likely to want to. If you’re avoiding something, you’re not going to voluntarily open the accountability dashboard.

A message in chat changes that dynamic.

2. It had to be proactive

This was the second big insight. The system couldn’t just wait for me to ask a question.

It needed a heartbeat.

I’ve written before about how persistent agents become more interesting when they can wake themselves up and check in rather than sitting dormant between prompts. That’s the same idea I covered in Let’s Talk About the Open CLAW in the Room. The value isn’t just intelligence. It’s continuity.

So I built the coach around proactive outreach:

• a morning stand-up
• occasional midday follow-up when something time-sensitive was mentioned
• an end-of-day recap
• scoring and reflection
• longer review cycles over time

That one change made the whole thing feel less like software and more like a process.

3. It had to remember

Without memory, a coaching bot is just a clever prompt.

With memory, it starts to become useful.

A real coach remembers what you said last week. They remember the thing you promised to do and didn’t do. They notice when the same excuse keeps showing up in a different form.

That memory layer ended up being one of the most important parts of the whole system. It let the coach connect today’s priorities to older conversations, recurring friction, and longer-term goals.

That’s when the pushback started getting good.

What the conversations actually look like

Most mornings start with a simple stand-up:

What are the three most important things today?

That’s not a revolutionary question. But it becomes powerful when something is going to ask you about it later.

Sometimes the coach just captures the plan. Sometimes it pushes back.

If I list something that should obviously be delegated, it asks why I’m still doing it myself.

If I fill the day with low-value tasks, it asks whether any of them are actually connected to revenue or the highest-leverage goal.

If I keep postponing something important, it notices.

And the memory makes the confrontation sharper than I expected.

It can say things like:

• this is the second time you’ve pushed off writing that marketing email
• you keep making room for side projects when the main project still needs attention
• you said this meeting was important yesterday, so what changed?

That kind of feedback is useful because it cuts through the story you tell yourself in the moment.

I’ve written before that goals work better when they turn into measurable daily actions. This system effectively enforces that translation every day. Big intentions have to become concrete commitments.

The surprising part: even AI can create accountability

This is the part that surprised me most.

On paper, it sounds silly. It’s just software. It’s not a real human being. Why should it create any accountability at all?

But accountability is not only about authority. It’s also about having a witness.

Once the coach lives in a real chat, checks in proactively, follows up later, and complains a little when you ignore it, the interaction starts to create social pressure. Not the same pressure as a great human coach, obviously, but enough to change behavior.

That matters.

Because a lot of productivity problems are not really knowledge problems. They’re avoidance problems. They’re friction problems. They’re “I know what I should do, but nobody is making me face it” problems.

That’s very similar to the pattern I wrote about in What You’re Really Avoiding Isn’t the Work. The obstacle is often not inability. It’s the gap between knowing and doing.

A coaching loop helps close that gap.

It also taught me something about my own habits

The strongest value wasn’t just that the coach reminded me to do things.

It showed me my patterns.

The same weak spots kept coming up:

• a tendency to drift toward side projects
• reluctance to delegate certain work
• the habit of postponing tasks that feel important but uncomfortable
• confusing activity with meaningful progress

That sort of pattern recognition is useful because it turns vague guilt into something concrete.

Once a behavior gets named, it becomes easier to interrupt.

That is where this starts to overlap a little bit with therapy or journaling. Not because the bot is a therapist, but because repeated reflection makes your own habits harder to ignore.

And if you are trying to build structure into your work, that kind of reflection compounds over time. I’ve written about the importance of creating structure and the need for small daily wins to maintain momentum. This system is basically a machine for both.

From a pile of scripts to a real product

I ran the first version as a bundle of scripts on my own computer for several weeks.

It was rough, but it worked.

Under the hood it combined three things:

• coaching research and prompting
• a memory system
• proactive messaging throughout the day

That was enough to prove the concept.

Once I saw the benefit personally, it became obvious that it should turn into a real application. Part of the reason is practical: if a coaching system is going to be proactive, something has to stay running. There needs to be a process alive in the background checking time, tracking context, and deciding when to reach out.

So I rebuilt it as an installable desktop app.

That turned into its own fun little experiment. At one point I had AI migrate the application into Rust in basically one shot. I don’t know Rust, which made that entertaining, but the result is that the app now compiles cleanly into native desktop software and lives in the taskbar like a normal application.

It runs on Mac and Windows. No server required on my side. Users bring their own API key, which keeps the economics simple and avoids the usual problem of somebody burning through shared credits.

Where I think the value actually is

I don’t think this replaces a great human executive coach.

A great coach can read nuance better, challenge you more deeply, and bring lived experience that software cannot fully match.

But that’s not the standard that matters.

The real question is whether a persistent AI coach can deliver enough value to justify existing.

I think the answer is clearly yes.

If a human coach costs hundreds of dollars an hour and maybe shows up once a week, there is a large middle ground between “nothing” and “premium executive coaching.” A system that asks strong questions every morning, follows up in the afternoon, remembers your patterns, and keeps your priorities honest can be enormously valuable even if it only captures part of the full experience.

Personally, I think I’m going to get far more than $49 worth of value out of it just from better prioritization and fewer days lost to drift.

If this sounds useful, it’s available now

After running it for weeks, I decided to make it available as a real product.

It’s called AI Executive Coach, and it’s available here:

Read the full AI Executive Coach page here.

For the first 100 users, it’s a one-time purchase of $49.

That’s intentionally simple. No server dependency on my end. No complicated subscription decision upfront. Just install it, add your own API key, and use it.

If you’re the kind of person who knows what to do but still benefits from having someone, or something, force a little honesty into the day, you’ll probably get it immediately.

Final thought

The biggest thing executive coaching provides is not advice.

It’s cadence.

Someone asks what matters. Someone checks whether it happened. Someone notices the pattern when it doesn’t.

That loop is expensive in human form. It doesn’t have to be expensive in software.

And for a lot of people, that may be enough to make the difference between a day that felt busy and a day that actually moved something forward.

Lesson 1: Google Always Catches Up

In 2014, my Automatic Blog Machine product was making money. Article spinning worked. Keyword stuffing worked. Building a hundred sites with rotated content and pointing links between them worked. For about six months.

Then Google’s Panda update got smarter, and everything I’d built evaporated. Rankings disappeared overnight. Revenue went to zero. The sites were worthless.

Every generation of programmatic SEO has its version of this story. Somebody finds a technique that games the algorithm, it works for a while, and then Google closes the loophole. Article spinning died. Exact-match domain networks died. Private blog networks died. Thin template pages with swapped city names and nothing else — those died too.

The lesson isn’t that Google is unbeatable. It’s that any approach built on fooling the algorithm has an expiration date. The only programmatic SEO that survives long-term is the kind that would still make sense if Google didn’t exist — pages that people actually want to read.

Lesson 2: The Quality Bar Keeps Rising

What counted as “good enough” in 2014 would get you penalized today. And what’s acceptable today will probably look thin in three years.

In the article spinning era, uniqueness was the bar. If the text didn’t trigger a duplicate content check, it was “good enough.” Nobody was reading these pages — they existed to rank, not to serve readers.

In the template era, usefulness was the bar. If the page had real data — actual business listings, real product specs, genuine local information — it could rank even with a formulaic template. The information was valuable even if the presentation was boring.

Now, in the AI era, the bar is comprehensive quality. The page needs real data, good writing, proper formatting, useful structure, internal links, and a design that doesn’t scream “this was generated.” Readers expect the same quality from a programmatic page that they’d expect from a hand-written one.

This isn’t Google being arbitrary. It’s reflecting what users actually want. Every time people complain about search quality — and they complain a lot — Google tightens the screws. The sites that survive each tightening are the ones that were already over-delivering on quality.

The practical takeaway: build to a quality standard that’s higher than what currently ranks. If the top results for your target query are mediocre, don’t match them — beat them. That margin is your insurance against the next algorithm update.

Lesson 3: Small Sites Can Win Specific Niches

The biggest misconception about programmatic SEO is that you need to be Yelp or Zapier to succeed. You don’t. Those companies succeed because they operate at massive scale across broad categories. But scale and breadth aren’t the only ways to win.

Small, focused sites win by going deeper than the big players bother to. A mega-site might have a page for “plumbing in Austin” but it won’t have a page about Austin’s specific water hardness regulations and what they mean for residential plumbing maintenance. That level of specificity is where the opportunity lives.

The best small-site programmatic SEO projects share three traits:

Deep niche expertise. The creator knows the subject well enough to spot what’s missing from existing content. They’re not just generating pages — they’re filling genuine information gaps.

Specificity that big sites can’t match. A large directory has breadth but not depth. They can’t afford to write 2,000-word deep dives for every long-tail variation. You can — especially with AI handling the research and drafting.

Willingness to maintain and update. Most programmatic sites get published and abandoned. The ones that win long-term keep their data fresh. If your competitor pages reference 2023 pricing, update yours to 2026 pricing. If a local regulation changed, update your city page. This sounds obvious, but almost nobody does it.

Lesson 4: Internal Linking Is the Multiplier

I underestimated internal linking for years. Then I saw the data.

A set of programmatic pages with no links between them behaves like a hundred isolated blog posts. Google crawls them independently, doesn’t understand the relationship between them, and treats each page as a standalone piece of content competing on its own merits.

The same set of pages with intentional internal linking becomes a content hub. Google understands the topical relationship. Authority flows between pages. When one page ranks well, it lifts the others. The whole is genuinely greater than the sum of its parts.

For programmatic SEO specifically, the linking structure should be systematic:

• Every page links to the hub — the main topic page that anchors the entire collection
• Related pages link to each other — city pages in the same state, comparison pages in the same category, FAQ pages on related topics
• The hub links to its best-performing spokes — as you learn which pages rank, link from your strongest page to support the weaker ones
• External content links in too — your blog posts, your about page, your other site content should all link to relevant programmatic pages

When I added systematic internal linking to a set of pages I’d published months earlier, some of them jumped from page 3 to page 1 within weeks. The content hadn’t changed. The links made Google understand what it was looking at.

Lesson 5: Failures Teach More Than Successes

I want to be honest about the projects that didn’t work, because the failure modes are instructive.

The 10,000-page experiment (2024). After writing about programmatic SEO as a concept, I decided to test it at scale. Build a large site, publish thousands of pages, see what happens. The content was AI-generated with some data enrichment, but the quality was inconsistent. Some pages were genuinely useful. Many were thin. Google’s March 2024 core update hit the site hard. Traffic dropped 70% in a week. The lesson: volume without consistent quality is a liability, not an asset.

The comparison site (2023). I built a site with product comparison pages using early ChatGPT-generated content. The information was plausible but not always accurate. Some product features were hallucinated. Some pricing was wrong. Readers complained in comments. Google noticed the bounce rates. The site never gained traction. The lesson: AI content without real data sourcing produces pages that look right but aren’t. Readers can tell.

The directory that worked (2025). On the other hand, a small directory project — fewer than 100 pages — that aggregated genuinely hard-to-find local information performed well from day one. Each page took longer to produce because the data required real research. But because the information wasn’t available elsewhere in a consolidated format, the pages ranked quickly and stayed ranked. The lesson: less content, more value per page, wins.

The pattern across every failure was the same: I prioritized quantity over quality. Every success came from the opposite decision.

Lesson 6: The Maintenance Problem Is Real

Here’s something nobody talks about in programmatic SEO guides: what happens after you publish?

Content decays. Prices change. Businesses close. Regulations update. Links break. Data goes stale. A page that was accurate when you published it becomes misleading six months later — and misleading content eventually gets outranked by something fresher.

For hand-written blog posts, this is manageable. You have 50 posts, you review them periodically, you update what’s outdated. For 500 programmatic pages, the maintenance burden is significant.

The solutions I’ve found:

Build refresh into the pipeline. If your data comes from scrapeable sources, schedule regular re-scrapes. Have the AI compare new data to old data and flag pages that need updates. Automate the parts that can be automated.

Prioritize maintenance by traffic. Not every page needs to be updated on the same schedule. Your top 20% of pages by traffic deserve monthly reviews. The rest can be quarterly or annual. Focus your attention where it has the most impact.

Design for easy updates. If your page template separates structured data from narrative content, updating the data is easy — just refresh the numbers. If every fact is buried in flowing prose, updating requires rewriting paragraphs. Think about maintainability when you design your template.

Remove pages that can’t be maintained. If a category of pages depends on data you can no longer source reliably, it’s better to remove those pages than to let them go stale. A smaller, accurate site outperforms a larger, unreliable one.

Lesson 7: AI Changed Everything (But Not How You Think)

The biggest shift in programmatic SEO isn’t that AI can write content. It’s that AI can do research.

Content generation was always the easy part. Even before AI, you could spin articles, fill templates, generate text. The hard part was getting accurate, specific, useful information for each page. That required actual research — visiting sources, extracting data, cross-referencing facts, understanding context.

What’s different now is that AI agents can do that research at scale. Claude Code can browse the web, read source documents, extract specific data points, and compile them into structured content — for every row in your spreadsheet. That’s not just faster writing. That’s faster research, which was always the bottleneck.

This changes the economics completely. A project that would have required weeks of manual research to populate with real data can now be researched in hours. The constraint shifts from “can I gather enough information?” to “is this information worth publishing?”

But here’s the nuance: AI research still needs human judgment. The AI doesn’t know which sources are trustworthy for your niche. It doesn’t know when a fact is technically accurate but misleading in context. It doesn’t know the difference between a useful page and a page that merely looks useful. That judgment is still yours — and it’s what separates programmatic SEO that works from programmatic SEO that gets penalized.

Where This Is All Heading

Three trends are shaping the future of programmatic SEO:

AI search is changing the game. Google’s AI Overviews, ChatGPT’s search, Perplexity — these tools synthesize information from across the web and present it directly to the user. If an AI can answer the query by reading your page and summarizing it, the user might never visit your site. This means programmatic pages need to offer something beyond summarizable facts — interactive tools, downloadable resources, visual comparisons, or depth that can’t be condensed into a snippet.

E-E-A-T matters more than ever. Google’s emphasis on Experience, Expertise, Authoritativeness, and Trustworthiness is a direct response to the flood of AI-generated content. Sites with a real author, real expertise, and real experience behind them get preferential treatment. For programmatic SEO, this means connecting your template pages to your broader brand — author bios, links to your other work, evidence that a real person stands behind the content.

The bar for “unique value” keeps climbing. Aggregating publicly available information into a cleaner format used to be enough. Increasingly, the winning programmatic sites add something genuinely new — original analysis, proprietary data, interactive tools, expert commentary layered on top of the aggregated data. The template is just the delivery mechanism. The unique value is what gets the page ranked.

The Only Rule That Never Changes

After a decade of building, failing, rebuilding, and occasionally succeeding at programmatic SEO, one principle has held constant through every algorithm update, every technology shift, and every competitive wave:

If the page helps the reader, it will eventually rank. If it doesn’t, it eventually won’t.

Every technical decision — the template structure, the data sources, the publishing pace, the internal linking, the AI tooling — is in service of that one question. Would a real person find this page useful?

Build for that standard, and the algorithm updates become opportunities instead of threats. The sites that survive Google’s crackdowns are always the ones that were building for readers, not for robots.

The tools have never been better. AI can research, write, and publish at a scale that was unimaginable even two years ago. But the strategic question is the same one it’s always been: are you creating something of value, or are you just creating more noise?

If you’ve read all three posts in this series, you have everything you need to answer that question for yourself. Start with the concept. Build with the simplest approach that works. And keep the long view in mind — because the sites that win in programmatic SEO are the ones that are still useful five years from now.

For more on building AI-powered content workflows, check out how I use AI to write and publish blog posts. And if you want to see the original post that started this whole series, that’s here.

But knowing what it is and actually building it are different things. Most guides jump straight to complex tech stacks — custom databases, headless CMS platforms, expensive plugins — and lose 90% of readers before they publish a single page.

The reality in 2026 is that AI has collapsed most of those steps. You don’t need to manually copy-paste pages from a spreadsheet. You don’t need to learn a page builder plugin. You can start with an AI assistant, a WordPress site, and a clear idea of what pages you want to create.

Step 1: Let AI Build Your Data Set

Every programmatic SEO project starts with a list of pages. The old advice was to sit down with a spreadsheet and fill in rows by hand. That still works — but why would you?

Instead, start by telling an AI assistant what you’re trying to build. Be specific about your niche and what kind of pages you want. For example:

“Give me a list of 50 cities in Texas with populations over 50,000, along with their county, population, and top three industries.”

Or: “Research and list every competitor in the meal prep delivery space, with their pricing, delivery areas, and key differentiators.”

Or: “What are the 30 most common questions people ask about home solar installation, organized by stage of the buying process?”

The AI generates your seed data in seconds. Export it to a Google Sheet or CSV file, and you’ve got the skeleton of your project. Each row is a potential page. Each column is a variable that changes between pages.

Here’s where the multiplication happens. Say you have 20 cities and 5 services. That’s 100 potential pages — “[service] in [city]” — generated from two simple lists. Add industries, and you’ve got another dimension. The data set grows fast.

Keep a local copy of everything. Download your research, cache your data sources, save reference material to your computer. You don’t want to re-fetch the same information every time you work on the project. A local folder with your spreadsheets, source documents, and reference data becomes your project’s knowledge base.

Step 2: Design Your Template

Before you generate a single page, you need to know what a good page looks like. This is the most important step, and it’s worth spending real time on.

Pick one row from your data set — one city, one product, one question — and build the best possible page for it. Not blindly with AI. By hand. Think about what someone searching for that query actually wants to know, and make sure the page delivers it. Your pages need to be good enough that people stay and read.

This manual page becomes your template. Study it:

• What headings did you use?
• What data points appear on every page versus what’s unique?
• How long does it need to be to genuinely answer the question?
• What internal links connect it to related pages in your set?

Once you’re happy with the template, describe it clearly — the structure, the sections, the tone, what goes where. This description becomes your prompt for generating every other page.

Step 3: Establish Your Brand Guide Early

This is something most programmatic SEO guides skip entirely, and it’s why so many pSEO sites feel like they were stamped out of a factory.

Before you generate content at scale, decide on your brand voice and visual identity. Write it down. These decisions are hard to change later, and consistency is what separates a site that feels trustworthy from one that feels like spam.

For writing voice, decide:

• First person or third person?
• Authoritative and expert, or friendly and conversational?
• Technical language or plain English?
• What phrases or patterns does your brand use? What does it avoid?

Feed this brand guide to your AI as context for every page it generates. The difference between “write a page about solar installation in Austin” and “write a page about solar installation in Austin using this voice guide” is enormous. Without it, every page will sound like generic AI output. With it, they’ll sound like they came from the same knowledgeable author.

For visual identity, decide:

• What style of images will you use? AI-generated, stock photos, custom graphics?
• Pick a specific image style and dial in the prompt so it’s consistent across all pages
• Choose a color palette and typography that carries through the site
• Decide on a layout template before you start publishing

Spend an afternoon getting your image generation prompt right. Test it on 5-10 variations and make sure the results feel cohesive. A site where every hero image looks like it belongs to the same brand signals quality. A site where every image looks randomly generated signals the opposite.

Step 4: Generate and Publish With AI

Here’s where modern tools change the game entirely. You don’t need to manually create pages one by one, and you don’t need an expensive import plugin to do it for you.

An AI coding assistant like Claude Code can take your spreadsheet, your template, and your brand guide and do the heavy lifting:

1. Research each row — For every entry in your data set, the AI can search the web, pull real information from multiple sources, and compile facts that are specific to that page. A page about “plumbing services in Austin” shouldn’t contain generic plumbing advice — it should reference Austin’s actual building codes, local licensing requirements, and water quality specifics.
2. Write the content — Using your template structure and brand voice, the AI drafts each page. Because it’s working from real research rather than generating from memory, the content is grounded in verifiable facts.
3. Publish directly — Tools like the WordPress REST API let AI publish pages directly to your site, complete with formatting, categories, tags, and featured images. No copying and pasting between tools.
4. Review each page — And this is the step you never skip. Read every page before it goes live, especially in the beginning. Check that the facts are accurate, the voice is consistent, and the page would pass the quality test from the last post: would a real person feel their time was respected?

For the first 10-20 pages, review every single one. As you get confident that your template and prompts produce reliable output, you can shift to reviewing a sample — but never stop reviewing entirely.

Start Slow, Accelerate Later

There’s a temptation to use these tools to publish hundreds of pages in a weekend. Resist it.

When a new site suddenly appears with 500 pages, Google notices. And not in a good way. A brand-new domain with a flood of content looks exactly like the kind of spam site that Google’s algorithms are designed to catch — regardless of how good the content actually is.

The better approach is to start with a handful of pages and grow steadily:

Week 1-2: Publish 5-10 of your best pages. Obsess over quality. Make sure every fact is right, every image looks good, every internal link works.

Week 3-6: Add 3-5 pages per week. Monitor which pages get indexed and start appearing in search. Pay attention to what Google seems to like.

Month 2-3: If pages are getting indexed and attracting some traffic, increase your pace. Maybe 10 pages per week. Keep reviewing quality.

Month 3+: If the signal is positive, you can ramp up further. But always tie the pace to the quality you can maintain.

This gradual approach does two things. It gives Google time to build trust in your domain. And it gives you time to learn what’s working — which page structures perform best, which topics attract traffic, and which ones fall flat. That feedback loop is worth more than a thousand pages published blind.

Picking Your First Project

The hardest part isn’t the technology. It’s choosing what to build.

Here are five proven patterns that work well for a first project, ordered from simplest to most ambitious:

1. FAQ pages for your niche. Take the 20-30 most-asked questions in your field and create a dedicated page for each one. Have AI research the best current answer for each, pulling from authoritative sources. This is the lowest-risk starting point because each page targets a specific long-tail query with clear search intent.

2. Comparison pages. “[Product A] vs [Product B]” for every meaningful combination in your space. AI can research current pricing, features, and reviews for each product. The data changes, so keep local copies and plan to refresh these periodically.

3. Location + service pages. “[Service] in [city]” combinations. This is the classic multiplication approach — 10 services across 20 cities gives you 200 pages. AI can research city-specific details (regulations, demographics, local competitors) to make each page genuinely useful rather than just swapping the city name.

4. Tool or resource directories. Curate every tool, service, or resource in a specific category. AI can research pricing, features, and user reviews from across the web, then present it in a consistent format. The value is in the consolidation — saving the reader from visiting 30 different websites.

5. Data-driven analysis pages. Turn public datasets into readable insights. Government databases, industry reports, and public APIs contain enormous amounts of information that nobody has bothered to make accessible. AI can process raw data and present it in plain language for specific audiences.

Pick one. Build 10 pages. See what happens.

Common Mistakes to Avoid

Having tried (and failed at) programmatic SEO more than once, here are the mistakes that kill projects:

Starting too big. Don’t plan 1,000 pages before you’ve proven 10 work. Build the smallest possible version, see if it gets traffic, then scale what works.

Skipping the brand guide. Without a consistent voice and visual identity, your site will feel like a content farm even if the information is good. Invest the time upfront.

No quality review. Publishing AI-generated pages without reading them is how sites get penalized. Review every page early on. Spot-check as you scale. Never publish blind.

Thin content. If your template produces pages with 200 words of generic text and a data table, that’s not enough. Each page needs to genuinely answer the searcher’s question. If you can’t make a page useful, don’t create it.

Ignoring internal linking. A hundred orphan pages with no links between them won’t perform. Every page should link to related pages in your set, and your set should link back to your main site content. Build the web of connections from day one.

Sloppy images. Inconsistent or obviously AI-generated images with different styles on every page undermine trust. Pick one style, refine the prompt, and stick with it across the entire site.

Going too fast on a new domain. Publishing hundreds of pages on a fresh domain in your first week is a red flag to Google. Start slow, build trust, accelerate when you see positive signals.

What to Do This Week

If this approach sounds interesting, here’s a concrete starting point:

1. Pick a pattern from the five options above that fits your expertise or business
2. Ask an AI assistant to generate your seed data — cities, competitors, questions, whatever your pattern requires
3. Build one perfect page by hand — this becomes your template and quality benchmark
4. Write your brand guide — voice, tone, image style, what to avoid
5. Search for your target queries and compare your template page to what’s already ranking

If your page is better than what’s currently out there, you’ve found your project. The tools to scale it are available right now — and most of them are free or close to it.

In the next post, I’ll share lessons from a decade of building programmatic SEO projects — what actually works long-term, what gets penalized, and where this is all heading as AI gets more capable. For more on how AI fits into content workflows, check out my AI-assisted content strategy. And if you’re a builder looking for the technical deep dive, growth engineering with Claude Code covers the pipeline side in detail.

But start with the pattern and the brand guide. Everything else follows from those two decisions.

It worked — for about six months. Then Google got smarter, the rankings disappeared, and I learned an expensive lesson about building on a foundation of trickery.

That was my introduction to programmatic SEO. And while the tools have changed dramatically since then, the core question hasn’t: can you create content at scale without it being garbage?

What Programmatic SEO Actually Is

Programmatic SEO is creating web pages using templates and data instead of writing every page by hand. That’s it. No magic, no dark art.

Think about it this way. A real estate site with a page for every neighborhood in a city — those pages aren’t hand-written. They pull from a database: median home price, school ratings, walkability score, recent sales. The template is the same, but the data makes each page unique and useful.

That’s programmatic SEO at its simplest. You define a pattern, plug in data, and generate pages that target specific search queries.

Some real-world examples that are probably already in your life:

• Yelp has a page for every “best [restaurant type] in [city]” combination
• Zapier has integration pages for every app pairing — thousands of them
• NerdWallet has comparison pages for financial products across every category
• Tripadvisor has pages for every hotel, restaurant, and attraction in every city on Earth

These aren’t hand-crafted blog posts. They’re templates filled with structured data, and they drive millions of organic search visits every month.

The Spectrum of Complexity

Here’s where people get intimidated. They hear “programmatic SEO” and picture a team of engineers building complex data pipelines. But the spectrum is much wider than that.

The simple end: A Google Sheet with 50 rows of FAQ questions, turned into individual pages on a Wix or WordPress site. Each page targets a specific long-tail search query. No code required.

The middle: A WordPress site with a template that pulls in data from a spreadsheet or simple database. Maybe you’re building city-specific landing pages for a local service, or comparison pages for products in your niche.

The advanced end: A full pipeline that scrapes data sources, enriches it with AI, generates unique content for each page, and publishes automatically. This is where tools like Claude Code come in — but you don’t need to start here.

The point is that programmatic SEO isn’t binary. You don’t need a sophisticated tech stack to benefit from the approach. You need a repeatable pattern and data to fill it.

A Decade of Cat and Mouse

My Automatic Blog Machine story isn’t unique. The history of programmatic SEO is really the history of people trying to create content at scale and Google trying to separate the valuable from the worthless.

The early era (2010-2015): Article spinning, keyword stuffing, link farms. Content was generated to game algorithms, not to help readers. Google’s Panda and Penguin updates torched most of it. My product was part of this wave, and it deserved to get squashed.

The template era (2016-2022): Smarter operators moved to database-driven templates. If you had genuinely useful structured data — business listings, product specs, local information — you could build pages that actually served a purpose. This worked better because there was real information behind each page, even if the presentation was formulaic.

The early AI era (2023-2024): ChatGPT arrived, and suddenly everyone could generate “unique” text at scale. But GPT-2 and GPT-3 era content had obvious problems. The hallucinations were rampant. There was no way to connect the model to real data sources, so it would confidently make up facts, invent statistics, and fabricate references. If you read enough AI-generated content from that period, you developed a sixth sense for it — the same vague structure, the same filler phrases, the same lack of specificity.

Some people tried to work around this. I experimented with using web search APIs to pull real content, then feeding it to ChatGPT to create summaries and rephrase things in a more natural way. It was better than pure hallucination, but still produced that unmistakable AI voice. And Google was getting better at detecting it.

Where we are now (2025-2026): This is where things genuinely changed. The current generation of AI tools — particularly agent-based systems like Claude Code — can do something the earlier models couldn’t: go out on the internet, find ten real references for every claim, consolidate and synthesize that information, and present it in a way that actually helps the reader.

That’s a fundamentally different value proposition than spinning synonyms or generating hallucinated text.

The Real Turning Point

Here’s the thing that changed my mind about programmatic SEO after years of skepticism.

When you can connect AI to real data sources — web scraping, APIs, databases, live search results — you’re not faking content anymore. You’re doing genuine research at scale. The AI becomes a research assistant that can:

• Pull together information from dozens of sources for a single page
• Take complicated language (legal documents, scientific papers, technical specs) and rephrase it for different audiences
• Cross-reference facts across multiple sources to reduce hallucination
• Tie together related concepts in ways that would take a human researcher hours

Could someone get this information by doing a Google search themselves? Maybe. Could they have a conversation with an AI chatbot and get similar answers? Possibly. But if the value you’re providing involves pulling together many sources, consolidating scattered information, and presenting it in a clear format — that’s real work, even if a machine is doing it.

Think about a directory site that aggregates local business information from public records, review sites, and social media — then presents it in a clean, searchable format with plain-language summaries. That’s providing genuine value. The information exists on the internet already, but it’s scattered across dozens of sites in inconsistent formats. Consolidating it is the service.

Or consider taking dense regulatory documents and creating simple, city-specific guides for small business owners. The source material is public, but it’s written in legal language that most people can’t easily parse. Making it accessible is the value.

When Programmatic SEO Is Worth It

Not every site or business benefits from this approach. Here’s a honest framework for deciding.

It’s probably worth exploring if:

• You can identify a clear pattern of search queries (like “[thing] in [place]” or “
  • 

    AI Executive Coach

    $49.00 Add to cart
  vs
  • 

    AI Executive Coach

    $49.00 Add to cart
  “)
• Structured data exists that could populate those pages (public databases, APIs, scraped information)
• Each generated page would genuinely answer someone’s question
• You’re willing to invest upfront in building the pipeline, knowing the payoff is gradual
• You have some technical comfort, even if it’s just spreadsheets and a basic website builder

It’s probably not worth it if:

• Your topic requires deep original thought or personal experience on every page
• The search queries you’d target are already dominated by massive sites with real authority
• You can’t identify a repeatable template that works across many variations
• You’re only interested in tricking Google rather than helping readers
• You need results next week (programmatic SEO is a long game)

The honest truth: Most people who attempt programmatic SEO either give up before publishing enough pages to see results, or they cut corners on quality and get penalized. The sweet spot is finding a niche where you can provide genuine value at scale — and that niche is more specific than you think.

The Quality Test

Before I invest time building programmatic pages for any topic, I apply a simple test:

If a real person landed on this page from a Google search, would they feel like their time was respected?

Not “would they click around the site.” Not “would Google’s algorithm reward it.” Would an actual human being read this page and think, “Good, that’s what I needed to know”?

If the answer is yes, the approach is sound regardless of how the content was created — by hand, by template, by AI, or by some combination. If the answer is no, no amount of technical sophistication will save it. Google is remarkably good at figuring out when people are disappointed by what they find.

This is the real shift in programmatic SEO. It’s no longer about creating content that fools algorithms into thinking you’re providing value when you’re not. It’s about actually providing value — and using automation to do it at a scale that would be impossible manually.

Where to Start

If you’re curious about programmatic SEO but don’t want to build a complex pipeline on day one, start here:

1. Find your pattern. What questions do people search for in your space that follow a repeatable format? Use Google’s autocomplete, “People also ask” boxes, or a tool like AlsoAsked to spot templates.
2. Check the competition. Search for a few variations of your pattern. If the top results are from massive sites with huge authority, pick a more specific niche. If the results are thin or unhelpful, you’ve found an opportunity.
3. Build one page by hand. Before automating anything, manually create the best possible version of one page in your template. This becomes your quality benchmark.
4. Then scale gradually. Start with 10-20 pages, not 1,000. See how they perform. Adjust your template based on what works. Only then consider building automation.

The tools available today — from simple no-code builders to full AI agent pipelines — make the scaling part easier than ever. But the strategic thinking that goes into choosing what to build? That’s still on you.

I’ve written more about the technical side of building these pipelines in my post on programmatic SEO, and if you’re interested in how AI fits into a broader content workflow, take a look at how I use AI to write and publish blog posts. For the growth-minded builders, growth engineering with Claude Code gets into the deeper technical possibilities.

But honestly? Start with the pattern. Everything else follows from that.

The manual approach doesn’t scale. It doesn’t run on weekends. And it can’t simultaneously watch pricing pages, Amazon listings, product catalogs, review trends, and ad activity across five competitors at once.

That’s the problem this project set out to solve.

The Build Story

The Competitor Tracker Agent started as a personal frustration. Running a brand means constantly asking: what are competitors doing right now? Are they running a sale? Did they just launch something new? Are their reviews tanking — and is that an opening to capture market share?

The only honest answer used to be: “I don’t know, and finding out takes too long to be worth it.”

Here’s the thing — the data isn’t hidden. Competitor pricing is public. Amazon reviews are public. New product launches on Shopify stores are detectable. Google Ads transparency data is accessible. The problem isn’t access to the data. The problem is that gathering it, comparing it to what you saw last week, and then reasoning about what it means — that’s a full-time job.

So the question became: what if an AI agent could do all of that automatically?

Building small AI automations has been a recurring theme in this workflow — the insight from working on mini AI automations was that the highest-leverage moves are rarely the complex ones. You chain a few reliable steps together, automate the repetitive parts, and let the AI handle the reasoning layer. That’s exactly the architecture here.

What the Agent Actually Does

The Competitor Tracker Agent runs on a 6-hour scan cycle, 24 hours a day. It monitors four intelligence pillars:

Price Monitoring

Tracks competitor pricing across DTC websites and Amazon ASINs. Configurable thresholds mean you only get alerted when it actually matters (say, a change greater than 5%), not every minor fluctuation. It catches flash sales, coupon activity, and Buy Box changes.

Product Intelligence

Detects new product launches before they’re announced publicly. Shopify stores expose their full product catalog via a public endpoint — a new SKU showing up there at 11pm on a Thursday gets flagged immediately. Discontinuations, variant expansions, and positioning copy changes are all tracked.

Review and Sentiment Analysis

Monitors Amazon review counts and star ratings over time. When a competitor’s ratings start declining — say, dropping from 4.3 to 4.0 over 30 days — that’s a signal. It means customers are unhappy, and if you’re selling in the same category, that’s an opening. The agent surfaces these trends before they show up in your own sales data.

Ad and Campaign Monitoring

Tracks competitor advertising activity via Google Ads Transparency Center and Amazon Sponsored placements. When a competitor pivots their messaging or launches a new campaign targeting terms they’ve never used before, that signals a strategic shift worth knowing about.

The Tech Behind It

The agent is built in Python with Claude AI as the reasoning layer. Here’s the stack:

• Web scraping layer — Custom scrapers for competitor DTC sites, Shopify catalog endpoints, and Amazon product pages. Rotating request intervals to stay within reasonable limits.
• Amazon monitoring — ASIN-level tracking for pricing, review counts, BSR, and ad placements via public data and optional SP-API integration.
• Ad intelligence — SerpAPI for Google Shopping and Ads Transparency Center data; Amazon Sponsored Brands detection from search result pages.
• Claude AI for analysis — Raw data gets fed into Claude with context about what changed since the last scan. Claude reasons about whether a change is significant, what it likely means strategically, and what action to take. This is the part that makes it genuinely useful rather than just another data dump.
• Slack integration — Alerts fire within minutes of a significant change being detected. The daily briefing is a structured report generated every weekday at 8am.

The agent also maintains persistent memory across scans — tracking trends over weeks and months, not just comparing today against yesterday. That historical context is what lets it say things like “Acme’s prices are at a 6-month low” rather than just “price changed.”

This fits into a broader pattern of thinking about AI as infrastructure rather than as a one-off tool. The post on growth engineering with Claude Code explored this — when you treat AI as the reasoning engine inside a persistent automated system, you get compounding returns that a prompt-and-response workflow never will.

What the Morning Briefing Looks Like

Every weekday at 8am, a structured report lands in a dedicated Slack channel. Here’s what a typical Friday briefing looks like:

Price Intel: Acme Corp dropped Widget Pro from $34.99 to $27.99 (-20%). Flash sale, likely ends Sunday. Their lowest price in 6 months.

Product Intel: BrandX quietly added “Pro Max Bundle” to their Shopify store. Not announced publicly. $89 price point — a new premium tier.

Review Intel: No major rating changes. BrandX trending slightly down: 4.1 to 4.0 stars over 30 days.

Ad Intel: Acme Corp added 3 new Google Shopping ads this week targeting “budget widget” and “affordable widget 2026” — consistent with their price drop strategy.

Recommended Actions:

1. Consider a targeted counter-promotion this weekend while Acme’s prices are low — capture price-sensitive shoppers before they return to normal pricing.
2. Investigate BrandX’s Pro Max Bundle. If it gains traction, it could pressure mid-tier SKUs.
3. BrandX’s review decline is an opening — consider increasing PPC bids on their branded terms.

The key distinction is the recommendations section. Raw data is noise. The agent uses Claude to reason about what the data means in context and what to do about it. That’s the difference between a monitoring tool and actual intelligence.

The DIY Competitive Advantage

There’s a strong argument for building tools like this rather than buying off-the-shelf software. Enterprise competitive intelligence platforms like Crayon and Klue exist — but they’re built for B2B SaaS companies, start at $15,000+ per year, and track PR and content rather than pricing and Amazon reviews. They’re solving a different problem.

The doing-it-yourself advantage is that custom-built systems can be tuned exactly to the competitive landscape at hand. Which competitors matter. Which price changes actually warrant a response. Which product categories to watch. That specificity is what turns monitoring into actionable intelligence.

What This Becomes

Competitive intelligence at this level of depth and automation wasn’t accessible to small and mid-size e-commerce brands before. It required a dedicated analyst, an expensive platform, or a lot of manual work that was never consistent enough to be reliable.

The agent changes that calculus. Tell us who your competitors are, and we install a monitoring system tailored to your market in under two weeks. Scans run every 6 hours. Alerts arrive in real-time. The morning briefing is waiting before the team starts their day.

The parallel to building AI agent systems that handle complex, multi-step reasoning tasks is clear: the value isn’t in any single AI call, it’s in the architecture that chains intelligence together into something that runs continuously without human intervention.

Full Details and Demo

The full service page — including pricing, the complete feature breakdown, and a sample Slack report — is at mattwarren.co/competitive-intelligence.

If this is a problem your brand is dealing with, book a free 30-minute competitor audit. Walk away with a competitive landscape snapshot whether you buy or not.

I passed.

Not because it wasn’t valuable. It clearly was. But the price point was higher than I wanted to commit to, and the weekly time requirement was more than my schedule could absorb right now. So I said thanks, thought about it for about 20 minutes, and then opened Claude Code.

Here’s what I built instead.

The idea that sparked it

The coaching conversation had been happening over text. Just back-and-forth messages, advice trickling in throughout the day. What struck me about that format wasn’t the content — it was the delivery mechanism.

You don’t go get it. It comes to you.

That’s a fundamentally different experience than opening ChatGPT and typing a question. When a message shows up on your phone unprompted, your brain processes it differently. There’s a social reflex that kicks in. Someone reached out. Someone is thinking about you and your goals. Even if intellectually you know it’s a bot, the messenger app context does something to the accountability equation that a browser tab simply doesn’t.

So the question became: could an AI agent replicate that dynamic? Not just a chatbot that answers questions, but something that runs persistently, thinks about your situation in the background, and reaches out to you when it has something worth saying?

The build: research first

The first thing I did was ask Claude Code to go do research. Not write code — just go learn things. I sent it out to find scientific papers, behavioral research, and business frameworks on what actually makes executive coaching effective. What questions do good coaches ask? How do they maintain accountability? What cadences work? How do you help someone stay focused on priorities without becoming a nag?

It ran for about 20 minutes, pulling from multiple sources, organizing findings into a structured research document. The output was genuinely useful — not just “here are some coaching tips” but a breakdown of the behavioral psychology behind why coaching works, what distinguishes great coaches from mediocre ones, and the specific techniques that show up consistently in the research.

That document became the knowledge base for everything that followed.

From research to software plan

Once the research was solid, I asked it to turn those findings into a software plan. Here’s what that plan centered on:

A Telegram bot as the interface. Not a web app. Not a new chat window you have to go find. A bot that lives in your existing messaging app, alongside your other conversations, and behaves like a contact in your phone. This was non-negotiable from the start — the whole point was that the interface creates accountability, and that only works if it’s somewhere you already check.

Proactive scheduling. The research consistently highlighted a morning check-in as one of the highest-leverage interventions in any coaching relationship. What are your top three things to accomplish today? Simple question, but when asked by a person (or something that feels like a person), it creates a kind of micro-commitment that the end of the day will test. The bot would send this every morning, unprompted.

Evening accountability. Paired with the morning check-in is an end-of-day follow-up. Did you accomplish those three things? If not, what got in the way? This is where accountability becomes real. It’s easy to type your priorities and then ignore them. It’s harder when something is going to ask you about them later.

A memory system. This was the piece that made everything else worth building. A good coach remembers what you told them last week. They notice patterns. They connect what you said in January to something you’re struggling with in March. Without memory, a coaching bot is just a fancy prompt. With it, the conversations compound. I asked for a SQLite database and a system that would pull relevant context into each interaction — what goals had been discussed, what came up in recent check-ins, what had been going well or poorly.

What it does, concretely

The resulting application is straightforward in structure but surprisingly capable in practice. It runs as a persistent background process on my computer. When it starts up (configured to launch on login), it connects to Telegram and starts listening. A scheduler runs alongside it.

Every morning, before I’ve opened a browser, there’s a message waiting:

Good morning. What are your three most important things today?

I type back. The conversation might go a few exchanges. The bot has context from previous days, so it might note that one of the things I mentioned connects to a goal we discussed earlier in the week, or ask whether the thing I said was blocking me last Thursday got resolved.

At the end of the day, there’s a follow-up. At the end of the week, a slightly longer check-in. The system also has a lightweight internal process that evaluates whether anything in my recent history is worth proactively surfacing — something that’s been flagged multiple times, a deadline approaching, a thread that went quiet. Most days it decides there’s nothing urgent to interrupt with. Occasionally it sends something.

That’s the whole system. It’s not complicated. But the experience of using it is substantially different from anything I’ve tried before.

Why this actually works

Here’s the thing about accountability: it’s a social phenomenon. The research makes this clear. People keep commitments better when they feel that someone is tracking. It doesn’t matter much whether the tracker is a person, a journal, or a piece of software — what matters is the sense that your stated intentions have a witness.

Web apps and chatbots fail at this because they require you to initiate. You have to go there, open it, decide to engage with your goals. That friction is small in theory and enormous in practice. The days you need accountability most are the days you’re least likely to open the accountability app.

A Telegram bot sidesteps this entirely. It comes to you. The interface is indistinguishable from a message from a real person. On some level your brain doesn’t fully process the distinction, and that’s exactly the point.

After a few days of using this, the morning question has started to feel like a real thing I need to respond to. The end-of-day check-in has made me more honest with myself about what actually got done. I’ve written before about the challenge of maintaining focus — this is the most practical solution I’ve found.

The bigger shift

I keep coming back to one observation from this project: at the end of it, I felt like I’d hired a coach. Not built an app. Hired someone.

That reframe is worth sitting with. There’s a long history of software built around the idea of helping people with productivity, goal setting, and accountability. Most of it has failed to change behavior in any meaningful way because it treats the problem as an organizational challenge. Here’s a system to track your goals. Here’s a dashboard. Here’s a way to categorize your tasks.

What actually changes behavior is a relationship. Someone who asks how it’s going, remembers what you said, and expects you to show up. Software has historically been incapable of this because it’s reactive — it waits for you.

The combination of a persistent agent, a messenger interface, and a memory system produces something that isn’t quite software and isn’t quite a relationship. It’s something new. And it works because it targets the actual mechanism of accountability rather than building another dashboard nobody opens.

Building something like this

If this sounds useful, the pattern is reproducible. You’re not building anything exotic. The components are:

A Telegram bot (the interface — python-telegram-bot library handles this in about 50 lines). A scheduler (APScheduler or a simple cron-like structure) for proactive messages. A memory layer (SQLite is more than sufficient — just store conversations and let the agent summarize and retrieve them). A knowledge base (the research Claude Code collected became the system prompt that shapes every interaction). A persistent process (a simple Python script set to run on startup, or a systemd service if you want something more robust).

The whole thing lives in a folder on your computer. No hosting required. No subscriptions. Accessible anywhere through Telegram.

Claude Code handled the research, the architecture, and the implementation in a single session. The approach I use for building with AI — research first, then architecture, then implementation — works especially well for projects like this because the research phase directly shapes the software design.

Software that runs forever

There’s something that becomes obvious once you build one of these persistent agents and live with it for a few days: this is a fundamentally different category of software.

We know command-line tools, web apps, desktop apps, and mobile apps. These are all things you go get when you need them. They sit in a menu or a browser tab or an app drawer, waiting to be opened.

Persistent agents are different. They run in the background. They monitor things. They decide when something requires your attention. They interrupt you only when warranted. The interface is a chat — a format your brain associates with people, not programs.

This is where more software is going. Not apps you download — agents you deploy. Processes that run on your hardware (or in the cloud), maintain memory across months of interaction, and have access to tools that let them actually do things on your behalf. The executive coach is a simple example. The same architecture could monitor your business metrics and alert you when something looks off. It could track your health data and notice patterns before you do. It could manage a process — customer follow-ups, content scheduling, financial reporting — and only surface the items that genuinely need your judgment.

The paradigm shift isn’t about AI getting smarter. It’s about software becoming proactive. That transition is happening fast enough that most people haven’t noticed it yet, but once you’ve lived with a persistent agent for a week, you’ll wonder why all your software was passive.

I passed on the coaching program. A few hours later I had a coach. That’s the most interesting part of all of this — not the technology, but what becomes possible when the barrier to building drops to nearly zero.