AI agents in WordPress: what to decide before letting an agent touch a folio system

AI agents in WordPress went from experiment to core feature in a few months. Connecting one is easy now. Deciding what that agent may do inside your site is still hard, and it is the part almost nobody writes about.

I come to this topic from a real system: a WordPress plugin that managed a pool of 80,000 folios (unique entry codes) in production, with receipts verified by OCR + LLM. That system did not use agents. It used a pipeline. And that difference is exactly the starting point.

This article is what I would decide before letting an agent touch a system like that: what to expose, what never to expose, and how to leave a trail of everything. The code is illustrative, not the client's.

Pipeline or agent: the decision that comes first

The Panini Fan Zone FWC 2026 system verified receipts in two fixed steps. Tesseract extracted the text from the image. Then a LLaMA 3.3 70B model, served by Groq, validated that text against the promotion rules.

The code decided the order. A cron job every 2 minutes picked up the pending items, ran them through OCR and the model, and stored the result. The LLM solved one step; it did not choose the next one.

An agent works the other way around. You give it tools, for example "look up folio", "mark as valid" or "send email", and the model decides which one to call, in what order and with what data.

That changes the risk model:

• In a pipeline, the worst case of a model error is a wrong classification. Your rules can catch it.
• In an agent, the worst case is a wrong action: changing a status, deleting a record or emailing a participant.
• In an agent, the input is also an attack vector. If the agent reads the text of a receipt, that text can carry instructions written to manipulate it.

So the first question is not which agent platform to use. It is whether the problem needs an agent at all. For verifying receipts against clear rules, a pipeline is cheaper, more predictable and easier to audit.

An agent makes sense around the system: letting the support team ask in plain language about a folio's status, summarizing incidents, or preparing reports. There the flexibility is worth it, as long as the tools are tightly scoped.

Integrating AI agents in WordPress

WordPress is adding pieces so agents can discover and use a site's capabilities, with APIs that describe what each plugin can do and a bridge to the MCP protocol. It is a good step forward, but it does not change the underlying rule.

Whatever the connector, in the end the agent calls something inside your site with a user's permissions. Security depends on what you expose and with which permissions, not on the protocol. The WordPress REST API already has everything you need to do it right.

Start with read-only tools

The first tool should answer questions without changing anything. Looking up a folio's status is the perfect example: useful for support and free of side effects.

add_action( 'rest_api_init', function () {
    register_rest_route( 'folios/v1', '/status/(?P<folio>[A-Z0-9-]{6,20})', [
        'methods'             => 'GET',
        // A dedicated capability: the agent's user is not an administrator.
        'permission_callback' => fn () => current_user_can( 'folios_read' ),
        'callback'            => function ( WP_REST_Request $req ) {
            $status = folios_status( $req['folio'] ); // read only
            // Never return personal data: the agent does not need it.
            return [ 'folio' => $req['folio'], 'status' => $status ];
        },
    ] );
} );

Three decisions make this route safe:

• The regular expression validates the folio before touching the database. Anything that does not look like a folio never reaches the callback.
• permission_callback checks a dedicated capability. Not manage_options, not "any logged-in user". The agent's role has that capability and nothing else.
• The response carries the minimum. The folio's status, yes. The name, the email or the receipt image, no.

Never leave permission_callback as __return_true on a route that queries business data. It is the fastest way to turn a support tool into a leak.

A user and a password just for the agent

The agent should authenticate as its own user, with a role created for it. WordPress application passwords are ideal: they are revoked one by one and cannot be used to log in to the dashboard.

# ⚠️ Production: back up the database before giving an agent access.
wp db export "backup-$(date +%F).sql"

# A dedicated user for the agent: if something goes wrong, revoke it without touching anyone.
wp user create folio-agent "$AGENT_EMAIL" --role=folio_agent

# Application password: revocable and separate from the login password.
wp user application-password create folio-agent "agent-read" --porcelain

# Test: reads respond; a route without the capability must return 401 or 403.
curl -s -u "folio-agent:$APP_PASS" https://your-site.example/wp-json/folios/v1/status/FZ-000123

The folio_agent role is registered in the plugin with add_role and carries only the read capabilities. If the agent misbehaves, you revoke its password and the rest of the site stays the same.

Writes: proposals, not actions

Sooner or later someone will ask for the agent to "fix" things too. The safe answer is that the agent proposes and a person approves.

register_rest_route( 'folios/v1', '/proposals', [
    'methods'             => 'POST',
    'permission_callback' => fn () => current_user_can( 'folios_propose' ),
    'callback'            => function ( WP_REST_Request $req ) {
        global $wpdb;
        // The agent does not change the folio: it leaves a proposal a person approves.
        $wpdb->insert( "{$wpdb->prefix}folio_proposals", [ 'folio' => sanitize_text_field( $req['folio'] ),
            'action' => sanitize_key( $req['action'] ), 'author' => get_current_user_id(), 'status' => 'pending' ] );
        return new WP_REST_Response( [ 'id' => $wpdb->insert_id ], 202 ); // 202: accepted, not executed
    },
] );

The 202 status code communicates exactly what happened: the request was accepted but not executed. The real action happens when someone with permissions approves it from the dashboard, and that step uses the same validation a person would go through.

This pattern has an extra benefit: the proposals table is also the record of what the agent tried to do.

Limits and auditing from day one

An agent can get stuck in a loop and call the same tool hundreds of times in a minute. That should hit a limit, not your database.

• Per-user rate limit. A per-minute counter, stored in a transient or the object cache, that responds 429 when exceeded.
• A log of every call. Who, which route, with which parameters, when and with what result. Without that log, an incident is impossible to reconstruct.
• Tested revocation. Before connecting, test that revoking the application password cuts access instantly.

llms.txt: what it is and what it is NOT

There is a confusion around agents in WordPress worth clearing up. llms.txt is not a configuration for processing documents, and it is not a file that helps an OCR or LLM pipeline read receipts.

It is a Markdown text file at the root of the site that explains to a language model what your site contains and where the important parts are. Its audience is the assistants and agents that read the web, not your backend.

This very site publishes one at /llms.txt. An example structure looks like this:

# Samuel Torres — software and cloud engineer

> Custom backend, Linux servers and AI automation in Mexico City.

## Cases
- [Panini Fan Zone](https://samueltorres.dev/en/cases/panini-fan-zone/): 80,000 folios with OCR + LLM verification.

## Services
- [AI automation](https://samueltorres.dev/en/services/ai-automation/): OCR and LLM pipelines.

## Optional
- [Blog](https://samueltorres.dev/en/blog/): technical articles.

What llms.txt does:

• It provides curated context. Instead of the model guessing from menus and footers, you hand it a summary with links.
• It prioritizes. The top sections are the essentials; the "Optional" section is what can be skipped when space runs short.

What it does not do:

• It does not control crawling. That is still what robots.txt is for.
• It protects nothing. It is public by definition. Never list internal routes, API endpoints or anything you would not want to see in a chatbot's answer.
• It does not replace the REST API. It describes your content; it does not give an agent tools.

In a folio system, then, llms.txt only describes the public side: what the promotion is, how to take part and where the rules are. Receipt processing lives in the backend, far from that file.

Improving folio processing (with or without an agent)

If the goal is to process folios better, most of the improvement does not come from an agent. It comes from hardening the pipeline. This is what pays off most:

• Business rules live in code and in the database. The model proposes whether a receipt qualifies; unique constraints and validations decide. In that project's registration module, a composite unique index per activity is what prevented duplicate registrations.
• Filter before calling the model. If OCR returned empty text, reject right there. Every call you avoid is cost and latency you do not pay.
• Treat receipt text as data, never as instructions. Pass it to the model clearly delimited, with a fixed task. If an agent ever reads it, this rule becomes critical.
• Ask for structured output and validate it. Fixed fields, fixed types. Whatever does not match the format gets flagged for review.
• Test concurrency. That project's suite included a test with 50 simultaneous workers hitting the same route to confirm that exactly one registration won each slot.

With that solid pipeline in place, a support agent on top is a useful addition: it answers questions about folios using the read-only tool, and leaves proposals when something needs fixing.

Order matters. First a deterministic system that works with no AI in the decision loop. Then, if it adds value, an agent that queries it with minimal permissions.

What NOT to do

• Connect the agent with an administrator user. It is the fastest way to a demo and the most dangerous in production. The agent inherits everything that user can do, including installing plugins.
• Give it direct write access to business data. Changing folio statuses, deleting records or sending emails without human approval turns every model error into an incident.
• Let the agent read user input without isolating it. The text of a receipt or a form can carry instructions. If the agent has write tools and reads that text, an outsider can try to steer it.

The next step

Integrating AI agents in WordPress is not a connector problem. It is a permissions problem: which tools exist, who can use them, what gets logged, and what requires a person.

If your team wants to connect agents to a WordPress site with business data, harden an OCR + LLM pipeline, or audit what its REST API exposes today, at Conqr Digital Agency we design architectures that scale. Let's review your case.

The folio system that inspired this article is documented in the Panini Fan Zone case study. And if you are looking to automate processes with AI, take a look at the AI automation service.

FAQ

What is the difference between an LLM pipeline and an AI agent?

In a pipeline, your code decides the order of the steps and the model only solves one of them. In an agent, the model decides which tool to call and with what data. The agent is more flexible, but every tool you give it is a door it can open.

How do I connect an AI agent to WordPress safely?

With its own user and a minimal role, a revocable application password, REST API routes with a permission_callback and a dedicated capability, and a log of every call. Start with read-only access.

What is llms.txt for in WordPress?

It is a file at the root of the site that summarizes, in Markdown, what the site contains and where the important parts are, so a language model can read it better. It does not control crawling and it does not process documents.