There is a difference between adding an AI agent to a product and building an agent platform. The first is a feature: one LLM, one prompt, one integration, shipped and largely forgotten. The second is infrastructure: a shared runtime every agent runs on, a consistent way to define what each agent is allowed to do, and the operational machinery to keep it all working reliably in production.
Most teams build the first. We built the second.
Every AI agent in Wisry — the growth copilot, the ad-creative researchers, the video-editor assistant, Blogsmith (the writing agent that drafted this very post) — runs on one unified, in-house agent runtime. One engine, one event stream, one place to observe and improve every agent we ship. Here is the thinking behind it, and why it matters for the products you use.
An Agent Feature vs. an Agent Platform
When you bolt an LLM onto a single feature, you get a useful tool. You also get something that is hard to audit, hard to improve, and hard to trust at scale. Each integration lives in its own corner of the codebase, with its own prompt, its own error handling, and its own blind spots. When something goes wrong — or when the model gets smarter and you want to upgrade — you are touching multiple independent systems.
An agent platform inverts this. The runtime is the stable layer. Agents are guests on it: they arrive with their configuration, use the tools they are authorised to use, and produce outputs the runtime records. The product team improves an agent by changing its definition, not by rewriting plumbing.
This is the shift that makes AI agents operable rather than merely functional.
Agents Are Configuration, Not Code
In the Wisry runtime, an agent is a versioned definition: its instructions, its model choice, its tool list, and its guardrails. That definition lives in a registry, not in the codebase. It can be reviewed, activated, rolled back, and A/B-tested independently of any product deployment.
Activating a new agent version in production requires a second person’s review. This is not a formality — it is the same gate applied to any production change, now applied to the agent’s behaviour itself. The practical result is that “we updated the agent” is a deliberate, reviewable, reversible act rather than a silent side effect of a model change.
This also means the engineering team does not need to redeploy the product to improve an agent. The broader team can review what an agent is instructed to do. And when something behaves unexpectedly, there is always a specific version to point to.
Tools as a Permission System
Agents in the Wisry runtime can only use tools from a validated catalog: web research, image generation, product data retrieval, campaign operations, and others. A tool an agent is not authorised to use simply does not exist for it — it is not hidden or blocked at runtime, it is absent from the agent’s world entirely.
Sensitive tools run sandboxed. The boundary is not advisory; it is structural.
This treats capability as a permission system rather than a trust system. We do not ask agents to exercise restraint; we constrain what they can reach. The validated catalog also means every tool has been reviewed for safety, cost, and correctness before any agent can call it. New tools do not appear in the catalog by accident.
Orchestration and Observability
Some jobs are straightforward enough for a single focused agent. Others — researching a competitor’s ad strategy, generating creative variants, queuing them for review — benefit from a division of labour. For those, the runtime supports an orchestrator pattern: a coordinating agent that breaks a job into steps and dispatches them to specialist sub-agents (research, creative, publishing, and others).
Every dispatch is recorded. In the session console, any conversation can be replayed step by step: what the orchestrator decided, which sub-agent handled which step, what tools were called, and what each one cost. Cost per agent is visible — which matters when you are running agents at scale and want to know where compute is actually going.
This is observability, not just logging. The data is structured, queryable, and tied to sessions. “What happened in that run?” has a real answer.
Testing Agents Like Software
The claim “the agent got smarter” is easy to make and hard to verify. The Wisry runtime makes it verifiable.
Agent versions are scored against curated evaluation datasets before they are trusted with production traffic. A dataset is a set of inputs with expected outputs — the same principle as a test suite, applied to agent behaviour. When a new version scores better than its predecessor on the benchmark, there is evidence of improvement. When it does not, there is a reason not to ship it.
Per-user experiments extend this into production: users can be assigned to experiments that pin specific agent versions and feature values. We test agent improvements the way we test product features — with real users, measurable outcomes, and instant rollback if the numbers move the wrong way. “We are running an A/B test on the research agent” is a sentence that now has operational meaning.
What This Means for Wisry Users
The runtime is invisible to users by design. What you see are the agents it runs:
- Wisry, the growth copilot, guides you through competitor ad research and into a live campaign — drawing on research, creative, and campaign-management sub-agents coordinated behind a single conversation.
- Ad-creative agents research winning ads in your market and generate image and video variants, each grounded in evidence. This is the engine behind the kind of AI-driven ecommerce creative that used to require a full production team.
- The video-editor copilot handles revision and refinement of video ad outputs — the iterative work that produces strong UGC-style creative without a shoot.
- Blogsmith, the writing agent that drafted this post inside our BlogStudio, is itself a runtime agent. It can research, write, and save drafts. It cannot publish — a human clicks that button. That constraint is structural, not a polite suggestion.
The same runtime powers agents across multiple products at Wisdomise beyond Wisry itself. It was built to be product-agnostic from the start, which is why adding a new agent to any product in the portfolio is a matter of writing a definition, not building new infrastructure.
The Philosophy in Plain Terms
Most teams bolt an LLM onto a feature. We built the machinery to run a fleet.
Agents should be as operable as any other production software: versioned so you can review changes, observable so you can diagnose problems, testable so improvements are measured rather than assumed, and safe by construction rather than by instruction. The Wisry agent runtime is our implementation of that principle — and every agent we ship is better for it.
If you would rather see the agents in action than read about their architecture, the best move is to start a campaign.
