Foxbox Digital is an award-winning engineering-focused product development agency.

Inside the Box Foxbox Digital Blog

Versapay: Digital Payments Mobile Strategy

The Three-Agent Model

The Three Roles

Why Three Roles and Not One

How We Apply It at Foxbox

A Real Example: Building a Care Coordination Feature

What This Means for How We Staff Engagements

The Honest Caveats

The Short Version

There's a version of AI-assisted development that most people picture: a developer typing a prompt, reading the output, and deciding whether to keep it. One human, one model, back and forth. It's better than writing everything from scratch. It's not how we work.


At Foxbox we use what's become known in the engineering community as the three-agent model. It's a multi-agent architecture pattern — a way of structuring AI agents in a hierarchy so that complex software work can be decomposed, executed in parallel, and verified before it ships. Understanding it properly requires stepping back from individual AI tools and thinking about how a system of agents can work together.


This post explains the model, where it comes from, how we apply it in practice, and what it looks like on a real engagement. 

Microsoft's Azure Architecture Center, Google's Agent Development Kit documentation, and Anthropic's guidance on multi-agent workflows all describe variations of the same core pattern. It goes by different names: orchestrator-subagent-evaluator, generator-critic loop, maker-checker. The underlying structure is consistent.


How orchestrators, subagents, and critics work together in production AI development workflows — and how Foxbox applies the pattern on real client builds.

The Three Agent Model for AI-Native Development | Foxbox Digital

At Foxbox we use what's become known in the engineering community as the three-agent model. It's a multi-agent architecture pattern — a way of structuring AI agents in a hierarchy so that complex software work can be decomposed, executed in parallel, and verified before it ships. Understanding it properly requires stepping back from individual AI tools and thinking about how a system of agents can work together.

This post explains the model, where it comes from, how we apply it in practice, and what it looks like on a real engagement.

The Three Agent Model: How We Approach AI-Native Development

The Challenge

Building Attention Infrastructure 

The Tech Stack

Putting the Pieces Together

When Signal Labs came to us with a deadline and a vision, the scope was ambitious by any measure. A full marketing site for an AI company — one with deeply technical content, a headless CMS, meeting scheduling tied to HubSpot, animated data visualizations, a white paper viewer, a blog engine, a glossary, an FAQ, and a page that reads more like a long-form manifesto than a landing page. Two engineers. Two weeks.


We shipped it. Here’s what it actually looked like.

14 Days, 76 Commits, One Production Website: What Happens When You Build With Claude Code

The Inflection Point

What "Breaking at 1,000 Users" Actually Means

Why Things Break Down

The Four Most Common Failure Modes

The Common Thread

You built something real. In weeks, maybe days, you went from idea to working product. Users are signing up. Revenue is starting to move. You've done the hard part — you've proven the thing works.

And then someone asks: "What happens when this gets big?"

Here's the honest answer: if your codebase was built primarily through AI-assisted iteration — Cursor, Copilot, Replit, Lovable, or any of the other tools in that ecosystem — there's a near-certain set of things that will break as you scale. Not because those tools are bad. They're extraordinary. But they're optimised for speed of creation, not resilience under load.

Built fast with AI tools? Here’s what breaks at 1,000 users—and how to fix scaling issues in databases, APIs, and infrastructure before they cost you.

Why Your Cursor-Built MVP Will Break at 1,000 Users (And How to Fix It Before It Does)

First, let's be specific about what failure looks like, because it's rarely a dramatic crash. It's usually:

Response times that were 200ms at 10 concurrent users becoming 8 seconds at 200

A database query that worked fine on 5,000 rows grinding to a halt on 500,000

A background job that ran fine once a minute now running 800 instances simultaneously and exhausting your server's memory

An authentication flow that was secure enough for beta testers becoming a liability when someone motivated decides to probe it

A third-party API integration that worked fine until you hit the rate limit you didn't know existed

None of these are corner cases. They're the predictable, structural consequences of code that was written to demonstrate functionality, not sustain it.

AI-generated database code is usually syntactically correct and logically sound. It does what you asked it to do. What it almost never does is consider query performance at volume.

The pattern looks like this: a query that works perfectly when your users table has 200 rows becomes catastrophically slow when it has 200,000. Not because the query is wrong — it returns the right results — but because there's no index on the column being filtered, or the query is doing a full table scan, or it's making N+1 queries in a loop (fetching a list of records, then making a separate database call for each one).

The N+1 problem deserves special mention because it's invisible in development. You load 10 posts and make 10 separate queries to fetch each post's author. That's 11 queries total, which takes maybe 50ms. At scale, you load 500 posts, make 500 author queries, and your page takes 4 seconds to render, if it renders at all.

 Add indexes on every column you filter or sort by. Audit every query for N+1 patterns and replace them with joins or eager loading. Run 

 (in Postgres) or its equivalent on any query that touches large tables. Do this before you need to.

When you build with AI assistance, you write the happy path. The code does what you want it to do when users behave the way you expect them to. What it rarely accounts for is what happens when users (or automated processes pretending to be users) don't.

A single user can send 10,000 requests in a minute and exhaust your server

Someone can brute-force your login endpoint

A webhook can fire repeatedly and create thousands of duplicate records

A misconfigured client can poll your API every second and bring your infrastructure to its knees

This isn't a paranoid security scenario. It's just what happens when something gets popular enough to attract bad actors, or when a client-side bug causes a retry loop.

 Add rate limiting at the API gateway or middleware level. Implement exponential backoff for retries. Add idempotency keys to any endpoint that creates records. This is a few hours of work that prevents days of incident response.

3. Synchronous Operations That Should Be Asynchronous

AI-assisted code has a strong tendency toward the synchronous. When you describe what you want — "when a user signs up, send them a welcome email, add them to the CRM, and provision their account" — the most natural code to generate does all three of those things in sequence, in the same request/response cycle.

This works fine at low volume. At high volume, it breaks in two ways:

First, it makes your response time dependent on the slowest of those operations. If the CRM API takes 3 seconds to respond (which third-party APIs occasionally do), every signup takes 3 seconds. Users abandon forms. Conversion drops.

Second, it makes your entire signup flow fragile. If the CRM API is down, signups fail. Not because anything is wrong with your product — because a third-party dependency is unavailable.

 Move side effects out of the request cycle and into a job queue. Send the welcome email asynchronously. Sync to the CRM in a background worker. If those jobs fail, retry them. Your request handler should do the minimum necessary to return a response — write to the database, return success — and everything else should happen out of band.

This one doesn't cause a failure mode — it makes every failure mode invisible until it's too late.

AI-assisted codebases almost never include proper logging, error tracking, or performance monitoring. There's no Sentry catching uncaught exceptions. There's no structured logging that would let you trace a user's journey through your system. There's no alerting that would wake someone up at 2am when the error rate spikes.

When something breaks at 1,000 users, you find out when a user tweets about it or when revenue drops, not when the problem starts.

 Add application error tracking (Sentry is the default choice for a reason). Add structured logging with request IDs so you can trace what happened. Set up basic uptime monitoring. None of this takes long — a few hours, not a few weeks — but it needs to happen before you need it.

There's a common thread running through every failure mode above: they're all invisible at small scale.

That's not a bug in AI-assisted development. It's an inherent property of how the tools work. You describe what you want the software to do. The model writes code that does that thing. It can't optimise for conditions it hasn't been asked to consider.

This is also why the failure often feels sudden and mysterious. The codebase worked fine for months. Then, seemingly overnight, it doesn't. What actually happened is that the code always had a structural ceiling — you just hadn't hit it yet.

If you're reading this and your MVP is in production with real users, here's a triage priority order:

Add error tracking (Sentry free tier takes 20 minutes to set up)

Check whether your most-used database queries have appropriate indexes

Add rate limiting to any public-facing API endpoints

Identify any synchronous operations that should be queued

Make sure you have a connection pool configured for your database (not just a single connection per request)

Load test your application at 10x your current peak load

Review your infrastructure for single points of failure

Make sure you have database backups that you've actually tested restoring from

None of what I've described above requires starting over. We do this work all the time — we take codebases built with AI tools and make them production-grade. That process is usually faster than people expect, because the core product logic is often sound. What's missing is the layer of engineering discipline around it.

The goal isn't to replace what you've built. It's to make it survivable.

If you're approaching a growth moment — a launch, a press hit, a sales push — and you're not confident your infrastructure can handle it, the time to find out is now, not when your signup page is down.

Over the past year, I’ve had lots of conversations with CTOs and product leaders about AI readiness. Almost every organization can point to something. A pilot. A chatbot. An internal coding assistant. A proof of concept built on top of a foundation model.


AI readiness often asks how we can use AI. Whether we have access to models. Whether we’re able to conduct experiments, learn new tools and integrate some type of AI functionality into an existing product experience.
AI-native readiness asks something more fundamental. Are our systems, teams, data models, and governance frameworks designed for continuous model-driven evolution? That distinction matters.


Bolting AI onto an existing product can generate short-term gains. But if your architecture tightly couples logic to a single provider, if your data pipelines are not instrumented for feedback, if your evaluation loops are informal, and if security controls were designed for deterministic systems, you will plateau quickly.


AI-native organizations design for adaptation. They assume models will improve monthly. They assume workflows will shift. They assume evaluation and governance are ongoing responsibilities, not launch-phase checklists.
As technical leaders, this is not about chasing hype. It is about making durable architectural and organizational decisions. AI-native readiness is a better measure because it reflects whether your organization can compound value from AI over time, not just demonstrate it once.
We break it down across six dimensions:

Most AI strategies stop at pilots and features. Learn how AI-native readiness helps CTOs design systems, teams, and architecture built for continuous AI-driven evolution.

AI Native Readiness: Beyond Bolted-on AI Solutions

AI-native organizations design for adaptation. They assume models will improve monthly. They assume workflows will shift. They assume evaluation and governance are ongoing responsibilities, not launch-phase checklists.
As technical leaders, this is not about chasing hype. It is about making durable architectural and organizational decisions. AI-native readiness is a better measure because it reflects whether your organization can compound value from AI over time, not just demonstrate it once.
We break it down across six dimensions:


1. Product Architecture Designed for Model Evolution


AI-native products assume models will change. Models improve. APIs evolve. Pricing shifts. Providers consolidate. Your architecture should reflect that reality. AI-native systems abstract model layers. They separate orchestration from inference. They support component swapping. They log structured interactions for retraining and evaluation.
In practice, this means:
Clear boundaries between business logic and model interfaces

Observability at the prompt, response, and decision layer

Versioned prompt and evaluation frameworks

The ability to test multiple models against the same workflow

If replacing a model requires refactoring large portions of your system, you are not operating in an AI-native posture.


2. Data as a Strategic Asset, Not an Afterthought

AI-native readiness goes beyond asking whether data exists. It asks whether data is usable, governed, and connected to feedback loops.
You need:
Structured and unstructured data pipelines

Mechanisms to capture user interactions for improvement

Instrumentation that ties model outputs to business outcomes

For example, in a clinical triage workflow, it is not enough to generate recommendations. You must track recommendation accuracy, escalation rates, and user overrides. That feedback must flow back into evaluation. AI-native organizations treat data flows as part of the product surface, not background infrastructure.

AI-native readiness also changes how software is built. Engineering teams should be using AI in development, testing, and QA in a systematic way.
This includes:
AI-assisted code generation and refactoring

Automated test generation and regression validation

LLM-on-LLM review for critical logic paths

Prompt libraries treated like versioned source code

This is not simply about velocity. It is about building teams that assume intelligent tooling is embedded in the workflow. If your engineering process looks unchanged from several years ago, you are likely under-leveraging what AI-native development enables.


4. Operational Maturity and Continuous Evaluation

AI systems are probabilistic. They drift. Edge cases accumulate. Performance changes over time. AI-native readiness requires operational discipline.
You need:
Formal evaluation frameworks

Benchmark datasets aligned to real use cases

Continuous monitoring of latency, cost, and output quality

In practice, this can mean shadow testing new models before promotion to production. It can mean regression suites that evaluate AI outputs against curated scenarios. It can mean cost observability tied directly to specific workflows.
Without this layer, pilots rarely mature into reliable systems.


5. Organizational Capability and Cross-Functional Alignment

AI-native readiness is not just technical.
Product, engineering, data, compliance, and security must align on:
Acceptable risk thresholds

You need leaders comfortable designing probabilistic systems. You need engineers who understand distributed architectures and model behavior. You need product teams who can define success metrics for non-deterministic outputs.
Without cross-functional clarity, AI remains isolated.

6. Data Security and Model Governance by Design

AI introduces new attack surfaces.
Prompt injection. Data leakage. Model inversion. Third-party API risk.
AI-native readiness requires:
Strict data segmentation

Vendor risk assessments specific to AI providers

Encryption and access controls at every inference boundary

In regulated industries, this is foundational. If you cannot clearly trace how data moves through your AI workflows, you should not scale them.
Security cannot be retrofitted onto AI systems built without governance in mind.


AI-native readiness is not about having the latest tools. It is about whether your organization is positioned to continuously build, evaluate, and evolve intelligent systems.


As CTOs, we are responsible for durable systems. Systems that adapt without becoming fragile. Systems that compound value rather than degrade.
AI-native readiness is a structural lens. It forces us to examine architecture, data, workflows, operations, organizational alignment, and security as an integrated system.


That is a more meaningful measure than whether we have launched an AI feature.
And in the current environment, it is the measure that will separate experimentation from sustained advantage.

Discover how K Health partnered with Foxbox to scale its AI healthcare platform across systems using Kotlin Multiplatform—powering personalized, cross-platform care at scale.

K Health: AI-Driven Healthcare Case Study | Foxbox Digital

When K Health was founded in 2016, the company set out to transform primary care. In 2024, they underwent a transformation of their own. One that required a highly capable engineering partner to bring to fruition.

empirical evidence that K Health’s AI Physician Mode outperforms human doctors

, the company set out to evolve the platform from a single-instance patient app into a white-label virtual care platform that allows hospitals and health systems to deliver personalized, AI-powered care at scale.

 With insufficient internal bandwidth to simultaneously build toward the future and maintain existing functionality, K Health needed a trusted partner to extend their engineering capabilities immediately

“We needed a team tomorrow or we weren’t going to get it done in time.

K Health turned to Foxbox for the support necessary to rebuild the apps from scratch, natively in iOS and Android, optimizing for cross platform functionality and adaptability via Kotlin Multiplatform. With a focus on AI functionality, automated testing and scalability, our team hit the ground running as extensions of the K Health team.

At the heart of the K Health experience is an AI-powered engine for symptom checking, triage, and scheduling—used by both patients and providers. Delivering that experience at scale required solving a deceptively complex problem: making advanced infrastructure feel completely invisible. 

K Health supports live video visits powered by multiple video providers, each with their own distinct technical constraints. Our challenge was to abstract those differences entirely, so patients never had to think about what technology was powering their visit.

To achieve this, we engineered a unified video layer that handled audio, video, device selection, and real-time state changes consistently across platforms, despite fundamentally different event models under the hood. In healthcare, even small inconsistencies, like a muted microphone UI that doesn’t reflect actual audio behavior, can introduce serious risk, requiring rigorous testing and careful synchronization.

In parallel, we designed the system to support multilingual and accessible care without increasing product complexity. Language localization is resolved server-side, allowing the app to dynamically render content in a patient’s preferred language without hardcoded translations or client updates. The result is a flexible, future-ready foundation that scales across partners, languages, and accessibility needs, all without ever compromising the patient’s experience.

 allowed us to build native iOS and Android apps with a shared, secure business logic. This shift dramatically improved scalability by reducing duplicate effort across platforms.

With Kotlin Multiplatform, we delivered fully native UI layers without compromising performance, resulting in lightning-fast interactions, smooth animations, and rock-solid functionality.We engineered for the future: optimizing for low-bandwidth environments, supporting multiple languages, and building a custom QA automation framework to validate daily releases and minimize regression risk. 

We engineered for the future: optimizing for low-bandwidth environments, supporting multiple languages, and building a custom 

 framework to validate daily releases and minimize regression risk. Every decision was made to enhance performance and long-term resilience.

We validated every day… it really helps enhance the testing experience.”

Our approach goes beyond writing code. From day one, we operated with full product ownership—proactively flagging issues, suggesting solutions, and adapting to shifting specs and timelines. We worked side-by-side with K Health’s internal engineers, designers, and product leads, navigating complexity with confidence and clarity.


This close collaboration enabled K Health to roll out new branded apps for major US-based health systems to provide AI-powered virtual care solutions, all while maintaining a single codebase and unified release pipeline. Because the architecture is built for flexibility, new deployments don’t require rework. Localization, customization, and expansion are possible on the fly. If a clinic wanted to launch in French tomorrow, they can do so without changing the code.

“They see something, they say something. They write it up, explore it, and suggest solutions.”

Today the K Health platform is powering virtual care programs at health systems that serve over 

 patients. All without sacrificing development efficiency, code quality or the ability to adapt. 

Together, our partnership doesn’t just extend capacity. It empowers K Health to move faster, think bigger, and scale smarter. And we’re proud to be along for the ride.


“The learning curve was steep, but now we can confidently build anything with Kotlin Multiplatform.” 

 to learn more about how we're helping providers and payers build world-class digital health products.

K Health: Powering AI-Driven Healthcare with a Personalized Cross-Platform Experience

Learn how to use Claude Code to automate end-to-end test creation. Build, review, and run automated tests with Claude Code, reducing setup time, enforcing project rules, and improving test coverage with human oversight.

Automated QA Testing in Claude Code | Foxbox Digital

AI coding assistants are no longer just for brainstorming or writing boilerplate code. They’re becoming powerful tools in test automation. In this piece we’ll walk through a real QA workflow using Claude to speed up repetitive test creation, highlight the human/AI handoff points, and share lessons learned along the way.

After an initial healthy skepticism, I’m now a firm believer that AI tools can dramatically improve QA workflows. Automated testing powered by tools like Claude can reduce hours of manual setup into minutes. But it’s not “end-to-end automation.” Human expertise is still critical in order to:

Architect processes before they can be automated.

Identify the right balance between reusability and project-specific rules.

Review and refine AI-generated code for quality, security, and maintainability.

Using tools like Claude Code, the QA engineer’s role shifts from operating a repetitive system to designing a new one entirely. The payoff is dramatic — a process that once took 1–2 hours manually can now be completed in 20–30 minutes with the right approach.

Let’s walk through one test case for a telehealth application with an AI symptom checker. To confirm patients are able to get the answers they need, we need to confirm they can upload a photo during an appointment set up flow.

Manually, the process would usually look something like:

Validate the app doesn’t crash and the upload succeeds.

Running this flow manually is repetitive and time-consuming.

Instead of hand-coding every selector and step, Claude can act as your automation assistant at every step of the way. Not too early in the process, not tacked on to the end. The craft is now finding balance. Here’s how I approached it

Using a recorder tool, the QA clicks through the scenario. Each action (tap, input, upload) is captured into a Java file.

Comments mark each step (e.g., // Login, // Select symptom, // Upload photo). Claude uses these annotations to understand context.

Naming conventions (PascalCase, file structures).

When to reuse existing methods (e.g., login flows).

Claude ingests the recordings + rules, and generates test files:

Page object files (for selectors and UI elements).

The engineer reviews the generated files, validates selectors, and fixes any missteps. Common pitfalls:

Misclassified selectors (e.g., ID vs XPath).

Fragile selectors that change with app updates. Security risks (Claude sometimes proposes hard-coded values).

With experience, teams learn to anticipate these errors and adjust rules accordingly.

On this particular project, this process has reduced setup time by ~70%, improved reusability, and has helped us deliver a better product in less time. Still, success requires careful upfront architecture and thorough human oversight, since selectors often trip up the AI and rules must be rebuilt for each new project. It moves at a speed no human could, but also makes mistakes that humans never would.

Understanding how to navigate both realities is what will redefine the “Quality” in QA.

: Begin with simple, repetitive flows like logins, file uploads, or form submissions—these are perfect for automation because they’re high-frequency and low-risk. Starting here helps you validate the process, refine your rules, and build confidence in Claude before tackling more complex scenarios.

Your CLAUDE.md (or equivalent rules file) acts as the brain of the system, guiding Claude on naming conventions, file structures, and method reuse. The clearer and more prescriptive this file is, the less cleanup you’ll face later, making it one of the highest-leverage investments in your QA automation setup.

Claude moves fast, but it’s not flawless—misclassified selectors, fragile locators, or incorrect assumptions will creep in. By budgeting time for debugging, you turn these missteps into learning moments that strengthen both your test suite and your rules over time.

Never merge AI-generated code blindly; human validation is critical. Security is a particular concern—watch closely for leaked credentials, hard-coded values, or unsafe shortcuts that might slip through without careful review.

As you run more scenarios, your rule set will grow into a library of reusable steps, making Claude more accurate and reducing duplication. Over time, this library becomes a strategic asset—accelerating test creation and improving consistency across your QA practice.