Capabilities
Systems built around the job, not the model
A useful system starts with a task someone needs to finish. We choose the architecture after the task is clear: ordinary software where rules are enough, retrieval where facts are needed, and an agent where several steps require judgement.
The parts of a system
- Input
- Approved data and tools
- Reasoning or fixed logic
- Human check
- Output
Where rules are enough, the middle step is ordinary code. Where an action has consequences, the human check comes before the output.
Agent systems and workflows
Build a system that moves from an input to a checked result. It may read records, use tools, evaluate an answer and prepare the next action for approval.
Possible brief
Research a shortlist of partners, score each against agreed criteria and prepare a CRM record. A person approves the record before it is written.
Controls
Representative test cases, known stop conditions, human confirmation for consequential actions, logs and error handling.
MCP servers and plugins
Connect AI interfaces to the tools and data your team already uses. The system defines what can be read, what can be changed and which actions need approval.
Possible brief
Ask an assistant to find people who attended a specific event and prepare a targeted message. Sending remains a separate, authorised action.
Controls
Authentication, least-privilege permissions, validated inputs, rate limits, logging and explicit write boundaries.
Generative production
Design a repeatable production process for text, images, video or speech. Approved formats and source material determine what can be generated, how it is checked and who can release it.
Possible brief
Turn a campaign brief into reviewed visual and audio variations for different markets, with the source assets and approvals recorded.
Controls
Brand rules, rights to source material, provenance, human review, cost limits and quality checks. Not every model output is fit for release, and a new medium may stay exploratory until its production scope is tested.
Voice and interactive experiences
Create a speech or natural-language interface around a useful action. The interface should know what it can answer, when it needs another tool and when a person must take over.
Possible brief
Let customers ask about bookings, hear an answer from approved records and request a change that staff confirm.
Controls
Latency requirements, speech evaluation, error recovery, accessibility, privacy, escalation and a non-voice fallback.
Prototyping is part of the work
Before a full build, we can make the interaction real enough to test with the people who would use it. The result is a demonstration and a clear decision to build, change or stop.
If your team would rather work with PJ directly on a defined piece of work, that is an engagement of its own.