Don’t “add architecture” when you can’t prove you need it

Monday outage: the agent worked, but the business broke

Last year, on a Fortune 500 apparel brand’s internal ops workflow (think: returns triage + entitlement checks + warehouse notes), we shipped an “agentic” assistant to help staff draft the next action. The model could read a customer record, suggest an outcome, and generate the work note. Everyone was thrilled—until two days after go-live.

The agent didn’t fail in the obvious way. It generated sensible notes. The failure was subtler: it made optimistic state changes. The workflow looked like “draft → approve → apply,” but the approvals were happening faster than our internal system could reconcile. Under load, the same order hit two parallel flows (same customer, same ticket, different browser tabs). The agent would draft consistent text, then the backend would partially apply updates, then the agent would re-read and “correct” the note—writing a second conflicting update.

We measured it the next morning. Error rate wasn’t the model’s token accuracy problem. It was a business integrity problem: 2.6% of workflows ended with inconsistent warehouse flags. Support volume spiked, and the “agent” became the scapegoat when the root cause was concurrency and state transitions.

We rolled it back, then rebuilt the system around an explicit state machine and idempotency keys. The agent stayed—but only as a text generator behind deterministic, serialized transitions.

That moment is why I’m taking a hard line today: if you can’t justify agents, microservices, multisite, or “just ship headless,” you should not add them. Not because they’re bad—because most teams can’t afford the operational complexity before proving the need.

When NOT to use agents

Agents are tempting because they promise autonomy. But you should avoid agents when the primary risk is not hallucination—it’s side effects.

Don’t use agents when side effects are irreversible

If the agent can trigger refunds, entitlement changes, order edits, or anything that creates regulatory or financial audit obligations, don’t start with autonomy. Start with tools that are gated: “suggest → human approve → apply,” with strict idempotency on the apply step.

• Bad pattern: agent decides outcome and applies it immediately.
• Better pattern: agent proposes, backend enforces a deterministic transition, and the apply step is idempotent and logged.

I’ve watched teams burn weeks on “better prompting” while the real fix was locking and transaction boundaries. Prompting won’t prevent duplicate state transitions.

Don’t use agents to paper over missing product requirements

If the workflow doesn’t have a clear “done” definition, an agent will happily optimize something you didn’t mean. For example: staff want fewer emails; leadership wants faster resolution; compliance wants exact wording. Without a measurable objective and a bounded action space, agents turn into expensive ambiguity machines.

In the AI Showcase we built internally, we added kill-switches and budget guardrails for a reason: autonomy can silently increase cost and operational load. When you don’t have strong controls, you’re betting the farm on model behavior under drift.

When NOT to use microservices

Microservices are not a performance feature. They’re an organizational feature with an operational tax. Most teams feel compelled because “it’s a clean boundary.” In practice, the boundary often becomes a latency and consistency boundary.

Don’t use microservices when you only need one deployment unit

If the services are updated together on the same cadence, with shared schema evolution, you’re just multiplying release complexity. Every new service adds:

• service-to-service auth and key rotation complexity
• observability wiring (logs, traces, dashboards)
• failure mode handling (timeouts, retries, partial failures)
• cross-service schema migration strategy

One production failure I’ve seen: teams introduced a microservice for “pricing rules” and then got bitten by cache invalidation ordering. A request would hit API gateway → pricing service would consult a stale cache → then the catalog service updated one second later. Result: a 1.1% cart total mismatch rate that was hard to detect because it didn’t break checkout, it just created downstream reconciliation work.

Before splitting services, I’d rather you fix your single service’s performance and caching strategy: proper cache key versioning, cache stampede protection, and strict invalidation semantics.

Don’t use microservices as an excuse to avoid transactions

Microservices tempt teams to replace database transactions with eventual consistency. Sometimes that’s appropriate. But if your business operation expects atomicity—“create order + reserve inventory + record payment intent”—don’t outsource correctness to distributed choreography. You’ll spend months debugging race conditions across network boundaries.

In Laravel systems, I generally prefer a single transactional boundary for core writes, even if I’ve got background jobs that do slow work afterward. Event-driven can come later once correctness is nailed down.

When NOT to use multisite

WordPress multisite is powerful, but it’s also a shared-namespace environment. “Shared” is the keyword you need to interrogate. Shared databases, shared runtime assumptions, shared operational playbooks.

Don’t use multisite when tenants have different upgrade cadences

If your sites need different plugin versions, different PHP requirements, different release schedules, multisite becomes a constant tug-of-war. You’ll end up with a compromise configuration that serves nobody well.

I’ve seen a multisite deployment where one tenant needed a security hotfix. The network admin applied it quickly, but another tenant’s plugin had a compatibility issue. Downtime followed—not for the tenant that needed the fix, but for the one that broke due to shared plugin state.

That’s why I’d rather use separate WordPress installs (or separate environments) when tenants are truly heterogeneous—even if it costs more disk.

Don’t use multisite when you can’t tolerate shared failure domains

Multisite amplifies blast radius. A misconfigured cache plugin or a network-wide upgrade can affect every tenant. If you can’t operate that blast radius responsibly, don’t “consolidate” into multisite.

For WooCommerce, the blast radius is even scarier because checkout reliability is non-negotiable. If you’re consolidating storefronts, prove that your operational and monitoring model can detect a tenant-specific checkout regression fast enough.

When NOT to “just ship headless”

Headless WordPress can be a win: performance, custom UX, reusable frontend, cleaner integration story. But “just ship headless” is usually a symptom of frustration—not a requirement.

Don’t ship headless when editors need safe workflows

WordPress is great at editorial safety: revisions, moderation, and predictable publishing flows. When you detach the frontend from the CMS, you inherit new complexity:

• preview tooling
• cache invalidation between CMS and edge CDN
• draft visibility rules across APIs
• content locking and concurrency control

In a client project for a regulated beverage portfolio, we tried to “move faster” by going headless for marketing pages only. The first problem wasn’t rendering. It was preview correctness. Editors hit “preview,” saw content that didn’t match the eventual public page, then published anyway. We spent days ironing out authorization headers, cache keys, and CDN bypass behavior.

That preview mismatch caused a 15-minute delay in fixing a public page and created internal confusion in a team that had strict compliance sign-off.

Headless isn’t wrong. But if your editors can’t confidently preview and publish, you’re adding risk to the part of the workflow you can least afford to destabilize.

Don’t ship headless if you don’t have a strong performance model

Headless is often justified with “faster pages.” In practice, performance depends on the whole delivery chain: server-side rendering vs CSR, API caching, CDN strategy, and how many round trips your UI makes.

One common failure mode: the frontend makes multiple API calls for the same data, and the CMS doesn’t implement cache headers consistently. Your LCP turns into a slow-motion “API waterfall.”

I like measuring this early. If you can’t hold LCP under 2.0s on real devices in staging, don’t call headless “optimized.” You just moved the bottleneck.

A practical decision rule I actually use

I ask teams to write a one-page “risk ledger” before choosing agents, microservices, multisite, or headless. It has three columns:

• What can break? (data integrity, uptime, compliance, editorial workflow)
• What proof do we have? (load tests, concurrency tests, integration tests, preview correctness checks)
• What’s the rollback? (feature flags, idempotency, deployment isolation)

If a team can’t fill that out, the architecture choice is mostly belief. And belief is expensive.

In our own AI Tax (PHP/MySQL layoff tracker) we learned this the hard way: when you add “intelligence” to a workflow with real-world records, you must have deterministic persistence and explainable state transitions. The model can be probabilistic; the database writes shouldn’t be.

My strong opinion: start boring, then earn complexity

I’m not anti-agent, anti-microservice, or anti-headless. I am anti-adding complexity before you’ve proven the bottleneck and validated operational readiness.

In the apparel brand incident, we didn’t need a smarter agent. We needed a state machine, idempotency, and concurrency control. After the fix, the same workflow dropped from 2.6% inconsistent states to under 0.1% over a week of load replay.

That wasn’t magic. It was engineering judgment: architecture that matches failure modes, not architecture that matches excitement.

Monday-morning quote

“If we can’t prove side-effect safety, consistency, and rollback, we don’t add agents, microservices, multisite, or headless—we fix the boring core first.”

At Champlin Enterprises, we treat architecture like production risk management: deterministic write paths, explicit state transitions, and measurable performance before we split systems or introduce autonomy—because that’s how we ship reliably across WordPress/WooCommerce, Laravel, and applied-AI products like AI Showcase. Champlin Enterprises projects.