One of the stranger bugs I ran into while building Mac MCP looked, at first, like a successful browser action. An AI agent entered text in a web editor. The words appeared on the screen, and the tool returned successfully. But the page hadn't accepted the edit in its own internal state. When it rerendered, the text disappeared.

That bothered me more than a straightforward error would have. If a tool fails loudly, at least you know where to look. Here the visible result and the real result had parted company, and the agent couldn't tell.

I build Mac MCP, a local service that lets AI clients work with macOS apps, browsers, files and commands. At first it's easy to focus on the model: which one plans better, how many tools it can call, how often a task finishes without help. I care about those things. But the bugs that changed how I think about the product mostly happened after the model had already made its decision.

That's what I mean by the execution boundary. The model can ask to type into a page, open a file or run a command. A separate local service has to decide whether the request is allowed, whether the target is still the right one, and what it can honestly say happened afterward. Those are three different questions.

Say you ask an agent to write a reply and leave it as a draft. It's a small task: find the field, type the message, stop. One extra click can send it. To the model, that might be a minor mistake in an otherwise reasonable sequence of actions. To the person whose account it is, the consequence is quite different.

I don't want the model's confidence to override that instruction. Permission has to be checked against the actual operation, not against the model's explanation of why it thinks the operation is harmless. If the user said "don't send," a convincing paragraph of reasoning shouldn't make Send an acceptable button to press.

The editor bug taught me the same lesson from the other direction. A tool reporting that it typed something doesn't prove the website saved it. Rich-text editors keep their own state, which doesn't always agree with the text you can see. In Mac MCP, I've worked on distinguishing a visible insertion from a confirmed editor change. When that confirmation isn't there, the tool can report editor_model_unconfirmed rather than pretending the edit stuck. Even that isn't proof of a server-side save. It's a more precise account of what the tool actually checked.

Working with more than one agent exposed another weak assumption. With a single agent, it's easy to think the browser tab and focused field you inspected a moment ago still belong to your task. With two agents, one can change the page while the other is deciding what to do. A perfectly sensible click, aimed at yesterday's version of the page—or even the version from two seconds ago—can land somewhere entirely different.

I used to think of that mostly as an orchestration problem. It's also an execution problem. The tool needs to know which tab and element the action belongs to and when its information has gone stale. More reasoning tokens won't make an old screenshot current. Sometimes the right response is simply to refuse the action and ask the agent to observe again.

Then there's the less dramatic but very personal issue of focus. I want an agent to work while I'm using my Mac. I don't want it dragging Safari to the front halfway through an email or taking over the keyboard while I'm typing. I've been testing ways to give agent work its own macOS Desktop instead of making every task compete for the same foreground workspace.

A separate Desktop helps with the interruption problem, but it doesn't magically solve permission or verification. The agent can still target the wrong thing. The browser can still reject a change. And some actions genuinely require foreground access. When they do, I'd rather see an honest stop than a clever fallback that steals the screen.

Shell commands make these distinctions even more important. A delegated AI provider might describe its environment as sandboxed, but that description doesn't automatically cover what a separate local macOS service can execute. I have to look at where a restriction is actually enforced and which path, if any, can go around it. A sentence in a system prompt is useful guidance. It isn't an operating-system boundary.

The practical question I keep coming back to is: what happens if the model makes the wrong choice? Does a check outside the model prevent the action, or are we relying on the model to remember a rule it was told? I don't think it's fair to call those two arrangements equally safe.

I'm also becoming more careful with the word "done." If an agent submits a form, there is a difference between a click being dispatched, the browser accepting the action, and the server recording the result. A verification check can fail because the expected result isn't there. It can also fail to run at all because the service is unreachable. The second case is unknown, not proof that the action failed. Retrying the check is sensible; blindly repeating a purchase or a post isn't.

All of this makes some demonstrations less impressive. Extra checks add time. Permission prompts are interruptions. A stale-state error means the agent might need to try a different approach. But I'm building something for a computer that belongs to a person, not a benchmark environment where the only thing that matters is a green completion badge.

I haven't solved every one of these problems in Mac MCP. Some protections are implemented; others are still being tightened, tested or redesigned. Writing down the boundary has made it easier to notice where I was treating a tool response as stronger evidence than it really was.

I still enjoy trying a new model. I just care more now about the questions that come after its plan: what was it allowed to touch, did it leave my own work alone, and can it show me what actually changed?

If the truthful answer is "I tried, but I can't verify that it worked," I want the tool to say that. It's a much better starting point than an agent confidently telling me a job is finished when it isn't.

Author's note: I used AI assistance to edit this article. The examples and technical decisions discussed here come from my work on Mac MCP.

The Model Shouldn’t Own My Desktop. The Execution Boundary Should. was originally published in Beyond Localhost on Medium, where people are continuing the conversation by highlighting and responding to this story.

The problem

A user registers. From there they can create auctions or participate as a bidder on someone else’s. Bids come in, and the highest valid bid at close wins. Simple to state, hard to do well.

The scale I designed for:

• ~1 lakh (100k) running auctions per day
• ~10 million users
• Hot auctions peaking around 1k requests/sec on a single auction id
• A long tail of cold auctions nobody’s watching
• Consistency > availability. If I have to choose, I’d rather reject a bid than accept a wrong one.

Out of scope

No cancellations. Once a bid is accepted, it stands. Cancellation of bid is not allowed

Payment. I’m not designing the money movement — charging cards, settling with sellers. But I’ll present some ideas on it, because deciding what to keep out of the hot path is itself a core part of the design. “Payment is out of scope” is not the same as “money doesn’t exist.”

The shape of it

Rather than one monolith, I split responsibilities into services with genuinely different load profiles and consistency needs:

1. CRUD service — auctions and users
2. Search service — discovery
3. Bidding path — Reverse Proxy → Bidding Service → Post Processor / Notification
4. Audit path — Bids Audit Queue → OLAP consumer
5. A CDC backstop from the Bids DB for added correctness

Let me walk each one in the order a request actually flows.

CRUD service

The least interesting part, which is a good thing. It receives and persists auction and user data into a plain relational DB (MySQL is fine). Keeping basic properties of user and auction here (refer diagram)

No cleverness here. This data is low-write, read-heavy, and perfectly happy on a boring SQL database. Resist the urge to over-engineer the easy parts.

Search service

Discovery is powered by Elasticsearch, kept in sync with the auction table via CDC. ES will prioritise live and future auctions and actively clean out old ones. Nobody searches for an auction that ended three weeks ago. Keeping the index scoped to “things you can actually bid on” keeps it small, fast, and cheap.

CDC gatekeeps as a perfect trigger for this, example if status is changed to Done, give it lesser score in search, changed to archived remove from ES.

The bidding path — this is the whole game

Everything above was a warm-up. Bidding is where correctness and scale collide.

The first real decision: how do you survive a very hot auction without turning your whole fleet stateful? Stateful service are a headache to manage, stateless service with 1L requests? Good luck handling Db queries at that scale.

So, let’s build the middle ground.

Let’s build an approach, where nobody owns the particular auction but knows where to requests should land. So, first questions first, are all auctions same? No. Some receive low traffic, others high (let’s call them hot_auction) and other very high (calling very_hot_auction). Categorising each one of them and processing accordingly will help us with achieving the scale.
And the real bottleneck was never the request handling anyway; it’s the DB writes on very_hot_auctions. Spreading reads around doesn’t fix the thing that’s actually on fire.

Reverse Proxy: detect heat early, without going stateful

So instead of pushing routing logic into the API gateway, I put a bit of client-side logic on the reverse proxy and deployed it there. The pragmatic reason: it was far easier to maintain and ship changes to a proxy I own than to modify the entire gateway layer. Smaller blast radius, faster iteration.

What does that logic do? It answers one question cheaply: is this auction hot right now? And crucially, it doesn’t need an exact count to do that. I don’t care whether an auction got 973 or 1,041 requests this second — I care that it’s “heavy enough.” So I just keep an eye on the recent count of requests per auction id, and if it crosses a threshold, I treat it as a hot auction. Approximate, cheap, and — importantly — it keeps the design from going stateful just to make a routing decision.

The payoff of detecting it here, at the one place that sees all the traffic: no service downstream has to build its own detection logic. The proxy stamps a hot_auction header on the request, and everyone after it just consumes and trusts the header. Dumber downstream services are easier to reason about and test.

Very High Load

For scenario of very_hot_auction (again deduced from the configured request count), the proxy will add a from a bounded set (e.g. 0–9) of prefixes like ‘2’ to ‘auction_1’ and then process consistent hashing logic on combined key (i.e. 2_auction_1 instead of ‘auction_1’ ) making very_hot_auction to be distributed as ‘hot_auction’ across multiple consistent hashed servers.

Benefit: we only need to solve for normal and hot_auctions, any scale beyond that gets distributed.

Bidding Service: the local-max trick

Under normal load, a bid is simple: check it beats the current winner, check it’s a valid multiple of the tick price, check the auction hasn’t ended, write winner bid to the Bids DB, respond success/ failure to the client.

Please note, DB write query is conditional with ‘new_bid_price > current_winning_bid_price’. So among concurrent write attempt, higher bid will win even at DB.

Under hot_auction load, writing every bid straight to the DB would destroy it. So we buffer it in server memory for minimal period instead:

• Each bidding server keeps the local maximum bid it has seen for that auction, in memory.
• It holds for a short window and only attempts to write its local max to the DB.

The holding period is configurable, and it commits on whichever comes first: a request count on that server (say 100–200 bids buffered) or a time ceiling (100ms wait). Two knobs, two guardrails — the count protects the DB from a sudden burst, and the timer protects the customer experience so nobody waits too long for an answer. Together they cut DB load dramatically while keeping response time bounded.

Essentially we reduce the DB writes drastically to 100–1000x and protect it. Yes, it can happen server crashes while data is in memory. Well, in defense, first of all that happens in rare cases, we keep server numbers optimal. And even when that happens, for clients it will be a normal BAU retryable failure. Clients can retry.

Let’s Add More Load

Let’s say you add more load. As discussed above, proxy will distribute the load as ‘hot_auction’ among bidding service. Each service only will care about load locally. You know why? Cause max of (local max) is all we need.

Now picture a very_hot_auction spread across a few servers. Each holds its own local max. They all try to write to DB. The conditional write means only the true maximum price write succeeds — the others fail, re-read the latest winner, and move on. The invariant that makes this safe is simple:

max(local maxes) is always the real maximum, no matter which server a request landed on.

Correctness rides on that one conditional write at the DB — the single serialization point. That’s the trade I’m happiest with: I spread load across servers and keep a single source of truth, persistent DB.

Serving reads from the Bidding Service itself

Here’s a choice I’d defend hard: reads for the live bid are served straight from the Bidding Service’s memory. Why build an entire separate read path?

Every server handling a live auction already has the current bid data in memory — it needs it to validate incoming bids. So the cheapest correct thing is to serve “what’s the current bid?” right out of that in-memory state. I’d much rather do that than stand up a full read-replica fleet and a fancy CQRS pattern for a read that’s already sitting in RAM.

Closing the auction correctly

If I naively fire a “winner!” notification exactly at end_at.

So the Post Processor doesn’t trust the instant of end_at. It polls (using a partial index on status, end_at) for auctions whose end time is older than now minus a grace window — say 10 seconds. By then every server's buffer has drained, the conditional writes have settled, and the Bids DB genuinely holds the final winner. Then, and only then, the notification goes out.

A 10-second delay on “you won” is invisible to a user. A wrong winner that can’t be taken back is a disaster. Easy call.

The audit path: where bid history actually lives

Every single bid — winning or not — is published to a Bids Audit Queue.

That queue feeds an OLAP consumer (think ClickHouse). That’s where user-facing bid history lives: “you bid $400, you were outbid at $450, you bid $500…” By tuning the number of consumers I keep the lag in a comfortable range, and I get a cheap, queryable, append-only record of everything that ever happened — perfect for history views and dispute resolution, kept well off the hot transactional path.

The OLTP database stays lean (it only tracks the ratchet of the current max), and the “show me everything” workload goes to a store built exactly for it.

Right tool, right job.

CDC as a correctness backstop

Buffering bids in memory means a server can crash mid-window and lose bids it hadn’t flushed. I accept this — it’s the price of buffering — and for most auctions, a rare “something went wrong, try again” is a fine answer. Because responses only go out after the batch commits, a crash means the bidder gets an error, not a false “you’re winning.”

But when I want stronger guarantees, I lean on a CDC pipeline off the Bids DB. It can drive de-duplicated notifications to the user (who could have lost confirmation due to server crash). The point: I treat absolute accuracy as a dial, not a default.

A word on the money movement

Payment is out of scope, but keeping money out of the hot path is itself a design decision worth showing.

My preference: a block → confirm → release flow on the wallet service, kept off the live bidding path. Block some amount when a user registers, confirm via CDC when they win, release via TTL or CDC when they don’t. And set each user’s ceiling at registration based on credit/KYC — in a separate, offline flow, never in the hot path.

I’m not putting a synchronous wallet call in front of a hot auction. Pull funds before, or settle after. The variants you can offer — pre-fund a max bid, pay a token amount to participate, or KYC-only with a credit ceiling — are all just different answers to the same question: what’s the minimum you must check in the hot path, and what can wait?

Closing thought

The interesting engineering isn’t in making the happy path work — it’s in deciding, explicitly, how wrong you’re willing to be, and for how long.

Designing an Auction Service: Where I Chose Correctness, and Where I Didn’t was originally published in Beyond Localhost on Medium, where people are continuing the conversation by highlighting and responding to this story.

The festive season is here, and once again it is the most demanding stretch of the year for ecommerce brands. Traffic peaks during the wave of sales on ecommerce and quick commerce platforms. Shopper intent is at its highest; the battle for the digital shelf, and ultimately the conversion, is real.

This year, the stakes are bigger. Redseer expected festive 2026 to be the strongest in five years, with online festive GMV of USD 15–16 billion, around 25% growth and 180–185 million shoppers. (Source: Redseer) The first two days of sales alone crossed ₹24,000 crore, nearly six times a normal day. And two in every three online shoppers in those first two days came from smaller towns.

But the shape of the season has changed. Demand is spreading well beyond the metros, with online sales expected to grow by up to 29%. (Source: Fortune India) Quick commerce is projected to grow 110–120% this festive period.

The season hasn’t been a straight line up, either. After the opening rush, sales fizzled as higher prices in the electronics category made shoppers hold back. Brands now have to win a shopper who is spread across more towns and compares prices harder than ever.

That means more shelves to watch, prices moving every hour, and more ad decisions than any team can make manually. Every missed keyword, every out-of-stock product and every lost rank still hands the sale to a competitor. What has changed is how fast it happens.

In this article, we look at the challenges brands face during festive sales in 2026, and how data-driven digital shelf analytics, now paired with agentic AI, helps brands move from spotting a problem to fixing it in time.

Challenges Ecommerce Brands Face During Festive Season Sales

Too Many Shelves, Too Little Visibility

Your share of shelf is no longer one search page. It is Amazon, Flipkart, Myntra and Nykaa, plus Blinkit, Zepto, Instamart and newer quick commerce apps, each showing different results by city and even by dark store. A SKU can rank first in Bengaluru and be missing in Pune. Without SKU-level, location-level visibility, these gaps surface only after the sales are lost.

Stockouts at the Worst Possible Moment

Quick commerce transforms festive demand into quick decisions measured in minutes. If your product is not in stock in an important pin code during high-demand times, people will not stop; they will go with the next available item from the list. Moreover, many brands are spending money on advertising campaigns that bring them no profit.

Competitive Pricing That Move by the Hour

Flash deals, reseller undercutting and MAP violations spike during sales. Shoppers are better armed too: AI assistants like Amazon’s Rufus now show price history, so inflated “discounts” get exposed quickly. Brands need real-time visibility into their own and competitors’ pricing to respond without eroding margins or brand value.

Product Pages Written for People, Now Read by AI

AI shopping assistants and review summaries increasingly shape what shoppers see first. Incomplete titles, missing attributes, low-quality images and inconsistent content across sellers hurt both search ranking and how AI tools describe your product. Your PDP and reviews are now part of discovery, not just conversion.

Media That Can’t See the Digital Shelf

This is the biggest gap. Media sees the campaign: spend, clicks and ROAS. Ecommerce sees the market: rank, share of shelf, price and availability. During festive peaks, the two rarely meet. Bids keep climbing on keywords where you’re out of stock, budget stays locked on a platform where your price is uncompetitive, and a rival overtakes your hero keyword while campaigns run on autopilot. The result is wasted spend on low-intent areas and missed revenue where demand is real.

Click Here to Read Full Blog: https://tinyurl.com/2kr4hz9h

Festive Sales 2026: Digital Shelf Analytics and AI Optimization was originally published in Beyond Localhost on Medium, where people are continuing the conversation by highlighting and responding to this story.