Mikel Studio · Issue #7
Signals: Design the AI Operating Surface
Two practical patterns for making AI deployments more efficient, inspectable, and easier to change safely.
AI systems are becoming less like standalone models and more like operating surfaces: they decide where work runs, what evidence is collected, and when a result is trustworthy enough to move forward. This edition looks at two design choices with immediate practical value: route routine work to the right execution environment, and build independent assurance into the system rather than adding it at the end.
The Signal
Make assurance part of the deployment path
Anthropic’s partnership with Accenture and Faculty points to a shift in enterprise AI governance. The organisations plan to implement embedded independent evaluation, with both parties expecting to invest at least $1 billion over five years.
The important detail is the operating model: evaluation moves closer to the deployed system instead of remaining a final review owned entirely by the team that built it. That matters because AI systems change in production. Models are updated, prompts evolve, tools and data are connected, and user behaviour shifts.
For teams deploying consequential AI, the practical question is not simply whether the model passed its original test suite. It is whether someone with enough distance from delivery can challenge the system as it operates in context.
Start by defining five parts of an assurance path:
- A challenger: an independent team, reviewer, or organisational function responsible for testing important systems.
- Release gates: evidence required before launch, expansion, model changes, or material changes to tools and data access.
- Contextual tests: evaluation of the model, prompts, retrieval, tools, permissions, workflow, and user experience together.
- An evidence trail: the system version, evaluation scope, findings, mitigations, owners, and deployment decision.
- Change triggers: renewed assessment after model updates, new integrations, incidents, or significant usage shifts.
This creates a useful separation of responsibilities. Builders remain accountable for making the system work; assurance makes it possible to question whether it continues to work safely enough for its context. For founders, the opportunity is to build products that make testing, monitoring, challenge, and documentation part of the normal control plane—not an administrative layer added after deployment.
What We Learned
Route agent work by consequence, not habit
A tiered sculptural arrangement featuring an oak block, a textured glass brick, and a polished chrome sphere against a neutral background.
Perplexity has brought its Portable Computer runtime to supported Windows machines powered by AMD Ryzen AI Max processors, allowing local AI tasks and recurring background workflows to run on the device without consuming Perplexity Computer inference credits.
The broader design lesson is useful beyond this specific product: agent systems do not need to be entirely local or entirely cloud-based. A hybrid architecture can assign work according to frequency, sensitivity, latency, and reasoning difficulty.
A practical routing pattern looks like this:
- Keep routine loops local. Use on-device execution for recurring automations, internal data triage, and basic summarisation when the task does not require frontier capability.
- Escalate difficult work. Route complex reasoning, large multimodal synthesis, and high-stakes decision trees to hosted models when their performance justifies the added latency and cost.
- Use local preparation before cloud escalation. Let the device structure or filter inputs, then send only the necessary context upstream when local capabilities reach an established confidence threshold.
- Define deterministic fallbacks. Decide what happens when local execution fails, confidence is low, connectivity disappears, or the cloud route is unavailable.
This turns “local AI” from an edge-case optimisation into an architecture decision. Before choosing a model or provider, classify the workload: how often does it run, what data does it touch, how reversible is its output, and how much reasoning does it need? The result may be a smaller, cheaper, and more resilient system than sending every loop to a central model by default.