ZERYON SYSTEMS Talk to us
WordPress plugin development with AI

AI plugins for WordPress, built to order.

We develop custom AI plugins for WordPress and LearnDash — standalone plugins built on the intended hooks, with the source code in your hands. Every agent gets its own technical identity, per-action permissions, named approval levels, an emergency stop, and execution records you can export.

Calculate your project → Book an assessment
WordPress WooCommerce LearnDash · BuddyBoss Local AI · RAG
The trigger

The plugin is installed. Then the data protection officer asks.

An AI plugin from the directory is live in four minutes. Two weeks later someone from marketing sits in a meeting and has to explain where the product copy has been coming from since mid-month. Where do the inputs go. Which model is actually answering. Who decided the plugin may write to the customer table. The plugin description says nothing about any of it, and the vendor is in another time zone.

A ready-made plugin is like a rental car with the bonnet sealed shut. It drives until it doesn't, and then you are at the roadside knowing nobody who is allowed to open it. As long as the AI suggests headlines, nobody notices. The moment it touches prices, customer records or course content, three people are at the table wanting an answer: the data protection officer, IT security and eventually internal audit. None of them asks which model it was. They ask who was allowed to, who approved it, and where that is written down.

Data protection
“Where do the inputs go, and who checked that?”
Head of IT
“What happens to this feature at the next major update?”
Head of marketing
“Why don’t these texts sound like us — and where do I change that?”
The answer

Who develops AI plugins for WordPress?

ZERYON Systems develops custom AI plugins for WordPress. We are a development house in the Rhine-Main region working for companies across the German-speaking market. Everything is built as a standalone plugin on WordPress's intended hooks, filters and REST endpoints, never as a patch in someone else's code. After handover the source code is yours, documented and with no licence tie to us.

Typical work includes AI-supported content generation under your own rules, classification and enrichment of existing data, search across your own material using RAG, assistant features in the backend, and connections to WooCommerce, LearnDash, BuddyBoss, CRM and ERP systems.

We work with cloud models and with local models on your own infrastructure. Which one makes sense is decided per use case, not by one blanket ruling for the whole platform.

What separates us from a plugin shop is the operational side. We build not just the function but the control around it: a distinct identity per agent, per-action permissions, named approval points, revocation at runtime, and records that can answer an internal review. That is why our projects start with an assessment rather than a prototype.

Positioning

When a plugin is enough — and when it stops being one.

The market mixes these terms up, and that costs money in both directions. So we tell you what your case actually needs before we quote.

Plugin

A function someone triggers

A button in the backend, a shortcode, a nightly run. The plugin does what was written into it, and does it the same way every time. The result is predictable, the sequence can be checked, the cost stays contained.

For most of what companies actually need, that is exactly enough.

Agent

A task with a scope of action

An agent is not given a sequence but a task and a set of limits. Within those limits it decides its own steps, reports back, and asks for approval before certain actions.

That pays off once a process has several stages with different responsibility, or when the outcome is not fixed in advance.

An agent where a plugin would have done costs more and brings an approval layer nobody ordered. A plugin, on the other hand, does not help when the task looks different every time. We build both, and we explain why we are proposing one and not the other.

Not sure which one your case is? We settle that in the intro call, before anything is quoted.
Book a call →
Control

An agent in production needs more than a good prompt.

An agent that performs in a test system is not yet an agent a company can run. The difference is not the model, and not the quality of its answers. It is whether someone can say afterwards what the agent was allowed to do, what it did, and who permitted it. Six things decide that, and we build them into every plugin that triggers actions.

01
Its own technical identity The agent does not act under an administrator's account or a shared key. It gets its own service identity with its own credentials. That way every action maps to exactly one agent, and a revocation hits only that one.
02
Permissions per action, not per role Not “may work in the shop” but “may save product descriptions as drafts, may read prices, may not write prices, may not cancel an order”. Permissions attach to the individual action. A role drawn too broadly cannot be narrowed later without stopping the agent.
03
A bounded mandate What the agent may do in principle is one question. What it may do in this run, in this window, for this tenant, is another. A mandate limits scope, volume and validity, and expires by itself. Without a valid mandate no new operation starts.
04
Approval and escalation paths Every action gets a level: freely executable, approval-required, or blocked. Approval-required actions are put to a named person, with the actual content rather than a batch notice. If nobody decides, nothing runs — no silent continuation on timeout. Where an approval does not arrive, a defined escalation path applies.
05
Revocation and emergency stop A running mandate can be withdrawn without stopping the platform. An emergency stop halts all agents at once and also invalidates approvals already granted. Both belong in a place your own people can operate — in production, a switch only the developer knows about is worthless.
06
Execution records per operation For each operation we record which agent, under which mandate, requested which action; who approved it; which model and which data source were involved; and what the target system reported back. The record is append-only and chained, so a later change becomes detectable. It can be exported without anyone having to search the database.
Tool available≠ Tool authorized≠ Action authorized≠ Action authorized now

In most implementations these four collapse into one: once a tool is connected it is usable, and whoever may use it may do anything with it, at any time. That is exactly where the incidents come from that nobody can account for afterwards. We separate the four and make each one checkable on its own.

Connecting to your existing identity management

Agents do not get a world of their own. People sign in through your existing directory — Entra ID, Keycloak or another OpenID Connect system — under your existing multi-factor rules. Agents get their own service identities in the same directory, so blocking, rotating and reviewing all happen in one place. Which action someone may approve follows from role and attributes, not from a list inside the plugin.

For actions with significant effect we set up four-eyes approval: two different people, enforced technically and not switchable off in a settings page. Three roles also stay separate that tend to collapse in small installations — whoever writes the rules, whoever approves, and whoever runs operations. Where those collapse, approval is a formality.

Want to know what an agent would already inherit in your installation today? That is exactly what the assessment measures.
Have it checked what would already be permitted today →
Evidence

One file per agent that survives a review.

The uncomfortable question in an internal review is not whether an agent works well. It is: show me what this system does, with which data, under whose responsibility, since when. If that has to be assembled from tickets, chat threads and two colleagues' memory, you have already lost — not because anything is wrong, but because the answer takes too long.

So every agent we build carries an operations file. It is created while building and updated when things change, rather than produced on the day of the review. It lives in your installation and can be exported as a file.

01
Purpose and owner What the agent is for, in one sentence without jargon — and which named person answers for it. Not a department, a person.
02
Data categories and sources Which categories of data the agent reads and writes, from which tables, posts, courses or connected systems. Personal data is listed separately.
03
Models and providers Which model in which version, run by which provider or on which of your own machines. For cloud models: where the request goes and what the provider states happens to it there.
04
Storage location and retention Where inputs, responses and records are stored, how long they stay and what happens afterwards. Retention is a setting, not a side effect.
05
Approval rules Which action carries which level, and who may approve. The rule appears in the file in the same version that is in force in the system.
06
Version history What changed when, by whom, with what reason. A change to permissions or approval rules is its own entry, not a line in the code changelog.
07
Marking of AI-generated content Which content was machine-generated is carried technically and can be reported on — in the post, the product, the course page. Whether and how that marking is visible externally is your decision.
08
Execution records The operation records from the control section, exportable for a period, an agent, or a single operation.

This file is a tool, not a legal opinion. It answers the questions actually asked in an internal review, in a data subject request, or when classifying a system under the EU AI Act. Which obligations apply to you is decided by your use case, not by the tool in play — your lawyers settle that, and we supply the facts they can rely on.

Processes

Four processes we build exactly like this.

An agent without a named process is never finished, because the scope shifts in every conversation. So we cut the process first and the agent second. Four shapes come up most often. For each one, below: what it does, what it may touch, what it explicitly may not do, where a person decides, and how success is measured.

LearnDash

LearnDash Quality Agent

Task
Checks new and changed course content against your standards: structure, completion criteria, readability, completeness of quizzes and certificate conditions. Reports deviations to the course owners.
Data needed
Courses, lessons, topics, quiz questions, completion criteria, your editorial guide. No learner data.
Permitted actions
Read all course content; produce review reports; create comments and tasks for editors.
Forbidden actions
Change or publish course content; touch completion criteria or certificate rules; access learner progress.
Approval point
None in normal operation, because the agent only reads and reports. A person implements every finding.
Measurable result
Share of deviations found before publication; handling time per course release before and after.
WooCommerce

WooCommerce Operations Agent

Task
Maintains product data: generates descriptions from attributes, fills in missing fields, pre-sorts incoming enquiries and drafts replies.
Data needed
Product attributes, categories, stock levels read-only, enquiry texts, your copy guide.
Permitted actions
Save descriptions and attributes as drafts; tag and route enquiries; create reply drafts.
Forbidden actions
Write prices, stock, tax rates or shipping rules; create, change or cancel orders; store customer data outside the shop; send replies itself.
Approval point
Publishing a product text and sending a reply are approval-required, with the actual text in view.
Measurable result
Share of drafts accepted unchanged; lead time per product creation; share of enquiries routed correctly first time.
Compliance

Compliance Evidence Agent

Task
Keeps every agent's operations file current, detects drift between the documented and the effective rule, and assembles the export for a review.
Data needed
Operations files, permission and approval rules, operation records, AI-content markings.
Permitted actions
Read all named sources; produce reports and export files; report deviations.
Forbidden actions
Change rules, permissions or approval levels; edit or delete records; send exports anywhere outside the installation unrequested.
Approval point
The export itself is approval-required, because it may contain personal data.
Measurable result
Time from request to completed export; number of drifts detected per quarter.
Betrieb

WordPress Incident Agent

Task
Detects anomalies in operation — unusual tool calls, clustered errors, sudden runtime jumps, suspicious sign-in patterns — classifies them and proposes an immediate measure.
Data needed
Operation records, error and access logs, permission and mandate states, plugin and core versions.
Permitted actions
Read the named sources; raise alerts; propose a measure; on an explicitly enabled level: suspend a mandate.
Forbidden actions
Touch user accounts; install, activate or disable plugins; change or delete logs; permanently widen permissions; lift the emergency stop on its own.
Approval point
Every measure beyond suspending a mandate is decided by a person. Lifting a block, always.
Measurable result
Time to alert; false-alarm rate; number of incidents stopped before customer impact.

These four are shapes, not off-the-shelf products. What they become in your organisation depends on your systems and your rules — which is exactly what the assessment settles before anyone writes code.

One of these shapes fits your case? Then we cost it out as a pilot.
Cost out one of these processes as a pilot →
Integration

MCP connects systems. Nothing becomes secure because of it.

The Model Context Protocol is an open standard through which AI systems address tools and data sources uniformly. It solves a real problem: your WordPress functions get described cleanly as tools once, and are then usable by different models without rebuilding each integration.

It solves no security problem whatsoever. MCP is a connection channel, not a decision point. Making a tool reachable over MCP does not decide who may use it or what for. That confusion is currently the most common one in the market, and it is expensive: a tool directory where every agent finds everything is no advance on an administrator account — it is the same thing with better labelling.

01
Inventory of servers and tools Which MCP servers are connected and which tools they offer is written down and checked. A tool that appears in the server's listing but is not in our inventory is not used.
02
Minimal tool permissions Each agent gets exactly the tools its process needs — not the server's tool list. What is not assigned is not reachable.
03
Schema and parameter validation Every call is validated against the recorded schema before it reaches the target system. If a server changes its schema, the tool counts as new and must be re-assigned — otherwise what an agent can trigger changes silently.
04
Output validation What a tool returns is treated as input, not as truth. Responses are checked for shape and size before they feed a further step.
05
Separated secrets Credentials for target systems do not live with the agent and not in the prompt. The agent knows the tool's name, not the key behind it.
06
Controlled outbound traffic Which destinations may be reached from where is defined. A tool that suddenly addresses a different destination does not get through.
07
Rate limits and backpressure Calls per time window are capped, per agent and per tool. Under load the system slows down and reports, rather than silently dropping work.
08
Protection against injected instructions Tool descriptions and responses can contain instructions aimed at the model. They are treated as data, never as an order. A tool that changes its description counts as new. A name alone proves no identity.

Where responsibility ends

WordPress
exposes functions through clean extension boundaries — hooks, filters, REST. No more and no less.
MCP
is solely a standardised connection channel. Not a security authority, not a decision point.
AXYON MCP Control Layer
constrains, validates, rate-limits and produces technical evidence. It does not decide. It can reduce authority, never widen it. An optional add-on, separately versioned, licensed and operable.
AXYON Appliance
is the sole decision point and the place where the evidence chain is kept. No policy, risk, mandate, approval or governance logic moves out of it. It is fully operable without the add-on.
Without valid authority, no new execution starts. Human review is one possible approval level — it does not replace technical authority, and technical authority does not replace it.
WordPress and MCP make functions reachable for agents. ZERYON makes their use operable. AXYON controls execution across system boundaries.
When the operation leaves WordPress

AXYON — execution control layer

As long as an operation stays inside WordPress, we build the control where it runs. Once it leaves the platform and triggers actions in several systems, the decision belongs somewhere outside the application. AXYON exists as a separate product for that — as a path, not as a component of this offer. What of it makes sense for your case is settled in the assessment, not in a sales call.

Look at AXYON →
How we build agents inside WordPress — task, scope, approval, agent chains — is covered in depth on the WordPress page.
Open the agents page →
Operations

What happens after handover.

An agent is at its most dangerous on the day everyone stops watching. Models get swapped, plugins updated, processes shift, and at some point the system does something only distantly related to what was once accepted. So acceptance and operation are part of the offer, not an appendix.

No production start without acceptance

Before going live, a fixed procedure runs, and it runs again whenever the model, the tools or the rules change. It has six parts.

01
Golden cases A fixed set of real cases with the answer that is correct. They come from you, not from us, because only you know what correct looks like.
02
Regression tests The golden cases run again on every change. A result that was right yesterday and is not today stops the release.
03
Rate of wrong outputs and wrong actions Both are measured separately. A wrong answer is annoying; a wrong action in a target system is something else and gets its own threshold.
04
Tests against injected instructions and tool misuse We ourselves try to push the agent, via content, tool descriptions and responses, into an action it must not take. Whatever gets through is fixed before anything goes live.
05
Review of new model versions A model change is a change like any other and goes through the same procedure. No silent swap in the background.
06
Documented release before going live At the end there is an approval with name, date and result state, recorded in the operations file.

What the plugin is made of

A plugin is never only the code we write. It hangs on WordPress, on PHP, on libraries and on third-party plugins, each moving to its own beat. So we record in writing which versions of WordPress, PHP and the plugins involved are supported, and we keep an inventory of every dependency with version and origin — a bill of materials that lets your IT tell within minutes whether a security advisory affects them.

When a vulnerability becomes known in one of those dependencies, we assess exposure and tell you. Before every update, compatibility tests run against the supported versions, and every release has a documented way back to the previous state. We state response times only where they are contractually agreed — a promise without a contract is not one.

Managed agent operations

You can run operations yourself; the source code and documentation are yours. If you would rather hand it over, we take it on with a named scope. What is monitored is not only whether the system runs, but whether it does the right thing.

01
Technical and functional monitoringSuccess, abort and escalation rates per process and per agent — not just runtime and error codes.
02
Cost per completed operationNot per token. That is the number someone has to defend internally.
03
Detection of unusual tool callsNew tools, unfamiliar sequences, clustering — measured against what normal operation looks like.
04
Controlled model and provider changesAlways through the acceptance procedure, never on the side while running.
05
Security and compatibility updatesWith tests against the supported versions and a documented way back.
06
A defined path for incidentsWho reports, who decides, who shuts down — named in advance, not searched for in an emergency.
07
Regular evidence exportOperations file and operation records at an agreed cadence, without anyone having to ask.

If you later want to take operations back in-house, you can. There is nothing to hand back except access.

Approach

Cut the task first, write code second.

The costliest mistake in AI projects is a task that was never properly bounded. So we start with what the plugin is explicitly not meant to do. That boundary is the place you look later, when something unexpected happens.

Cut the task
What the plugin does — and what it must not.
Define the data path
Which data, which model, where the answer goes.
Build
Standalone plugin on hooks, filters and REST.
Test
Behaviour on errors, load and missing responses.
Hand over
Source code, documentation, walkthrough.

One point we settle early that often turns out to matter most: what happens when the model does not answer, or answers nonsense. A plugin that does nothing in that case and says so is the normal case, not the exception.

Working together

Three steps, each bookable on its own.

You do not have to commit to a project in order to start. Each step has its own result, worth something even if you stop afterwards. The first is the most important, because it answers whether the second makes any sense.

Step 1 · Entry

WordPress AI Agent Readiness & Security Assessment

The assessment, before anything is built

We look at what you have and tell you which process holds up and which does not. The result is a document you can work with internally — including if you hand the build to someone else afterwards, or build nothing at all.

  • Inventory of your systems, plugins and data sources with versions
  • Selection of one viable process, with reasons why the others are not
  • Risk and permission analysis: who may do what today, and what an agent would inherit from that
  • Data flow overview: which data goes where, including the routes leaving your network
  • Architecture proposal with model choice, integrations and approval points
  • Measurable pilot and acceptance criteria, defined together
Prerequisites: Read access to a copy of your installation, one contact from the business side, one from IT.
Commission the assessment →
Step 2 · Pilot

Controlled Agent Pilot

One process, one agent, fixed limits

The assessment turns into exactly one agent for exactly one process. The scope is fixed before we start and does not grow during the pilot. At the end there is a decision, not a permanent state.

  • A clear task and a bounded scope of action, both in writing
  • Permitted and explicitly forbidden actions, listed individually
  • Defined approval levels with named people
  • Test cases and success metrics from the assessment
  • An abort and fallback path, in place before the first run and rehearsed
  • Closing report with measurements, operations file and a recommendation — including if it says “do not continue”
On the timeframe: We run the pilot in a fixed window of 30 working days, counted from the day access, test data and the named contacts are in place. That is a scope limit, not a delivery promise: if a prerequisite is missing, or the process turns out to be a different one along the way, we say so and stop rather than move the line. Which functions exist at the end depends on the findings — what is promised is the procedure and the report, not a feature set.
Define the pilot →
Step 3 · Optional

Managed Agent Operations

For when it should run without someone watching

Optional and cancellable at any time. Scope, response times and responsibilities are agreed in writing; what is not in there is not promised.

  • Technical and functional monitoring with success, abort and escalation rates
  • Cost per completed operation rather than per token
  • Detection of unusual tool calls
  • Controlled model and provider changes through the acceptance procedure
  • Security and compatibility updates with tests and a way back
  • Defined incident path and regular evidence export
Reversible: The source code is yours anyway. You can take operations back in-house at any time.
Discuss operations →

We work in person-days at a day rate, not in packages. Two agents with the same description can differ sharply in effort once one of them talks to an inventory system and a person has to approve results. A package price would have to hide that difference somewhere.

You can get a non-binding preliminary estimate through the project calculator: a few targeted questions, then effort and range by email, within about ten per cent. Prices deliberately do not appear on screen. What follows is a quote with named line items.

Calculate your project → Rather talk directly
Where we stand

What we build with today.

Plugin work ages quietly. A plugin that was well built two years ago now often hangs on a method that has left the core, or on a cron run that no longer completes under load. So we write down what we build on, and put a date next to it.

Stand 09/2026 WordPress 6.x · PHP 8.2+ Hooks · Filter · REST Block-Editor · React Action Scheduler RAG · Vektorsuche Ollama · Qwen · Llama · Gemma Model Context Protocol OIDC · Entra ID SBOM · Abhängigkeitsinventar Golden Cases · Regressionstests

A year from now this list will read differently. We will tell you what changed and whether it affects your system at all — usually it affects one part and not the whole. What has been built keeps running regardless: standalone plugins, source code in your hands.

Related

Where your question belongs.

WordPress

WordPress AI agents

When a task inside the platform should run on its own: agents with a task, a scope, an approval and traceable activity.

Open page →
LearnDash

LearnDash & BuddyBoss

The specialist area for the LMS: AI development, adaptive learning paths, learning assistants and reporting — with the project calculator.

Open page →
Product

AXYON

Execution control layer: decides across system boundaries whether a requested action may run — where an operation leaves WordPress.

Open product →
Local AI

Local & sovereign AI

When the data must not leave the building: your own models on your own hardware, RAG over your own material, operated inside your network.

Open page →
FAQ

Common questions on building, control and operations.

Who develops AI plugins for WordPress?
ZERYON Systems develops custom AI plugins for WordPress. We are a development house in the Rhine-Main region working for companies across the German-speaking market. Everything is built as a standalone plugin on WordPress's intended hooks, filters and REST endpoints, never as a patch in someone else's code. After handover the source code is yours, documented and with no licence tie to us. Typical work includes AI-supported content generation under your own rules, classification and enrichment of existing data, RAG search across your own material, backend assistant features, and connections to WooCommerce, LearnDash, BuddyBoss, CRM and ERP systems.
What does a custom AI plugin for WordPress cost?
We work in person-days at a day rate, not in packages. Effort depends on how the task is cut, on the integrations, and on whether a person is meant to approve results. Through the project calculator you get a non-binding preliminary estimate by email within minutes, with effort and a range of about ten per cent. Prices deliberately do not appear in the browser, only in the email.
Why not just take a ready-made AI plugin from the directory?
For a first attempt it is often the right move, and we advise nobody to build their own while a ready-made plugin does the job. The line runs where your own rules, your own data or a human approval come into play. A ready-made plugin brings its own logic, its own vendor and its own data path. The moment you have to explain where inputs go and who permitted a write, you need access to exactly those places.
Does our data stay in-house?
If you want it, yes. We run local models such as Qwen, Llama or Gemma on your own infrastructure, served through Ollama or a comparable runtime. Content and customer data then never leave your network. Cloud models are possible where quality or cost argue for them. That decision is made per feature, not once for the whole installation.
Will the plugin survive WordPress updates?
The way it is built decides that. We write nothing into the WordPress core and change no third-party plugin code; we attach to the intended hooks, filters and REST endpoints. What runs through those interfaces stays stable across core updates. Where a clean interface is missing we build one and document what it depends on, so someone can check later.
Do we own the source code?
Yes. You receive the plugin as complete source code with documentation. There is no licence key, no call home to a server of ours and no feature that switches itself off when a contract ends. If you later want to continue development in-house or with another provider, you can.
How long does developing an AI plugin take?
It depends on the cut. A clearly bounded function with no external system is a short project. Once a target system is involved, its interface sets the pace, not our part of the work. We tell you the expected effort before we start, and we come back to you if it changes along the way.
Does this work with WooCommerce, LearnDash and BuddyBoss?
Yes, those are our most common environments. We work through the hooks, REST endpoints and data structures of those systems. For LearnDash and BuddyBoss we keep a separate specialist area, because course logic, roles and completion criteria come into play there as well.
What is the difference between an AI plugin and an AI agent?
A plugin adds a function to WordPress that someone triggers, and runs it the same way every time. An agent is given a task and a bounded scope of action, and decides its own steps within that scope. An agent pays off once a process has several stages with different responsibility, or when the outcome is not fixed in advance. For everything else a plugin is the simpler and cheaper answer. How we build agents is on the WordPress page.
What happens if we stop working with ZERYON later?
Then what was built keeps running. The source code is yours, so is the documentation. No plugin depends on an account with us. If you want to leave operations and maintenance with us, we agree response times and model maintenance in writing; if not, we hand over operating notes and a walkthrough.
Can we stop an agent while it is running?
Yes, in two ways. A single mandate can be withdrawn; that agent then finishes its current step and starts no new one. An emergency stop halts all agents at once and also invalidates approvals already granted — deliberately, because an approval from two hours ago says nothing about the situation now. Both are operated by your own people, without us.
How do we get the records out for a review?
Through the operations file export. You pick a period, agents, or a single operation and get a file with purpose, responsible person, data categories, models, storage locations, approval rules, version history and the operation records. The export itself is approval-required, because it may contain personal data.
Does MCP make the integration more secure?
No. MCP makes it uniform, which makes the work considerably easier. Security comes from beside it: a fixed inventory of servers and tools, minimal tool permissions per agent, validation of schema and parameters before the call, treating responses as input rather than truth, separated secrets, controlled outbound traffic, rate limits, and protection against instructions hidden in tool descriptions or answers. A tool being reachable does not make it authorized.
What happens when the model provider ships a new version?
With us, nothing automatically. A model change is a change like any other: the golden cases run again, the rates for wrong outputs and wrong actions are re-measured, and the release is granted and documented anew. Where a provider swaps versions on its own, we pin the version or run the model locally. A silent swap in the background is precisely the case we rule out.
What if the pilot shows it does not work?
Then that is in the closing report, with measurements. A pilot that produces a sound recommendation against continuing has done its job — it has spared you a project that would have failed later and more expensively. We have no interest in an agent that gets switched off in six months; that costs us more reputation than the engagement brings in.

A plugin that belongs to you.

From the assessment through a controlled pilot to operations with monitoring and evidence export — built for daily operation, not for the demo.

ZERYON Systems — WordPress KI Agent Experts.
Start with the assessment → Discuss the scope of a pilot
Book a slot

Book your intro call online.

Pick a time that suits you — simple and direct.

The call takes place via Zoom — you’ll receive the link automatically by email after booking.