AI Practitioner
Skills, Tooling, and Governance Practice
Brian Jolley builds AI systems that hold up outside a demo. The practice covers five areas: designing and orchestrating multi-agent systems, building governance and reliability into AI workflows, engineering the environment those workflows run in, structuring content and data so machines can read it, and measuring whether any of it worked. What follows is what he can do and the built evidence for each part, rather than a list of places he has worked.
Agentic Architecture and Orchestration
Brian Jolley’s working environment holds more than thirty agent definitions, each with a defined role, its own tool access, and a research base it is expected to argue from. Five of them are deliberative councils, where members hold positions across structured passes, cross-examine each other by name, and finish with dissent recorded and attributed instead of averaged into a consensus nobody actually holds.
Above the individual agents sit orchestrated multi-phase pipelines. One skill runs three dependent phases in sequence, passing file paths between them, with human approval gates placed where a wrong answer would propagate into everything downstream.
Testing his own architecture. In August 2026 he ran a four-arm ablation on that council design, to find out whether the scaffolding was doing real work or just looking like it. The arms were named expert personas running the full protocol, the same protocol with the names stripped out, bare independent samples with no protocol at all, and a single model at a matched token budget.
The results went against the elaborate arms. The only genuine verification act in the whole run, a live web search checking a claim against reality, happened unprompted in the least structured arm. Named personas matched anonymous lens-differentiated reviewers rather than beating them, and produced one live instance of the overconfident citation the review was about in the first place. Bare independent samples reproduced almost the entire finding set at a fraction of the cost. His conclusion was that protocol elaborateness had substituted for verification behavior rather than producing it, and that the protocol earns its cost through dialectic refinement and preserved dissent, not through finding things a simpler method would miss. The report states its own limits plainly: one question, one run per arm, and all four arms sitting on the same underlying model.
The point is not the finding. It is that the experiment was designed to be capable of embarrassing the thing it tested, and the result was written down when it did.
AI Governance and Reliability Engineering
Most AI work right now treats reliability as a prompting problem. Brian Jolley treats it as a systems problem, where governance, data isolation, and verifiability are architecture decisions rather than conversational ones.
Deterministic control layers. His approach centers on multi-step workflow pipelines that separate what a user asks for from what a model is actually allowed to do with it. That means structured rules engines, data isolation, model routing so no single vendor owns the reasoning stack, and auditability built in rather than bolted on afterward.
A diagnostic framework for failure. Production AI failures get sorted into three separately-fixable modes rather than one generic “hallucination” bucket: context drift, training-data contamination bleeding into outputs, and unspecified relationship inference. Each has a different architectural fix, and none of them are solved by better prompting.
Requirements traceability. A four-loop workflow lifecycle covering requirements, build, test and debug, and run turns a business process into a deployable AI workflow. Inside it, an elicitation chain running from BRD to PRD to SRD to UI spec to API contract keeps a workflow’s actual behavior traceable back to a documented business requirement instead of an assumption baked into a prompt. The framework accounts for the failure points this kind of pipeline tends to hit, including deduplication logic, dangling state references, and save-time validation gaps, with process fixes rather than one-off patches.
Human-gated production. Every production repository in his practice sits behind the same rule: branch, commit, pull request, human review, and no direct pushes to the main branch. Because those repositories deploy automatically on merge, the review gate and the production gate are the same gate. Automation writes the change, a person decides whether it ships.
Development Environment and Workflow Engineering
Brian Jolley operates a configured, version-controlled AI development environment built on Claude Code, Anthropic’s CLI tool. It is not a default installation.
Instruction files inject scoped context automatically, so rules that must never be violated (terminology definitions, forbidden client-facing language, deploy protocol) are loaded before work starts rather than remembered by whoever is at the keyboard. A persistent file-based memory system carries decisions, corrections, and open threads across sessions. Git worktrees isolate parallel work. Skills and agents are version-controlled and reviewed like code, on the same branch-and-pull-request protocol as production sites.
He wrote a number of the skills in that environment himself, including the persona buildout interview, the FAQ generator, the schema producer, the pipeline orchestrator that runs all three, the visibility audit and reporting tools, and the snapshot collector. External services are wired in through MCP connections covering mail, calendar, documents, notes, web scraping, and browser control.
He also maintains a shared knowledge base with an explicit schema, a page catalog, and an append-only change log, written and kept current by the AI rather than by hand, and used by two people working from separate machines.
Structured Data and Machine-Readable Content
Content that reads well to a person is not automatically retrievable by a machine. This part of the practice is about closing that gap.
The work covers JSON-LD @graph markup with linked entity nodes rather than isolated blocks, so an organization, a service, an audience, a page, and its questions all reference each other; llms.txt and full-text files that give an agent a clean copy of a site without making it parse layout; markdown content negotiation, so a page can hand back a plain-text version to a client that would rather have one; crawler configuration that distinguishes retrieval agents from training crawlers instead of blocking both by reflex; and chunk-level structure, where each section is written to survive being retrieved on its own, with no dangling pronouns pointing at a paragraph the agent never received.
Measurement and Evaluation
The snapshot system is the measurement piece. For a client domain, it locks a set of questions written around what a customer would actually ask an AI assistant, never around the business name, then submits each one to Claude, ChatGPT, Perplexity, Gemini, and Grok. Raw results are saved to version control with timestamps, a report is generated from them, and the whole thing runs on a schedule without a laptop attached. Partial platform failures are surfaced and retried rather than quietly dropped.
Results are reported as a visibility percentage, meaning the brand appeared in some number out of a hundred prompts, and never as a rank. That follows directly from the Fishkin research below, and it is enforced as a rule in the reporting tooling rather than left to whoever writes the report.
The ablation described earlier belongs here too. Measuring client visibility and measuring whether your own methods work are the same discipline pointed in two directions.
Where the Work Happens
Brian Jolley co-founded Found for AI with Dustin Crump, which is where the small-business side of this practice runs. Found for AI answers one question for every client: how well can AI agents understand your website?
The engagement starts with an AI visibility audit, a structured assessment of a site’s crawler configuration (are AI agents allowed in?), structured data (is there anything for an agent to parse?), content structure (is information organized for retrieval or only for visual layout?), and citation eligibility (would an agent trust this site enough to recommend it?). The audit produces a score and a set of action items. Clients either implement those themselves or hand the work to Found for AI, which builds the persona-driven pages, answer-block markup, entity graphs, crawler rules, and llms.txt files directly.
He has also published a three-post series on AI access barriers at foundforai.com/blog: “When Cookies Bite Back,” on how consent banners and coupon pop-ups block agents from reaching site content; “We Don’t Serve Your Kind Here,” on robots.txt files acting as bouncers that most businesses never intentionally hired; and “A Bot and an Agent Are Not the Same Thing,” on the difference between a crawler that indexes and an agent acting for a specific person with a specific question. An agent visiting your site is a warm lead, because a real person sent it.
Client Outcome: Brent Jagodnik
Brent Jagodnik runs Full Throttle Performance Solutions, a consulting firm that helps businesses grow by analyzing data and optimizing KPIs. He ran his site through Found for AI’s free assessment tool. First score: 34 out of 100.
He opened the advanced tab, reviewed the specific findings covering schema gaps, Open Graph issues, and other AI readability signals, and handed them to Claude to fix. Time to implement: 10 to 15 minutes. New score: 74.
He then started running his other clients’ sites through the tool and began referring Found for AI to clients and agency contacts without being asked. Nobody asked him to go on camera. He offered.
In his own words: “The discovery is the best part. When you have an assessment tool like that, you can just go to your site, put in your website, and basically hit run. It can’t get more simple than that.”
Research Grounding
These positions are not marketing opinions. Each one is grounded in cited research and enforced as a rule in the production tooling.
AI rank is not a valid metric. Rand Fishkin’s January 2026 research across 2,961 prompts found less than 1% probability of identical brand recommendation lists across two runs of the same prompt. Found for AI reports visibility percentage instead, and this is enforced in the audit report output rules.
Content written clearly for humans is optimal for AI agents. Ethan Mollick’s Wharton research finds that prompt engineering techniques do not improve responses from current frontier models. Plain, specific, factual content is both readable and citable, so Found for AI does not write “AI-optimized” copy that sounds different from good human writing.
Specificity is the only conversion lever on AI-visible pages. Urgency and scarcity framing is prohibited outright in the persona buildout skill. “Limited time offer” is invisible to an agent. “Open Monday through Saturday, 8am to 6pm, serving the greater Salt Lake City area” is citable.
Lily Ray’s 2026 work on editorial trust signals and E-E-A-T, and Semil Ulusoy’s 2026 work on RAG architecture and chunk-level optimization, cover the citation and retrieval side. Each source has a wiki page translating its findings into specific client recommendations.
The Meta-Layer
This page is an example of the work it describes. The structured data wrapping it was written for agent consumption, the content is organized for retrieval, and a markdown version is available to any client that asks for one. The tools were built, the client work was done, the writing was published, and then the same methodology was turned on his own professional presence.