Build Systems, Set Goals: A Goal-Oriented Approach to AI in SEO and Product Work

Most conversations about artificial intelligence begin with model selection: which one is smarter, which is cheaper, which writes better code, or which handles more context. I suggest starting with a different question: what system are we building, and what result should it produce?

This article is based on my talk at the WebPromo Experts AI SEO Day conference on August 19, 2026.

The opening slide places the goal before the model. The talk is not a catalogue of AI products; it is a method for designing work in which inputs, rules, verification, feedback, and ownership all serve a measurable result.

This background explains the emphasis on systems. On large multilingual sites, recurring work appears quickly, and a fragile one-off prompt cannot reliably govern audits, translations, technical checks, or decisions repeated across many markets.

I work in programmatic SEO and deal with large multilingual websites containing millions or tens of millions of pages. Repetitive work appears very quickly at that scale: audits, translations, collecting and reconciling data, finding technical problems, and preparing similar decisions again and again. If a recurring task consumes time several times a week - or even every day - it is worth turning into a system.

That system does not have to be complicated. Sometimes a script, a few files containing rules, and a clear way to verify the result are enough. What matters is that the system frees up time for work that genuinely requires a person: strategy, hypothesis testing, product understanding, and decision-making.

Below is my practical approach to building such systems, from goals and context to agent workflows, translation, and SEO analysis.

A System Starts with a Goal, Not a Model

A system is not a collection of fashionable tools, nor is it a group of agents with impressive role names. It is a set of interconnected elements organized to achieve a shared goal.

Even the simplest working system has several essential parts:

1. a goal;
2. input data;
3. a transformation process;
4. verification;
5. an output;
6. feedback.

We first need to understand what we want to produce. Then we can decide what goes in, what happens inside the process, how the output will be checked, and what should change in the next cycle if the result is unsatisfactory.

A Good Goal Is Small Enough to Verify

I prefer goals that can be implemented in about a week. A small release is easier to launch quickly, test against real data, and either expand or discard without regret.

In that sense, SMART is more than a diagram from a management textbook. A goal should be specific, measurable, achievable, relevant, and time-bound. “Automate content operations” tells us almost nothing. “Generate X in revenue from content within Y time at a defined publishing volume” already forces us to design an actual process.

Until the goal is clear, we cannot answer even the basic questions:

• What output must the system produce?
• Which sources are canonical?
• What should be done in code, and what should be done by an LLM?
• How will the output be verified?
• What happens when the system is uncertain?
• Who makes the final decision?

The System Does Not Have to Be Complex

One of my personal experiments began with a simple thought: if I am going to spend time on my hobbies anyway, can at least some of that time pay for itself?

Once a week, my friends and I play an online game. I record those sessions, and a local system detects active moments from the audio and video, cuts short clips, converts them into the required format, and sends them to the Gemini API. The model evaluates each clip and suggests a description and title. After an automated internal check, suitable clips are published as YouTube Shorts. Once enough of them accumulate, the system assembles a longer video and uploads that to the channel as well.

The channel now receives thousands of views per day, and the monetization offsets time I would have spent playing anyway.

The LLM is only one component. FFmpeg handles clipping and transcoding, selection criteria are defined separately, and publishing is another distinct stage. There is an input, a process, a check, and a measurable output. That is what makes it a system rather than a successful prompt.

You Need Domain Expertise to Build a System

AI quickly creates the illusion that we can automate a field we do not understand ourselves. In practice, that is one of the shortest routes to a poor result.

Suppose I want to create my own comic. A plot and the instruction “generate a page for me” are only the beginning. I need to understand what a comic consists of: how the story is structured, what the visual style should be, what the characters look like, which details must stay consistent across scenes, and what context the model needs when generating the next page. Without that knowledge, I will get a collection of random pictures, not a system.

SEO is no different. If you do not understand what should happen to a site and why, you cannot give the model the right task, notice an error, or verify the result.

There is a telling example from my consulting work. A manager gained access to an agent tool and asked it to assess the position of a large online store. The tool began collecting data and drawing persuasive charts suggesting that things were going badly, even though actual revenue showed the opposite.

It turned out that instead of using the full dataset, the model had taken roughly one thousand products and extrapolated the result to the rest of the catalog. Nobody knew why those particular products had entered the sample. The model tried to reduce the amount of work and produced a plausible answer, but did not disclose the critical assumption behind it.

The right stance is not “I am replacing myself with a model,” but “I am becoming an LLM operator within my own field of expertise.” The model adds speed and helps me stay attentive. Responsibility for the goal, method, and verification remains with the specialist.

Design the System So Its Components Can Change

No system remains optimal forever. Models, services, prices, and constraints all change, so components should be replaceable.

For example, I built a personal process for learning a new subject. I first select books, then use an LLM to create a short summary and decide whether I actually need each source. Because reading on a screen is not always convenient for me, the selected material is converted into audio. I originally built that stage myself, but the quality was mediocre. When ElevenReader appeared, I replaced one component while leaving the rest of the system intact.

This principle matters in SEO automation as well. If the entire process depends on one particular chat, changing the model forces you to rebuild the work from scratch. If the goal, inputs, rules, checks, and output format are documented separately, the model remains a replaceable executor.

Forget Magic Prompts: Context Is What Matters

A few years ago, prompt engineering was treated as the central skill: how to phrase the request, which words to add, and how to make the model reason “correctly.” Strong models now understand ordinary language well enough that you can simply dictate a request.

The important question has moved elsewhere: what can the model actually see?

Results depend less on a magic phrase and more on sources, boundaries, rules, and the history of past decisions. That is why I prefer to talk about context engineering rather than prompt engineering.

In an earlier AI SEO Day talk, I showed how to collect project knowledge and data for individual SEO tasks. The next step is to turn that accumulated context into a system that survives changes in chats and models.

Where Working Context Comes From

An SEO specialist’s context usually already exists; it is simply scattered across different places:

• a knowledge base or Confluence contains audits, hypotheses, tests, and - most importantly - conclusions about what worked and what did not;
• Jira or another task tracker contains the task description, the reason it exists, discussions, and links to the implementation;
• saved conversations preserve decisions that never reached formal documentation;
• call transcripts contain things the team discussed but never recorded anywhere else.

The outcome matters more than the fact that the work happened. If we translated one hundred thousand descriptions, the context should not end with “translation complete.” It should record how many pages were reindexed, what happened to rankings and traffic, which errors were found, and which rules changed after verification.

Documentation is no longer bureaucracy in this approach. It becomes the system’s memory and directly improves the quality of the next task.

Format matters too. LLMs work well with lightweight text formats: Markdown for documents, CSV for tables, and JSONL for bulk operations. These formats are easy for people to read, easy to version, and easy to move between tools.

Why Global Memory Does Not Work for Everyone

Built-in memory is convenient when you have one product and a stable context. An SEO specialist or agency, however, may work with dozens of websites at once. Facts, rules, and constraints from different projects then begin to bleed into each other. Outdated information remains in memory, while it is difficult to inspect and verify everything the model believes it knows.

I prefer an explicit folder structure and a cascade of rule files. General working principles live at the top. Below them are separate folders for personal and professional areas, companies, websites, projects, and tasks. Each level adds only its own rules.

This approach has three benefits:

• context is isolated instead of leaking between sites;
• rules are visible and can be opened and checked;
• changes are versioned with the project.

Before starting a task, I deliberately choose the scope: give the agent access to the entire working folder, one website, or only the directory for a specific task. The narrower the task, the less irrelevant context it receives and the lower the risk of mixing data.

Task State Should Live in Files, Not in Chat

A regular chat is a poor place for long-running work. The history grows, is eventually compressed, and loses detail. A few weeks later, it becomes difficult to understand why a particular decision was made. A new chat starts from zero.

That is why I use four files for each task:

TASK.md lets me verify immediately whether the model understood the request. PLAN.md shows whether it is about to do something unreasonable, such as calculate financial metrics without access to the source data. KNOWLEDGE.md preserves the traps: a connection method that failed, an API quirk, a problem in the data, or the reason one solution was chosen over another. RESULT.md records not the model’s promise, but the result that was actually produced and verified.

Indexes Make Every New Task Cheaper

Once there are many tasks, folders alone are not enough. After a task is completed, add a short summary to an index - for example, a CSV table. When new work begins, the agent first searches for similar tasks, then loads their results and accumulated knowledge.

This keeps experience from disappearing into old chats. The first task may require a great deal of manually supplied context. The next task reuses the solutions already found, and after several iterations much of the process becomes reproducible.

Ideally, a task should make sense from a cold start: a different model, a different machine, and no memory of the conversation, yet the files still show why the work began, where it stopped, and how to verify the result.

An Agent Is a Loop; an Orchestrator Runs It

There is a fundamental difference between a chat and an agent. In a chat, a person asks a question, receives an answer, and repeats the cycle manually. An agent receives a goal, plan, data, and tools, then performs steps, checks intermediate results, and repeats individual actions when necessary.

Agentic work adds another layer of risk: the orchestrator. This is the program between the user and the model. It decides which tools to call, which context to pass, when to compress the conversation, how to launch a subagent, and what to do after an error.

That means a decline in output quality does not always mean that “the model got dumber.” The orchestrator, its settings, the way it assembles context, or its supporting models may have changed. We need visibility not only into the final answer, but also into the steps that ran, the instructions a subagent received, and exactly what it returned.

Long conversations covering unrelated subjects also hurt quality: sooner or later, the history is compressed into an unpredictable summary. It is better to separate projects and open a new task for each distinct goal, while keeping state in files.

Turn Repeated Work into a Runbook

Once the same task has been completed several times, its history can become a runbook: a reproducible description of the process.

A good runbook includes:

• the goal and boundaries;
• input data and the expected output format;
• the sequence of steps;
• tools used;
• conditions and branches;
• checks;
• error handling;
• the definition of done.

Suppose you regularly build keyword sets. Instead of opening a new chat every time, preserve the working sequence, file formats, and scripts from previous runs. The input topic changes; the proven framework stays.

A request or trigger starts the runbook. The system gathers the required context and data, executes the steps, calls the tools, verifies the output, and only then hands the result to a person.

Case Study: Bulk Translation Without Thinking

One practical example is translating a large catalog. The initial input contained 408,418 descriptions. Filtering reduced the set to 160,551 products, and deduplication brought it down to approximately 125,600 unique texts.

The naive approach is to prepare a table, send it through batch inference, and collect the responses. That still leaves a large amount of manual work in file preparation and transfer - and, more importantly, provides no proper quality control during the process.

In the working system, responsibilities are separated:

1. code exports the catalog, filters records, and deduplicates texts;
2. DeepSeek translates the unique texts with thinking disabled;
3. results are cached in JSONL together with the prompt version;
4. deterministic checks identify formal errors;
5. simple problems are fixed automatically;
6. ambiguous texts enter a manual-review queue;
7. native speakers also review a random sample;
8. a systemic error leads to a rule change and a rerun of the affected records.

Why Thinking Made the Result Worse

Translation does not require multi-step reasoning. It requires precise rules, domain information, a good glossary, and fidelity to the source meaning. The thinking model spent tokens on reasoning, tried to improve the style, and introduced extra interpretation where careful transformation was needed.

After thinking was disabled in this case:

• tokens per call fell by 80.7%;
• the cost per translated word became 3.5 times lower;
• the native-speaker quality score improved by 3.2%;
• the complete run became approximately 35 times faster.

This is a good example of why there is no universally “best model.” For a particular task, what matters is sufficient quality, speed, cost, and controllability. A more expensive reasoning mode can perform worse than a simpler one when the system needs exact, repeatable transformation rather than inference.

Case Study: Reviewing a Site with Logs, Crawls, and Business Data

Another typical scenario is determining where a large website has real SEO problems and in which order they should be fixed.

Several sources can be combined in one process:

• server logs;
• Google Search Console data from BigQuery;
• site crawl results;
• a target model or set of SEO rules;
• sales data and other business priorities, when needed.

Logs and Search Console data can be stored in ClickHouse, while Screaming Frog results can be exported to tables. Local Python scripts then join everything by URL. For each page, the process compares Googlebot’s actual behavior, traffic, current page status, and target state.

Instead of an abstract request to “analyze my site,” the output contains three verifiable results:

1. a map of differences between the actual and target states;
2. priorities that show what should be fixed first;
3. concrete tasks for the website.

For example, the logs may reveal parameterized pages that were never excluded from indexing. The conclusion does not come from the model’s free-form reasoning; it comes from matching sources in a process where every step can be reproduced.

Code Should Calculate, Not the Language Model

My rules state this explicitly: even small calculations should be performed in code. An LLM can write a Python script, explain the output, and help find a logic error. The numbers themselves should come from a reproducible process.

The reason is simple: you can return to code. You can inspect the formula, input data, and intermediate values, then repeat the calculation. If a model merely says it calculated something “on its side,” the process is far more difficult to verify.

It is important to distinguish calculation from interpretation:

• code calculates, filters, joins, and checks formal conditions;
• the model helps write the code, explains the result, and suggests possible causes;
• the specialist decides whether the conclusion matches reality and can support action.

The source of data should also be a database, analytics system, or another canonical source - not a ChatGPT response. In one case I know, a company was preparing for an investment round and collected data from its managers. During the presentation, the team discovered that some of the metrics did not reconcile. One participant simply asked ChatGPT for the required percentages, and the model invented them. A convincing number does not become a fact just because it looks good on a slide.

Three Rules That Prevent Most Problems

1. Always Start with a Plan

An API can fail, a tool can skip part of the workflow, and the model may still report that the task is complete. A plan lets you check the actual completion of each step instead of trusting the confidence of the answer.

Pay particular attention to whether files exist, whether the data is complete, and whether the checks actually ran. The word “done” proves nothing on its own.

2. Use a Separate Critic

After a complex task is completed, it is useful to open a separate context and ask a critic to review the result against the original plan: what was missed, which assumptions remain unsupported, and where verification is absent.

A critic does not remove responsibility from the person, but it helps search for a different class of errors. The final decision must still be made by someone who understands the domain and owns the consequences.

3. Limit Context to Match the Task

The model does not need the entire history of your life and every project. It needs the specific tables, documents, and rules required for the current result. Narrow context is easier to verify, cheaper to process, and harder to mix accidentally with data from another site.

Do Not Delegate Your Intelligence

A model may possess more knowledge than any single person, but knowledge and experience are not the same. Experience means understanding the specific project: why a decision was made, which constraints are hidden in the data, where an impressive result conflicts with reality, and which questions must be asked before launch.

AI can handle data collection and transformation, code generation, first drafts, bulk translation, and risk discovery. What cannot be delegated is ownership of the goal, the choice of a source of truth, professional judgment, or final acceptance of the result.

The most useful AI system is not the one with the largest number of agents, models, and integrations. It is a system in which a person can clearly describe the desired outcome, understands the process, can verify every important step, and can replace any component without losing accumulated experience.

Start with one recurring task. Record its goal, inputs, steps, and definition of done. Preserve the result and the errors you found so that the next run becomes cheaper and more reliable. Add an LLM only where it genuinely strengthens the process.

The model may change. Your system remains yours.

That final slide is also part of the system’s logic. A process is not complete when a model stops producing output; it is complete when a responsible person can receive the result, answer for it, and decide the next action.