Engineering notes on building intelligent software.

An agent is a loop: decide, call a tool, observe, repeat. The risk comes from what the tools can do and how long the loop may run. Before an agent runs unattended, give it scoped credentials, so it can only touch what its task needs.

Add hard limits on steps, time and spend, and treat everything a tool returns as untrusted input, since text retrieved from the web or a ticket can contain instructions aimed at the model. Finally, require human approval for irreversible actions such as payments or deletions.

Log every step. A trace lets you debug a bad run, prove what happened and build an evaluation set from real cases.

When a retrieval-augmented system gives a wrong answer, the cause is usually that the right passage was never retrieved. Swapping the model rarely fixes that.

Build a set of real questions with known source passages and track recall and precision on retrieval alone. Combine keyword and vector search, since identifiers and rare terms are poorly served by embeddings, and add a reranker for the final ordering.

Enforce permissions during retrieval so restricted text never reaches the model, and have the system decline to answer when the evidence is weak.

Headless commerce separates the storefront from the commerce engine. You gain control of performance and design, and the freedom to add search or an assistant without waiting for a platform release.

The cost is ownership: you maintain the front end, previews, caching and integrations. It pays off when the storefront is a differentiator, when you sell across channels or when platform limits are already costing sales.

If a standard theme meets your needs and your team is small, a conventional platform may be the better choice.

A deployment platform is a build system, a runtime, a router, an observability layer and an isolation model. Builds must be reproducible and cached. The runtime must health-check before switching traffic and roll back on failure.

Routing handles domains and certificates automatically. Observability gives each project its own logs and metrics. Isolation matters most if customers' code shares infrastructure, so design it before anything else.

Whether you adopt an open platform or build your own, these five concerns remain.

Interfaces should never hold private keys. Show users in plain language what a transaction will do, and simulate it before the wallet prompt appears. Handle pending, failed and reorganised transactions explicitly.

Index events with replay support so your data can be rebuilt. If you depend on smart contracts, have them audited by an independent specialist. Interface developers are not a substitute.

Regulatory questions around custody, tokens and payments need legal advice before engineering begins.

Buy when a product covers most of your process and the remaining gaps are small. Build when the process is a source of advantage, when integration requirements are heavy or when licensing costs scale badly.

Often the best answer is to compose: keep a commercial core and build the differentiating parts around it through APIs.

Whatever you choose, plan for exit: own your data, prefer open formats and keep integrations behind interfaces you control.

The EU AI Act entered into force in 2024 and its obligations are phasing in between 2025 and 2027, with the timing of some high-risk rules still under review. Whatever the final dates, buyers and auditors already ask the same questions: what the system does, how it was tested and who can intervene.

Engineering can answer those questions cheaply if it starts early. Keep an inventory of AI features and the models behind them, log inputs, outputs and tool calls, version prompts like code, and keep evaluation results for every release. Design a clear point where a person can review or override a consequential decision.

None of this replaces legal advice on how your system is classified. It does mean that when the classification arrives, the evidence already exists.

A growing share of product discovery starts in AI assistants rather than search boxes. An assistant comparing options reads structured data: titles, attributes, availability, price, delivery times and return policies. Stores with thin or inconsistent data simply get skipped.

Getting ready is mostly unglamorous work: complete product attributes, clean variant structures, accurate stock and accessible APIs or feeds. Checkout flows should handle orders that arrive with intent already decided, while keeping payment authorisation with the shopper and a licensed provider.

The human storefront still matters, but it now shares the stage with machine readers. Treat product data as a product.