We use AI, and we will tell you exactly how
Some firms selling AI services are quietly uncomfortable about how much AI is in their own work. Pagetrends is not, because AI helping people work is where this is going. We use AI throughout what we build. Our Model Context Protocol takes a design produced by an AI system and rebuilds it as clean semantic markup inside a client’s existing content platform. Our content work applies AI against briefs derived from thirty years of accumulated search practice and grades the result on a scorecard before anyone ships it.
The declaration is the easy half. What makes it credible is the machinery around the model, which is also the thing a client is buying when they ask us to put AI into their own operation.
The failure behind the statistic
Research from MIT last year found that roughly 95 percent of enterprise AI pilots produced no measurable business impact. That number gets quoted as evidence the technology is oversold. What it actually measures is a deployment failure, and that failure has a consistent shape. A capable general purpose model gets connected to a business process. It produces output that is fluent and plausible, though nobody can verify it. Either the manual review consumes the time savings, or it stops happening and errors enter the business quietly. Within a quarter or two the initiative is abandoned, while the postmortem concludes that the AI was not ready.
The AI was usually fine. What was missing was any mechanism to determine whether its output should be allowed through.
Constrain the output, not the model
The engineering principle underneath everything we build is that what a model returns should be checked by something other than a hopeful human reading it. Our MCP is the clearest example we can point to, and anyone can verify it by viewing the source of a page it produced. The protocol classifies a design’s structure and types its editable regions against a closed vocabulary the system enforces. Composition stays open so a designer can build anything, while the parts a machine must understand are drawn from a defined set that can be checked mechanically. Output that does not conform does not ship, and no human has to notice the problem for it to be caught.
That is a general principle rather than a trick specific to markup. An agent proposing a record entry writes into a system with schema validation and referential constraints, so a malformed proposal is rejected by the system rather than by a reviewer’s attention. An agent resolving a data conflict proposes with its reasoning attached and cannot commit without approval. An agent generating a document works from a template whose required fields are enforced. In each case the model is doing interpretive work it is genuinely good at, inside a boundary that makes wrong answers detectable.
"The question worth asking any AI vendor is not how capable their model is. It is what happens when the model is wrong, and how you will find out."
Where the human belongs
Automating the wrong half is the most common mistake in this field, and it is the mistake that has flooded the market with content and output nobody wants. The correct division is straightforward. Machines take the tireless work: scanning volume no person would get through, reading every exception, applying a rule consistently across ten thousand records, monitoring continuously. People take the judgment: deciding what matters, deciding whether a result is actually right, and owning anything that touches money, a customer commitment, or a legal obligation.
There is a practical version of this rule for clients. Anywhere a wrong answer costs real money or damages a customer relationship, a person approves before it commits. Everywhere else, the system proceeds and a person reviews after. Deciding which category each process falls into is most of the design work in an AI integration, and it is a business decision rather than a technical one, which is why it happens in discovery with the people who own the consequences.
What integration means for software never designed to accept AI
Most business software in service today was built before any of this existed. It has an API designed for data exchange rather than for reasoning, a data model that assumes a human is interpreting the screen, and no concept of an actor that proposes rather than executes. Bringing AI into that environment means building the surrounding structure the software does not provide. A place for a proposal to sit before it becomes a record. A representation of the business context the model needs. A validation layer between the proposal and the system of record. An audit trail capturing what was proposed, what was approved, and by whom. A path for the exceptions that fall outside what the agent should decide.
That surrounding structure is the actual deliverable in a custom AI integration. The model is a component, and increasingly a commodity one, while the surrounding system is not.
Building for models that keep changing
Model capability improves on a cycle measured in months, which means anything built to the specific quirks of one model is a maintenance liability. We build the boundary, the validation, and the human approval path as the durable parts of the system, and treat the model itself as replaceable. When a better one arrives, it slots in behind the same constraints, and the business does not experience a rebuild.
How the engagement runs
Discovery, design and the substantial majority of the build happen through screen shared working sessions. Onsite is available when the work genuinely earns it. Agent design specifically is covered in custom AI agents. Deciding what to automate first, and what is not worth automating at all, is covered in AI consulting.