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

Inside the Box Foxbox Digital Blog

Versapay: Digital Payments Mobile Strategy

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.

Agentic engineering in practice: How we used Claude Code to compress the build cycle for a production-ready, multi-feature Next.js site to just two weeks.

Compressing Build Cycles with Claude Code | Foxbox Digital 

When our client 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.

Leveraging Claude code, we shipped it with two engineers in just two weeks.

Our client is building a new kind of institutional operating system. Their thesis is that the fundamental problem facing modern organizations isn’t a lack of data or intelligence. It’s the absence of architecture that converts ambient organizational awareness into timely, coherent action.

It’s a dense, rigorous idea. The website had to not just do it justice, but make it clear and compelling.

Before getting into the process, here’s what we actually built on:

 of what needed to be wired together — CMS schemas, API routes, SEO configuration, dynamic routing, mobile responsiveness across distinct pages — is where complexity compounded fast.

Our Process: Tickets, Then Claude, Then Ship

Our process was ticket-driven. Linear issues tagged `WEB-XX` mapped to discrete page sections or features. A typical day looked like:

Product clarifies a section spec in the ticket

We pull up Claude Code alongside the codebase

We iterate: sometimes on a component, sometimes on a full page section

The back and forth on tickets was real. Sections got renamed mid-sprint. Copy changed. Section order shifted. CTA buttons appeared and disappeared. In a traditional sprint, each of these is a small tax — find the file, understand the context, make the change, check for side effects. With Claude Code, that tax drops dramatically.

The requirement was a branded page that renders the PDF inline on desktop, falls back to a download CTA on mobile, and matches the brand system exactly. That’s three distinct rendering paths, responsive logic, and brand polish — work that might take half a day to scope and execute. With Claude Code, I described the intent, it scaffolded the component, I reviewed and adjusted, and we were done in under an hour.

Fast Prototype Validation: The Real Unlock

The most underrated benefit of building with Claude Code wasn’t raw speed on any single task. It was the compression of the validation loop.

Traditional prototype validation goes something like: design → build → review → revise → build again. Each cycle has a handoff cost. With AI-assisted development, the cycle becomes: describe → build → review → describe revision → build again. The handoff cost nearly disappears.

This mattered most on the core page requiring a long-form product narrative and eleven distinct sections.

Each of these had to be both visually coherent and intellectually precise — the white paper’s argument is sophisticated enough that a sloppy visual translation would undermine the credibility of the whole product. Claude Code helped us move through sections rapidly while maintaining stylistic consistency: the dark background, the accent color system via CSS variables, the fluid typography using `clamp()`, the custom font trio of Inter, DM Sans, and IBM Plex Mono.

When something looked wrong in the browser, I described it. When the copy didn’t match the ticket, I pasted the correct copy. When a section needed restructuring, I explained the new hierarchy. Each correction took far less time than it would in a traditional loop.

What 76 Commits in Two Weeks Actually Means

Typed query layer (no more guessing at CMS response shapes)

Homepage: Hero with `LiveSignalPanel`, WhyNow, Architecture, UseCases, Testimonial, FinalCTA

Blog engine: listing page, detail pages with Portable Text rendering

Core narrative page (11 sections, WEB-41 through WEB-49)

Meeting scheduler with HubSpot API, availability checking, JWT-secured booking

Glossary, FAQ (CMS-driven with accordion), White Paper page

SEO: metadata, sitemap, robots.txt, JSON-LD Organization schema

Mobile responsiveness audit across every page

Navigation rename, redirects, final copy pass

Seventy-six commits. Clean, descriptive messages. PRs reviewed and merged. CI passing on every merge.

One area where Claude Code was particularly valuable was the Sanity CMS architecture. We built eleven schema definitions — landing page, core narrative page, blog page, FAQ page, glossary page, essays, block content, site settings — and a typed queries layer that makes every content fetch type-safe.

This isn’t glamorous work. It’s careful, repetitive, and easy to get wrong in ways that bite you later: a misnamed field in a schema that doesn’t match the query, that doesn’t match the component prop, that causes a runtime error in production. Claude Code helped maintain consistency across all of it — schema → query → type → component — without losing the thread between files.

Here’s a concrete snapshot of what two engineers shipped in two weeks:

Nine thousand lines isn’t a vanity metric — it’s context. That’s typed components, CMS schemas, API routes, SEO configuration, a booking system, a PDF viewer, a blog engine, and a glossary, all wired together with no cut corners. What makes that number meaningful isn’t its size, but the fact that every line was reviewed, committed, and CI-verified.

Honesty matters here. Claude Code isn’t a replacement for engineering judgment. A few things still required purely human work:

No AI looked at the browser and noticed that a section’s line height felt slightly too tight, or that the mobile nav needed a z-index fix. That’s still eyes-on-screen work.

When a product requirement arrived ambiguous — and they always do — someone had to resolve the ambiguity before Claude Code could execute on it. The AI is only as clear as the spec you give it.

Choosing to use the App Router’s server components for CMS freshness while keeping interactive sections as client components — that tradeoff required understanding Next.js’s rendering model, the data freshness requirements, and the performance implications. Claude Code can implement an architectural decision. It won’t make one for you.

Our client argues that institutions are struggling to focus cognitive resources on what matters, when it matters.

There’s a version of that same failure pattern in software development. Teams have the skills, the tools, and the spec. What they often lack is the bandwidth to move fast enough through routine implementation work to reach the hard decisions that actually require human judgment.

Claude Code shifts that balance. It handles the implementation surface efficiently enough that engineers can focus attention where it belongs: architecture, product decisions, quality judgment, and the parts of the work that are genuinely hard.

Two weeks. One production website. The signal was there. The tools finally let us act on it in time.

14 Days, 76 Commits, One Production Website: How to Compress Build Cycles with Claude Code

Agentic engineering made software cheaper to build. Learn why judgment now drives build vs. buy, and what to look for in a product development partner.

Build vs. Buy in the Age of Agentic Engineering | Foxbox

Every few years, someone declares custom software dead. SaaS was going to kill it. Then low-code, then no-code. Now it's AI.

The argument goes like this: if a capable team with AI agents can ship working software in days, why build anything yourself? Buy a platform, configure it, move on.

It's a fair question, but it's the wrong one. AI engineering doesn't settle the build vs. buy debate. It changes the inputs.

Custom software used to be expensive because implementation was expensive. Engineers were scarce, builds took months, and every feature carried delivery risk.

t, where AI agents write, test and refactor code under the direction of experienced engineers, now move at a pace that would have sounded like a sales pitch two years ago. At Foxbox, we recently took a product from concept to production in 14 days. Not a prototype. A production-ready product.

AI didn't build it alone. A senior engineer did, with AI handling much of the implementation. The real lesson is that turning a good decision into working software now costs far less, and that changes the build vs. buy math.

The traditional rule of thumb was simple: 

 when it's strategically differentiating.

That still holds. What's shifted is what "cheaper and faster" means. A custom workflow that once took six months of engineering might now take six weeks. So plenty of capabilities that were obvious buys a few years ago deserve a second look. Not because you should build everything, but because finding out what's worth owning costs far less.

"AI lets you build faster" is true, and by now it's useless for making decisions. The better question is what becomes scarce when building gets easy.

Cheaper software means you can test more ideas. More ideas means picking the right ones becomes the hard part. The bottleneck moves from implementation to decision making.

That's why some companies get real leverage from AI while others mostly get more code, more prototypes and more technical debt. The difference usually isn't tools or talent. It's product discernment: knowing what's worth building before anyone opens an editor.

"If building gets cheaper, won't we end up with a lot more software nobody needs?"

Yes. It's already happening. Our industry is great at generating features and 

. Plenty of software doesn't deserve to exist, and AI makes it easier to create more of it. So the real test is whether owning a capability gives you leverage. It usually does when it's:

A workflow core to how your business operates

A customer experience competitors can't easily copy

A process stuck waiting on a vendor's roadmap

A capability that helps you learn faster than your market

If none apply, buying is often still the right call. What AI changed is the threshold where custom development makes economic sense, and it's lower than most companies assume.

The most dangerous idea in AI engineering is that generating software and creating maintainable software are the same thing. They aren't. AI can pile up 

Software's true cost shows up after launch: architecture that survives change, tests you trust, observability when something breaks at 2 a.m., documentation a new engineer can follow six months later.

That's why "we built it in three days" is one of the least interesting things a team can say. The better question is whether you'll still be glad you own it in three years. (We dug into this on our stream.)

At Foxbox, sustainable velocity comes from three roles working together, the core of our approach to 

 frames the problem and decides what should be built.

 combines AI and engineering expertise to execute quickly.

 challenges assumptions, validates quality and protects maintainability.

Without orchestration, you get activity without direction. Without criticism, you get velocity without durability. Without either, AI just helps you make mistakes faster.

"Can we build this fast?" is no longer the right starting question. The answer is probably yes. Ask these instead:

Does owning this capability give us strategic leverage?

Will custom software help us learn faster than an off-the-shelf tool?

Are we constrained by someone else's roadmap?

Can we maintain this responsibly for years?

Do we have the discipline to decide what's worth building?

A confident yes to the first three and an honest yes to the last two make a real build case. Otherwise, buy, and feel good about it.

AI hasn't made software free. It's made implementation a commodity, and that makes judgment the differentiator. The companies that win won't build the most software. They'll get better at knowing which software is worth building.

From Sprint to Ship: How Agentic Engineering Changes the Math on Build vs. Buy

AI can generate features. It can't tell you which one your customer will build their day around. Rob Volk on why the aim still matters more than the tools.

Still Aiming for Indispensable

The short version: it had become so ingrained in my daily life that I couldn't imagine living without it. And that, I argued, is the rare distinction every digital product should aim for. Not "useful." Not "nice to have." Indispensable.

Two years later, the espresso machine is still running strong. The argument is too. But almost everything about how we build products has changed, and it's worth being honest about what that means.

In 2024, "AI-assisted development" mostly meant autocomplete with good manners. Today, agentic AI does real engineering work. 

 to plan tasks, write code, run tests, and iterate on their own output while our engineers direct, review, and make the judgment calls. Work that took a team a sprint can take a developer an afternoon. Prototypes that used to take weeks now happen before the second meeting.

This is not a marginal improvement. It's a different physics of product development. And here's the uncomfortable truth that comes with it: when building gets cheap, building the 

 gets cheap too. The market is now flooded with products that were technically easy to create and strategically pointless. You can vibe code something into existence, ship it, and hope for the best.

Some of it demos beautifully. Almost none of it survives contact with real users, real data, real security requirements, or real scale. Speed without direction just gets you lost faster. Which is why I think our argument from two years ago hasn't just held up. It's been magnified.

Understanding customers is still the whole game.

 AI can generate a hundred feature ideas in a minute. It cannot tell you which one your customer will build their morning routine around. That still requires sitting with real people, watching where they struggle, and digging past the surface. If anything, the discipline matters more now, because the temptation to skip it is stronger. When you can build anything instantly, 

deciding what deserves to exist becomes the scarcest skill in the room.

Testing every assumption matters more, not less.

 Back then I wrote that CI/CD, automated testing, and user validation were non-negotiable. In an agentic world, they're the difference between a product and a liability. AI-generated code needs the same rigor as human-written code, arguably more, because it's produced faster than any human can casually eyeball. The teams winning right now aren't the ones generating the most code. They're the ones with the strongest systems for validating it: automated test coverage, security review, human judgment at every checkpoint. Velocity without verification is just risk at scale.

Building for the long haul is now the dividing line.

 Two years ago, shortsighted products found their way to the recycling bin. Today they get there faster, because users have more alternatives and less patience. A vibe-coded app might launch in a weekend, but the first HIPAA audit, the first traffic spike, the first integration request will expose exactly how it was built. Architecture, security, maintainability, and scalability were never visible in a demo. They were always what separated products that last from products that trend. That gap is now a canyon.

Indispensable products are still growth engines.

 This part hasn't budged an inch. When a product becomes something customers can't live without, it becomes the beating heart of the business that built it. AI didn't change that equation. It just raised the stakes on both sides. The ceiling for well-built products is higher than ever, because small teams can now deliver what used to require large ones. And the floor for careless products is lower, because the market can see the difference immediately.

Here's how I'd put it now: agentic AI made building easy. It made building something 

Anyone can generate software. Fewer can generate trust, and trust is still earned the old way: through products that work every time, respect people's data, and fit so naturally into someone's life that their absence would be felt.

The tools changed. The economics changed. The aim didn't.

If you're trying to figure out what indispensable looks like for your customers in an AI-native world, and how to build it properly, 

Know when rapid AI-driven iteration becomes a liability. Learn how to improve codebase structure and shift to a product engineering mindset. 

AI Product Engineering | Foxbox Digital Blog 

There's a moment in every AI-assisted product build where the superpower starts to become a liability.


For a while, everything is momentum. You describe what you want, it gets built. You find a problem, you fix it. You add a feature in an afternoon that would have taken a week before. The velocity feels extraordinary — because it is.


And then something shifts. Changes start having unexpected side effects. The codebase develops a gravity that slows things down. A simple feature request turns into a three-day slog. A bug gets fixed and two others appear. The thing that made development fast — iterating quickly without worrying too much about structure — starts working against you.


This is the transition point from building to engineering. Most founders feel it before they can name it. This post is about how to recognise it, what it means, and what to do about it.

When you're building with AI tools — Cursor, Lovable, Replit, or any of the other current leaders in the space — the core workflow is iterative. You describe what you want, you evaluate what you get, you refine. The feedback loop is fast. The results are often surprisingly good.


This workflow is optimised for exploration. You're figuring out what the product should be by building it. The velocity comes from not having to know everything upfront — you can try things, see if they work, and change them if they don't.


What it's not optimised for is accumulation. Every time you add something, modify something, or fix something, you're making a deposit into a codebase that has to support everything you've put in it so far. When the codebase is small and simple, this is fine. As it grows, each change touches more of the system, and the probability of unintended consequences grows with it.


The point at which the cost of unintended consequences starts exceeding the benefit of rapid iteration is the point to switch modes.

Signal 1: You've stopped trusting deployments

In the early days, deploying was fine. You'd push a change, it would go out, the thing would work. Now there's a knot in your stomach when you deploy. You push something out and immediately monitor the error logs. You've been burned before.


This is the system telling you something about its own fragility. The code has accumulated enough state and enough complexity that changes are no longer isolated. They interact.


Signal 2: You're spending more time on bugs than features

Track your last two weeks of work. If more than half of your time is going to fixing things that broke — rather than building things that didn't exist — the codebase has crossed a threshold. You're maintaining it rather than building on it.


This ratio tends to get worse over time if the underlying structure isn't addressed. It doesn't naturally correct itself.

Signal 3: The codebase has knowledge that only exists in the code

This is a subtler one. Ask yourself: if a competent engineer who had never seen this project opened the repository today, how long would it take them to understand how it works?


If the answer is "they'd basically have to reverse-engineer it" — there's no documentation, the code is difficult to follow, the architectural decisions aren't visible anywhere — you've built something that is brittle in a human sense as well as a technical one. It depends on the people who built it to maintain it, rather than on its own coherence.

Signal 4: You're about to put real load on it

You have a launch planned. A press feature is coming out. You're closing a partnership that will bring in a wave of new users. You're about to deliberately grow.


This is a prospective signal rather than a reactive one — you're not yet broken, but you're about to be exposed. This is the best time to make the transition, because you can do it deliberately rather than in response to a crisis.

Signal 5: Money is moving through the system

If your product has real financial transactions — payments, subscriptions, contracts, invoicing — the standards are different. Bugs in a feature are annoying. Bugs in billing are existential. Inconsistent state in a user's profile is recoverable. Inconsistent state in a payment record might not be.


The moment real money is involved is the moment to demand engineering discipline, regardless of whether you've hit the other signals.

What "Starting to Engineer" Actually Means

This is the part that founders sometimes misunderstand. The transition from iterating to engineering isn't:


Stopping product development to do a rewrite

Hiring a team of people who will spend six months on infrastructure before shipping anything

Adopting a slow, bureaucratic development process

Establishing a foundation you can build on.

 This means addressing the structural issues — the missing indexes, the absent error handling, the synchronous operations that should be async, the secrets in the codebase — so that future development is faster and more confident, not slower.

 Good documentation, clear architectural decisions, code that can be understood by someone who wasn't there when it was written. This isn't a luxury — it's what enables you to move fast at scale, because changes don't require the full context of everyone who's worked on the system.


 Not necessarily 100% coverage of everything — that's often a waste of effort at this stage. But tests around the things that matter: the critical paths, the financial logic, the edge cases that have burned you before. Tests that give you confidence to deploy.

 Your deployment process, your monitoring, your alerting, your on-call runbooks — these aren't supporting characters. When production breaks, they're the whole show. Getting them right isn't a distraction from building the product; it's what allows you to build the product sustainably.

There are two ways to get this wrong, and they're mirror images of each other.


The first is staying in iteration mode too long. You keep shipping, the codebase accumulates fragility, you hit a scaling moment unprepared, and you end up doing emergency remediation under pressure. This is more common. It tends to happen because iteration feels productive and engineering feels like it's not building anything.


The second is switching to engineering mode too early. You have a small product, a handful of users, and you start talking about microservices, Kubernetes, and multi-region deployment. This is how startups burn six months on infrastructure for a product that isn't validated yet. The irony is that the people making this mistake often do it in the name of "doing it properly."


The discipline is in timing. You want to switch modes at the point where the system's current structure will actively slow you down — not before, not after.


That point is different for every product, every team, every stage. But it's almost never at the beginning, and it's almost always before the crisis.

If you've recognised the signals above and want to make the transition intentionally, here's what it looks like in practice:

 Understand what you have before deciding what to do about it. What are the structural problems? Where are the risks? What will break first, and under what conditions? This doesn't have to be exhaustive — you're looking for the high-impact issues, not a comprehensive audit of everything.

 Not everything needs to be fixed at once. Security issues (exposed secrets, missing auth checks) are first. Infrastructure reliability (error tracking, monitoring) is next. Performance and scalability come after that. Structural improvements (test coverage, code organisation) can be layered in over time.

 The transition shouldn't require a freeze on feature development. The best approach is usually a parallel track: some capacity dedicated to structural improvement, some dedicated to product development. The proportion shifts as the structural issues are resolved.

 If the people who built the MVP aren't engineers — or if they are, but they're needed on product — there's real value in bringing in a team who does this work specifically. Not to take over the codebase, but to set it up so that your team can maintain it confidently.

There's a version of this story where founders ignore the signals until they can't anymore. The product gets big enough that real users depend on it. The team grows. Revenue is meaningful. And then something breaks in a way that takes days to fix, or a new engineer joins and can't get the development environment working, or technical due diligence for a Series A reveals a codebase that makes investors nervous.


At that point, the options narrow. You're either doing remediation under pressure, or you're doing it under the scrutiny of investors and new team members. Neither is ideal.


The transition is much easier when you choose to make it. The codebase doesn't have to be a liability. It's fixable. But it takes intention — and the earlier you bring that intention to it, the less it costs.

When to Stop Iterating and Start Engineering

A practical breakdown of the multi-agent AI engineering model Foxbox uses in production: how orchestrators, parallel subagents, and critic agents work together to build and verify software at scale.

The Three-Agent Model: How we Accelerate Agentic Engineering

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. The terminology around this pattern is still settling; you'll see it called orchestrator-subagent, agentic loop, or simply multi-agent workflow depending on who's writing about it and when. The underlying structure is consistent regardless of what it's called, and that structure is what's worth understanding.

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 didn't originate with any single company or tool. It emerged from multi-agent systems research and has been formalized over the past couple of years by engineering teams at Anthropic, Google, Microsoft, and OpenAI as 

 became capable enough to make it practical.

The core idea is older than any of those companies: in any well-designed system, generation and verification should be separate concerns. You don't have the same person write the code and sign off on its correctness. You don't have the same process that builds the artifact also audit it. This separation of concerns is foundational to software engineering. It's why code review exists, why QA is a distinct function, why tests are written independently of the code they test.

The three-agent model applies that principle to AI agents. Instead of one agent trying to do everything — plan, implement, check, refine — you give each role to a specialized agent with its own context, instructions, and scope.

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 pattern. The names differ: orchestrator-subagent-evaluator, generator-critic loop, maker-checker. The structure holds.

The orchestrator is the agent at the top of the hierarchy. It receives the task — a feature, a bug fix, a module to build — and handles the planning work: decomposing the problem, deciding what needs to happen in what order, assigning work to subagents, and synthesizing results.

The orchestrator does not write code directly. Its job is coordination and judgment. It maps the work, specifies what each subagent should produce, and determines when output meets the standard to move forward.

This mirrors how a senior engineer actually operates. When a complex feature lands in a sprint, a senior engineer doesn't immediately start coding. They break it down. They think about dependencies. They decide what the interface should look like before anyone touches an implementation. That planning work is what the orchestrator does.

The builders are the hands. The generators. Each one receives a bounded, well-defined task from the orchestrator and executes it in its own isolated context window.

The isolation matters. One subagent working on the data access layer doesn't need to know about the UI. Another subagent writing the API schema doesn't need to know about the deployment configuration. Narrower context produces more focused output — the agent isn't holding irrelevant information while trying to do a specific job.

Subagents can run in parallel. If the orchestrator determines that the database schema, the API endpoints, and the authentication middleware are independent of each other, it can assign all three to separate builder subagents working simultaneously. This is where significant time savings come from in practice: tasks that would be sequential in a traditional development workflow can run concurrently.

The critic is the quality gate. After a builder produces output, the critic reviews it against a defined set of criteria before the result goes back to the orchestrator.

The critic's job is not to rewrite the output. It's to evaluate it: Does this do what was asked? Does it meet the acceptance criteria? Are there edge cases missing? Is there a security issue? Does it conflict with anything in the broader codebase?

If the output passes, the critic signs off and the orchestrator proceeds. If it fails, specific feedback goes back to the subagent for revision. This loop continues until the output meets the standard, or until a maximum iteration count triggers escalation to a human reviewer.

What this creates is a quality gate that catches problems before they compound. A builder writing a database query that would cause an N+1 problem gets corrected before that query is wired into the API layer. A subagent generating an API endpoint that exposes a sensitive field without proper access controls gets flagged before it ships.

The practical reason is context management. A single AI agent working on a large feature has to hold the entire task in a single context window. As that window fills, quality degrades — the model loses track of earlier constraints, makes decisions that contradict earlier ones, and produces output that works in isolation but conflicts with the rest of the system.

Distributing work across multiple agents, each with a focused context, prevents this. The orchestrator's context stays lean because it only manages plans and summaries, not implementation details. Each builder’ context is scoped to its specific task. The critic's context is structured around evaluation criteria, not generation.

There's also a quality argument independent of context. Generation and evaluation are different modes of work. An agent that wrote the code has already committed to a set of assumptions. A separate agent reviewing that code — with different instructions and no prior context — will catch things the generator missed. This is why pair programming works. It's why code review finds bugs the original author didn't. Separating the roles builds that dynamic into the process.

We don't apply this pattern mechanically to every task. A simple bug fix doesn't need an orchestrator. A single-endpoint change doesn't need parallel builders. The pattern earns its overhead when the work is complex enough that a single agent would hit its limits.

When a feature touches the database, the API, and the frontend — or requires integration with a third-party system alongside product logic — the orchestrator decomposes this into separate workstreams that can be specified and verified independently.

Refactoring a data model, migrating an API version, updating an authentication system — these are changes that affect many files and many layers. Parallel subagents, each responsible for a specific domain, move through these changes faster and with less risk of cross-contamination.

Any work where correctness is non-negotiable gets a critic configured with explicit acceptance criteria, not just a general quality review. In regulated industries — healthcare, fintech, anything with real compliance exposure — the critic's checklist includes the specific requirements that can't be compromised.

A Representative Example: Building a Care Coordination Feature

The following is a composite based on the kinds of engagements we run for 

 The specifics are illustrative, but the pattern and the catches are real.

The scenario: a care coordination platform managing care plans for patients across multiple providers. The feature: a notification system that alerts care team members when a patient's status changes, routed correctly based on the member's role, their relationship to the patient, and the type of status change.

This is a non-trivial feature. It has a rules engine (who gets notified, under what conditions), a delivery layer (push, SMS, in-app), a preference system (notification settings per user), a data model change (new notification event types with audit logging), and it touches HIPAA-covered data throughout.

Here's how the orchestrator decomposed it:

Define the event schema for status change notifications and the audit log format

Build the rules engine mapping patient status changes to notification recipients

Build the delivery service (separate subagent per channel: push, SMS, in-app)

Wire the components together and validate the end-to-end flow

Inside the Box

Articles, updates, and ideas you can put to use.