In a SEO audit, small and simple, a good prompt may be enough. In an audit of a digital publication involving several sources and hundreds of megabytes of data, it is no longer sufficient.

In this case, I worked with a Spanish publication that had suffered a very sharp drop in traffic from Google Discover. There were thousands of URLs with clicks, a six-figure content inventory, and a technical crawl amounting to several hundred megabytes.

Trying to fit all of that into a conversation does not improve the analysis. It only causes the model to lose context, mix up sources, and ultimately provide answers that are difficult to verify.

What I needed was not “more AI,” but an orderly way to work with it. In this article, I explain the system I built, how I configured it, and what I learned from using it in a real audit.

The core idea is simple: heavy data is processed outside the conversation, and only verifiable results enter the context.

The real problem: context runs out

The audit combined sources with very different functions:

Source What it provided Approximate volume
Google Search Console: Discover Trends, reach, and CTR by URL Thousands of URLs with clicks
Google Search Console: Search Organic trends and queries A large number of rows
Google Analytics 4 Sessions, engagement, and return visits Several extracts per period
Technical crawl Internal linking, indexability, and structured data Several hundred megabytes
CMS export Author, section, tags, and date An inventory of hundreds of thousands
CrUX and PageSpeed Insights Page experience Several JSON responses

Each source was manageable on its own. The problem arose when it was time to cross-reference all the data and obtain useful conclusions.

A model can read and summarize a CSV. What it should not be asked to do is retain all the records, hypotheses, decisions, and audit history in the same context window. If the context is filled with raw data, there is less room left to reason about it.

There is also a business cost. When a session is lost or a hypothesis is not recorded, the team repeats work. It revisits causes that have already been ruled out, produces contradictory versions of the diagnosis, and takes longer to reach a defensible recommendation.

That is why I separated the system into three layers:

  1. OpenCode: runs agents, permissions, and MCP connections
  2. Gentle-AI: defines when to delegate and how to review
  3. Engram: preserves decisions and findings across sessions

Three tools: one executes, another organizes the process, and the third maintains memory.

1. Start with privacy and permissions

Before connecting Search Console, Analytics, or the crawler, I reviewed the base configuration. It is the least eye-catching part, but also the one that prevents the most costly problems.

My configuration disables sharing and sets an orchestrator as the primary agent:

{
  "default_agent": "gentle-orchestrator",
  "share": "disabled"
}

An audit contains business metrics, URLs that may not yet be public, and access credentials. Disabling sharing reduces the possibility of that material ending up where it should not.

I then restricted access to sensitive files:

{
  "permission": {
    "read": {
      "*": "allow",
      "**/.env": "deny",
      "**/.env.*": "deny",
      "**/secrets/**": "deny",
      "**/.ssh/**": "deny",
      "**/*.key": "deny",
      "**/*.pem": "deny",
      "**/credentials.json": "deny"
    },
    "bash": {
      "*": "allow",
      "git commit *": "ask",
      "git push *": "ask",
      "git push --force *": "ask",
      "git reset --hard *": "ask"
    }
  }
}

I have simplified the example, but it retains the logic of the configuration I use: general reading is allowed, secrets are blocked, and human confirmation is required to publish changes or alter history.

The important distinction is this: the agent can use an authorized connection without having to read the file containing the credential. For the company, this means a smaller exposure surface and greater control over who can do what.

Automating first and securing later usually forces you to rebuild integrations, rotate credentials, or review logs that should never have contained them.

2. Connect sources through MCP

MCP, or Model Context Protocol, allows the model to use external tools and services through a common interface. For this audit, I connected seven components: memory, Analytics, Google Search Console, the Screaming Frog crawler (MCP and CLI), the CrUX/PageSpeed Insights API, Chrome DevTools, and technical documentation.

A simplified configuration would look like this:

{
  "mcp": {
    "engram": {
      "type": "local",
      "command": ["engram", "mcp", "--tools=agent"]
    },
    "google_analytics": {
      "type": "local",
      "enabled": true,
      "command": ["<lanzador-local-del-servidor>"]
    },
    "screaming-frog": {
      "type": "remote",
      "enabled": true,
      "url": "<servidor-local-mcp>",
      "timeout": 30000
    },
    "context7": {
      "type": "remote",
      "enabled": true,
      "url": "https://mcp.context7.com/mcp"
    }
  }
}

I have removed paths, identifiers, and all access data, but this should give you an idea of the structure.

Each connection had a specific purpose:

  • Engram stored decisions, incidents, and conclusions that needed to survive the session.
  • Google Analytics/Search Console made it possible to query data and behavior without pasting exports or credentials into the prompt.
  • The SEO crawler provided controlled access to technical information.
  • Technical documentation helped verify APIs and libraries before writing scripts.

The effect on the project was quite practical: less manual copying, fewer duplicate files, and clearer traceability from source to conclusion.

The mistake that changed how I process data

The technical crawl had been exported as NDJSON and amounted to several hundred megabytes. In an initial test, the AI tried to read the entire file into the context. The result was predictable: high usage and little useful analysis.

From that point on, I established a rule: a large NDJSON file must be filtered or processed as a stream; it should never be loaded in full into the conversation.

The agent runs a script that selects and filters the relevant columns and cases. The file may contain millions of values, but the orchestrator receives only a few dozen anomalous rows and a coverage summary. I now usually load the data into SQLite or PostgreSQL and have the AI run database queries only for the data it needs.

This is not just a technical improvement. It reduces execution time, cost, and the risk of making decisions based on a sample that the model has “hallucinated” or silently truncated.

3. The orchestrator coordinates; it does not do all the work

The orchestrator maintains the audit's thread. It decides which task to run, which agent should perform it, and which result is worth preserving. If it also reads every CSV, runs every script, and writes the report, its context deteriorates very quickly.

I use this decision rule:

Work In the orchestrator In a specialized agent
Check one, two, or three files Yes Not necessary
Explore four or more files No Yes
Process a large dataset No Yes
Run a pipeline or tests No Yes
Make a brief decision based on summarized evidence Yes Not necessary
Write several related documents or scripts No Yes, with a single owner

The question I ask is: does this task fill the main context without improving the decision? If the answer is yes, I delegate it.

Gentle-AI turns that criterion into explicit limits. For example, it requires delegating an exploration involving four or more files and prevents a significant edit from being divided among several agents without coordination.

For a marketing director, the advantage is less technical than it may seem. The system preserves a stable line of reasoning: problem, evidence, hypothesis, decision, and plan. It avoids having to reconstruct the audit every time the person or session running a task changes.

I also restricted which agents the orchestrator can invoke using an allowlist. If a role has not been defined, it cannot be improvised in the middle of the process.

{
  "agent": {
    "gentle-orchestrator": {
      "permission": {
        "task": {
          "*": "deny",
          "explore": "allow",
          "general": "allow",
          "sdd-apply": "allow",
          "review-readability": "allow",
          "review-reliability": "allow",
          "review-resilience": "allow",
          "review-risk": "allow"
        }
      }
    }
  }
}

The local configuration contains more specialized analysis and SEO roles, but the principle is the same: deny by default and authorize only known agents.

4. Separate agents, models, and contexts

Not every task needs the same model or the same tools.

To locate files or count records, I use a lighter model. To design the cross-referencing of sources, test a hypothesis, or review an important conclusion, I reserve models with greater reasoning capability.

Role Model type Reason Business impact
Orchestration Mid-tier and stable Routes and summarizes Keeps the cost of a long session under control
Exploration Lightweight Searches, counts, and classifies Reduces the cost of repetitive tasks
Analysis and design High reasoning Cross-references signals and evaluates hypotheses Improves the quality of critical decisions
Writing Suitable for documents Organizes evidence for each audience Reduces report preparation time
Review High reasoning and read-only Finds errors without modifying the work Prevents biased or accidental corrections

I prefer to define capabilities by role rather than publish a recipe tied to a specific version. Models change, but the agent's responsibility should not change with them.

As for models, the good thing about having this system is that it is provider- and model-agnostic. Most agents currently run on GPT-5.6 Sol, Tierra, and Luna with High or Medium reasoning, and some use Claude Opus 4.8. In the future, however, I can swap models according to capability and cost as needed.

I also explicitly disable tools. A reviewer can read, but cannot edit or run commands. This separates judgment from correction.

That separation seems bureaucratic until an agent tries to “fix” a test by changing the test itself. Something similar can happen in an SEO report: if the person reviewing a conclusion can also rewrite it without leaving a trace, it becomes harder to know what evidence supported the previous version.

5. Turn SEO knowledge into skills

A skill is not a piece of text about SEO. It is a procedure that specifies when to act, which constraints to respect, which tool to use, and what result to deliver.

The Google Discover skill I used includes four blocks:

  1. Activation contract: it is used to extract or diagnose Discover, not for conventional Search analysis.
  2. Technical rules: the request must specify type="discover"; the supported dimensions are date, country, page, and searchAppearance; this report contains no queries or position data.
  3. Operational decisions: which script to run to extract data and which one to use to diagnose a drop.
  4. Output format: clicks, impressions, CTR, trend, turning point, top pages, and differentiation between Search and Discover.

These rules have been verified against the local procedure. They also account for two constraints that affect planning: Search Console retains approximately 16 months of data, and Discover typically has a processing delay of two to three days.

In business terms, a skill reduces variability. Two analysts can run the same procedure and receive comparable output. It also prevents known errors, such as requesting a dimension unsupported by the Discover API or confusing Search data with Discover data.

My criterion for adding a rule is very simple: if an error has already recurred or could affect a decision, it must become part of the procedure. Correcting it only in the chat helps that one conversation. Documenting it in the skill helps the next audit.

My advice: do not use third-party skills; create your own. You only need to ask the AI to create the skill, give it a name, and provide rules that you define. This is how I have created several dozen specialized skills, with my methodology embedded in each task.

6. Engram as decision memory

Engram stores persistent information and exposes it to the system through MCP. I use it to preserve anything that cannot easily be inferred from the files.

The most useful operations in this workflow are:

Operation Use
mem_context Recover the point where the work stopped
mem_search Check whether an issue has already been investigated
mem_get_observation Open the full content of a result
mem_save Record a decision, incident, or lesson learned
mem_session_summary Leave a useful handoff for the next session

Not everything is saved—only decisions and facts that would be difficult to reconstruct. The AI decides what should be stored in Engram according to these instructions.

For example:

What: a sitewide penalty is ruled out.
Why: Search remains reasonably stable while Discover falls, although it continues to generate traffic.
Where: comparative analysis of both sources.
Learned: the decline appears specific to Discover and requires a review of quality, timeliness, and editorial dependency.

I use topic keys to give each hypothesis a stable address:

auditoria/medio/hipotesis-principal
auditoria/medio/dataset-maestro
auditoria/medio/hallazgos-tecnicos
auditoria/medio/decisiones

When the hypothesis evolves, the same key is updated. This prevents multiple incompatible conclusions from being scattered throughout the history.

From a business perspective, memory reduces rework and makes it easier to explain why a decision was made. It does not replace client documentation, but it does preserve the reasoning behind it.

7. The complete audit workflow

This is the path I followed. The important thing is to control what enters and leaves each phase.

Phase 0. Recover context and procedures

The orchestrator retrieves the previous summary and loads the skills index once.

Input: memory from the previous session.

Output: current state, open decisions, and available procedures.

This allows the session to start working instead of spending its first few minutes reconstructing context.

Phase 1. Extract Discover data

An agent runs the extractor against the authorized property. The API receives type="discover" and queries the supported dimensions.

The orchestrator does not receive every row. It receives the internal paths to the CSV files, the record count, the date range, and any coverage error.

The source remains traceable without consuming the main context with raw data.

Phase 2. Locate the turning point

Another step aggregates the daily and weekly series to detect the change in level. It compares the shape of the decline—sharp or gradual—and contrasts Discover with Search.

Stable Search traffic and collapsing Discover traffic are a sign that the problem is probably limited to Discover, not automatic proof of a penalty or a definitive root cause. The conclusion must be checked against the rest of the evidence and documented Google updates.

This comparison prevents the team from opening technical investigations that do not explain the decline and focuses the budget on the hypotheses most likely to account for the problem.

Phase 3. Create a master dataset

I then enriched the Discover URLs with:

  • Author, section, tags, and publication date from the CMS.
  • Internal-linking signals and structured data from the crawl.
  • Behavioral metrics from Analytics.
  • Performance and publication time.

The result was a dataset containing thousands of URLs. The orchestrator received only the available columns, the match rate across sources, and the unmatched records.

This part is essential. Clicks indicate which content performed, but the CMS inventory provides the denominator: how much of each type was published.

With that denominator, I was able to distinguish an effective format from excessive editorial dependency.

Phase 4. Formulate and test hypotheses

Once the dataset was ready, a specialized agent aggregated clicks by headline pattern, author, section, and publication time.

One of the findings was that a minority pattern accounted for a disproportionate share of Discover performance.

This did not mean that most of the publication used that pattern. It meant that a very large share of performance depended on a small fraction of the output.

That nuance changes the recommendation. The problem is not solved by banning a format, but by reducing risk concentration and broadening the sources of editorial performance.

Management therefore receives a content-portfolio decision, not a generic accusation of “clickbait.”

Phase 5. Write for two levels of readership

The report followed a simple structure:

  1. What changed.
  2. Which evidence best explains it.
  3. Which hypotheses were ruled out.
  4. Which decisions should be made.
  5. How to measure the recovery.

Figures were included only when they had a specific source. The technical detail remained in appendices, while the executive summary focused on impact, priority, and risk.

Management can make decisions without reading the pipeline, while the SEO team retains the evidence needed to verify them.

Phase 6. Review before delivery

The review is assigned according to the dominant risk:

Primary risk Review
Clarity and maintainability Readability
Behavior and regressions Reliability
Partial failures and integrations Resilience
Security, permissions, and data exposure Risk

A standard change uses a single lens. For sensitive paths or very large changes, the process can expand the review. Reviewers work in read-only mode and must provide concrete evidence.

I also separate problems introduced by the current work from pre-existing problems. A pre-existing finding may become a future task, but it should not block delivery if the change did not cause or worsen it.

With this criterion, the review focuses on real risks instead of becoming an endless list of possible improvements.

Phase 7. Close the session

Before finishing, I leave a summary with the objective, findings, completed work, next steps, and relevant files.

The next session can continue without reinterpreting the entire history.

8. How to reproduce this system

You do not need to start with twenty agents. I would build it in this order:

  1. Disable sharing when working with client data.
  2. Block access to credentials, keys, and environment files.
  3. Require human confirmation to publish changes or alter history.
  4. Connect memory, analytics, and crawling through MCP.
  5. Define an orchestrator that coordinates and summarizes.
  6. Create an execution agent, a writing agent, and read-only reviewers.
  7. Assign models according to task difficulty, not convenience.
  8. Process large files through filtering, aggregation, or streaming.
  9. Turn repeatable SEO procedures into skills.
  10. Ensure each skill defines activation, rules, decisions, and output.
  11. Store hypotheses and decisions under topic keys.
  12. Review according to risk and close each session with a summary.

This foundation already provides most of the value. The rest can grow when a real need arises.

9. A minimum test before working with client data

Before connecting a real property, I test the complete flow with a harmless task. This does not prove that the audit is correct, but it does prove that permissions, memory, and delegation work as expected.

Step Test Expected result
1 Save the configuration and restart OpenCode Startup completes without syntax errors or unexpected connections
2 Check which agent is active gentle-orchestrator appears as the primary agent
3 Run mem_save with an observation and a temporary topic key, then retrieve it with mem_search The retrieved content matches what was saved and remains available after restarting the session
4 Use task to delegate a harmless task, such as counting the headings in a test Markdown file An authorized subagent runs it, and the orchestrator receives only the requested summary
5 Ask a reviewer to inspect that same file It can read and return findings, but cannot edit it or run commands

When the test is complete, I delete the temporary observation if it adds no value. If any of these steps fails, I do not proceed with client information; I fix the configuration first. It is a small check, but it prevents discovering a misconfigured permission after the audit is already underway.

What I learned

Context is a working budget. I understood this when I tried to analyze an NDJSON file of several hundred megabytes inside the conversation. The model received a large amount of data but lost the ability to connect it. Since then, I have kept files outside the conversation, processed them in a database or as streams, and passed counts, anomalies, and verifiable references to the orchestrator. The important saving was not just tokens: I was able to keep the main hypothesis visible throughout the audit.

Repeatable errors must become procedure and memory. The Discover API has constraints that are easily confused with those of Search. Instead of trusting the next agent to remember them, I moved them into a skill. I did the same with decisions: a rejected hypothesis is stored under a topic key in Engram. This way, the procedure prevents the technical mistake from recurring, and memory prevents the discussion from recurring.

AI contributes more when judgment remains human. The agents found that a minority pattern accounted for a disproportionate share of performance. That concentration was evidence, not a strategy. I had to interpret it within the editorial context and turn it into a recommendation about diversification. Keeping reviewers in read-only mode also helped me separate criticism from correction and preserve a clear record of why a conclusion changed.

This way of working does not automate an entire audit. It does something more useful: it distributes the work so that every step is reproducible, reviewable, and understandable. I still direct the analysis. The agents handle the tasks they can perform best, without turning the conversation into a data warehouse.