Topic
28 articles on Architecture, written from production systems rather than documentation.
Teams pick one model and route everything through it. Most systems have several jobs with different requirements, and one answer fits none of them well.
Benchmarks compare query speed at a scale you may never reach. Filtering, tenancy and how updates behave decide more of the outcome than throughput.
Stdio is the default and it quietly decides your deployment model. The transport question is really a question about process lifetime and blast radius.
Chunk size is treated as a tuning parameter and behaves like an architectural decision. It sets the best answer your system can possibly retrieve.
Prompt engineering asks what to say to the model. Context engineering asks what should be in front of it at all, which is the harder half.
Below a few hundred thousand vectors, a dedicated database mostly adds a system to operate. The threshold is higher than the tooling implies.
Prompts, traces, embeddings and evaluation sets all quietly become copies of user data, and most of them were never on anybody's data map.
Most RAG systems are built against a snapshot and then quietly decay. Indexing is a pipeline with a freshness target, not a one-off import script.
Real queries are never purely semantic. They are scoped to a tenant, a status and a date, and where that filter runs changes the results you get.
The capability gap narrows every few months. What does not narrow is the difference in who controls deprecation, data residency and your cost curve.
A second agent multiplies the coordination problem, not the capability. What decides whether it holds together is who owns the shared plan.
Instructions and data arrive in the same channel, so the model cannot tell them apart. No wording fixes that, because it is a property of the design.
Whether it needs designing from scratch or rescuing from its own success, tell me what you’re building and I’ll tell you how I’d architect it.
Open to remote and hybrid work worldwide