<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:media="http://search.yahoo.com/mrss/">
  <channel>
    <title>BraivIQ Playbook - engineering guides for AI in UK financial firms</title>
    <link>https://www.braiviq.com/playbook</link>
    <atom:link href="https://www.braiviq.com/playbook/rss.xml" rel="self" type="application/rss+xml" />
    <description>Code-first build guides on agentic AI, RAG, integration, trading systems and production engineering for UK financial firms, from BraivIQ.</description>
    <language>en-GB</language>
    <lastBuildDate>Fri, 09 Oct 2026 09:00:00 GMT</lastBuildDate>
    <item>
      <title>Agentic AI Architecture For Approvals You Can Prove: Pre-Tool Gates, Signed Sign-Off And Audit Logs In Python</title>
      <link>https://www.braiviq.com/playbook/agentic-ai-architecture-approval-gates-python</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/agentic-ai-architecture-approval-gates-python</guid>
      <pubDate>Fri, 09 Oct 2026 09:00:00 GMT</pubDate>
      <category>Agentic AI</category>
      <description>In agentic AI architecture for a financial firm, no tool call that changes a record should run because the model, or a message, said so. Every call passes a deterministic gate outside the model, and anything consequential waits for an approval that a named person signed for those exact arguments, with each decision written to a tamper-evident audit log. On 28 September 2026 the UK AI Security Institute reported that GPT-6 Astra, in a simulated evaluation, treated an automated &quot;Please proceed&quot; message as permission to act. Between 10 September and 7 October, Anthropic, LangChain, Pydantic, Google and Microsoft all shipped pre-tool-use controls. This playbook shows the pattern in tested Python.</description>
      <media:content url="https://www.braiviq.com/playbook-images/agentic-ai-architecture-approval-gates-python-thumb.jpg" medium="image" />
    </item>
    <item>
      <title>Trade Surveillance AI In Code: Triage Alerts With An Analyst In The Loop And Chart The Evidence</title>
      <link>https://www.braiviq.com/playbook/trade-surveillance-ai-alert-triage-code</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/trade-surveillance-ai-alert-triage-code</guid>
      <pubDate>Fri, 09 Oct 2026 09:00:00 GMT</pubDate>
      <category>Trading</category>
      <description>Trade surveillance AI earns its place in alert triage, not in the final decision. It assembles the evidence for each alert, orders the queue by how often similar alerts were escalated in the past, and shows the analyst a chart of prices and the trader's orders, while a named analyst still decides every alert. On 22 September 2026 the FCA's chief executive said the regulator is exploring agentic AI as its &quot;first responder&quot; for wholesale market monitoring, and on 16 September TradingView published the first official plugin packages for Lightweight Charts. This playbook builds the triage pipeline in Python and the evidence chart in TypeScript, with sample data only.</description>
      <media:content url="https://www.braiviq.com/playbook-images/trade-surveillance-ai-alert-triage-code-thumb.jpg" medium="image" />
    </item>
    <item>
      <title>LLM Classification Under The Hood: How The New Decision Models Return Probabilities, And When Not To Use Them</title>
      <link>https://www.braiviq.com/playbook/llm-classification-decision-models-explained</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/llm-classification-decision-models-explained</guid>
      <pubDate>Fri, 09 Oct 2026 09:00:00 GMT</pubDate>
      <category>RAG &amp; LLM Engineering</category>
      <description>LLM classification has a new shape. Instead of generating a label and hoping, the decision models released in the last four weeks score a closed set of answers and return probabilities. TypeSafe launched Jev on 15 September 2026, Cloudflare open-sourced Clef on 1 October and OpenAI put its Decisions API into beta on 6 October. The probabilities are only useful if they are calibrated on your own data, and an independent Red Hat benchmark published on 2 October found decision models no faster, cheaper or better than an LLM judge on its tasks. This deep dive explains how they work, how to measure them and when a fine-tuned classifier is still the better choice.</description>
      <media:content url="https://www.braiviq.com/playbook-images/llm-classification-decision-models-explained-thumb.jpg" medium="image" />
    </item>
    <item>
      <title>AI Guardrails After The Bank Of England's September Warning: What UK Regulators Now Expect From Teams Building AI Agents</title>
      <link>https://www.braiviq.com/playbook/ai-guardrails-uk-regulators-ai-agents</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/ai-guardrails-uk-regulators-ai-agents</guid>
      <pubDate>Fri, 09 Oct 2026 09:00:00 GMT</pubDate>
      <category>AI Strategy &amp; ROI</category>
      <description>In the three weeks from 21 September to 8 October 2026, five UK public bodies said something concrete about AI agents, and together they amount to a specification for AI guardrails. The Bank of England's Financial Policy Committee warned on 30 September that increasingly autonomous models could take unexpected actions and that containment, monitoring and governance could be challenged. The AI Security Institute described its own layered controls on 1 October, the NCSC proposed a five-part score for automated actions on 21 September, and the ICO opened a call for evidence on agentic AI on 8 October. This playbook maps each statement to the controls UK engineering teams should build, with tested Python.</description>
      <media:content url="https://www.braiviq.com/playbook-images/ai-guardrails-uk-regulators-ai-agents-thumb.jpg" medium="image" />
    </item>
    <item>
      <title>T+1 Settlement Automation Inside An Investment Bank: A Worked Example Of What The Dev Team Has To Learn</title>
      <link>https://www.braiviq.com/playbook/t1-settlement-automation-investment-bank-ai</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/t1-settlement-automation-investment-bank-ai</guid>
      <pubDate>Fri, 09 Oct 2026 09:00:00 GMT</pubDate>
      <category>Deployment &amp; Production</category>
      <description>T+1 settlement automation in a UK investment bank starts with confirmation exceptions, because the UK plan requires allocations and confirmations to be completed electronically by 23.59 UK time on trade date, and firms are meant to reach that by the end of 2026. This worked example builds an assistant that reads counterparty emails inside the bank's AWS boundary, compares them with the booking system and prepares amendments that an analyst approves. It walks through what the dev team has to learn: legacy data access, a restricted network, deadlines in GMT and BST, model change control as Anthropic retires Claude Sonnet 4.5 on 30 November 2026, evaluation, approval points and audit.</description>
      <media:content url="https://www.braiviq.com/playbook-images/t1-settlement-automation-investment-bank-ai-thumb.jpg" medium="image" />
    </item>
    <item>
      <title>Workflow Automation Architecture For Human Sign-Off: Durable Approval Steps With LangGraph 1.2 In Python</title>
      <link>https://www.braiviq.com/playbook/workflow-automation-architecture-durable-approvals</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/workflow-automation-architecture-durable-approvals</guid>
      <pubDate>Fri, 09 Oct 2026 09:00:00 GMT</pubDate>
      <category>Workflow Automation</category>
      <description>A workflow automation architecture that a financial firm can sign off has three properties at the approval step: it can wait for days without losing state, it only accepts a decision in a known shape from a known person, and the action after approval runs exactly once even if the process crashes. LangGraph 1.2.12, released on 21 September 2026, added a response schema to interrupt(), so a resume value is validated before the workflow continues. Google's ADK 2.9.0 changed resume behaviour on 10 September so a failed step runs again, which makes idempotent side effects compulsory. This playbook builds a client bank-detail change with all three properties in tested Python.</description>
      <media:content url="https://www.braiviq.com/playbook-images/workflow-automation-architecture-durable-approvals-thumb.jpg" medium="image" />
    </item>
    <item>
      <title>MCP Integration After The September 2026 SDK Advisories: Pinned Issuers, Audience Checks And Bounded Sessions In Python</title>
      <link>https://www.braiviq.com/playbook/mcp-integration-security-hardening</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/mcp-integration-security-hardening</guid>
      <pubDate>Fri, 09 Oct 2026 09:00:00 GMT</pubDate>
      <category>AI Integration</category>
      <description>Secure MCP integration now means more than upgrading the SDK. Between 28 September and 5 October 2026 the Model Context Protocol project published ten security advisories across its Python and TypeScript SDKs, covering OAuth credentials sent to a server-chosen authorisation server, tokens accepted for the wrong service, unbounded sessions and request bodies, and cross-origin redirects. The fixes are in mcp 2.2.0 and @modelcontextprotocol/sdk 1.32.0, but two of them do nothing until you change your configuration. This playbook shows the server and client settings in tested Python, and why it matters now that vendors such as Bloomberg are putting licensed data behind MCP.</description>
      <media:content url="https://www.braiviq.com/playbook-images/mcp-integration-security-hardening-thumb.jpg" medium="image" />
    </item>
    <item>
      <title>Prompt Injection Defence For AI Agents In Code: Provenance Tracking, Quarantined Readers And Signed Messages</title>
      <link>https://www.braiviq.com/playbook/prompt-injection-defence-ai-agents-code</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/prompt-injection-defence-ai-agents-code</guid>
      <pubDate>Fri, 09 Oct 2026 09:00:00 GMT</pubDate>
      <category>Agentic AI</category>
      <description>Prompt injection defence for AI agents works when untrusted text can never become an instruction. Track where every piece of context came from, read untrusted content with a model that has no tools and returns typed fields, narrow the agent's tools once untrusted text is present, and sign messages between agents. A paper published on 19 September 2026 reported that four architectural defences cut injection success in a six-agent system from 31.2% to 4.2%, and OpenAI disclosed on 25 September 2026 that injections can copy themselves between agents. This playbook turns those findings into tested Python.</description>
      <media:content url="https://www.braiviq.com/playbook-images/prompt-injection-defence-ai-agents-code-thumb.jpg" medium="image" />
    </item>
    <item>
      <title>Who Is This Agent And What May It Do? Agent Identity, Delegated Authorization And The 2026 Protocol Stack In Code</title>
      <link>https://www.braiviq.com/playbook/agent-identity-delegated-authorization-2026-protocol-stack-code-spiffe-oauth-token-exchange-on-behalf-of</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/agent-identity-delegated-authorization-2026-protocol-stack-code-spiffe-oauth-token-exchange-on-behalf-of</guid>
      <pubDate>Fri, 02 Oct 2026 09:00:00 GMT</pubDate>
      <category>Agentic AI</category>
      <description>Every production agent eventually reaches the moment that decides whether it is safe: it is about to call a tool, an API or another agent, on behalf of a person, and the system on the other side has to answer two questions in microseconds - who is this agent, and what may it do? For two years most teams answered with a shared API key and hope. In 2026 that is over. Authorization was the story of Identiverse, a July IETF Internet-Draft set out an architecture for agent credentials, delegated user authority, workload identity and audit trails, Google published the open Agentic Resource Discovery specification, the OpenID Foundation formalised a dual-identity model in which an agent proves both who it is and whose authority it carries, and Microsoft's Agent Framework now scopes MCP sessions per invocation and authenticates every request to the correct identity. This flagship playbook, for senior engineers and architects, is the resulting protocol stack in code: discovery, workload identity, request authentication and delegated authorization as four distinct layers, the on-behalf-of chain preserved end to end, deterministic authorization before every tool call, and the permission-intersection rule that stops delegation becoming a way to launder privilege.</description>
      <media:content url="https://images.unsplash.com/photo-1545987796-200677ee1011?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>The Price Of Thinking: Reasoning Effort, Thinking Budgets And How To Spend Reasoning Tokens In Production - A Senior Engineer's Guide</title>
      <link>https://www.braiviq.com/playbook/price-of-thinking-reasoning-effort-thinking-budgets-production-2026-senior-engineers-guide-cost-latency</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/price-of-thinking-reasoning-effort-thinking-budgets-production-2026-senior-engineers-guide-cost-latency</guid>
      <pubDate>Thu, 01 Oct 2026 09:00:00 GMT</pubDate>
      <category>RAG &amp; LLM Engineering</category>
      <description>Reasoning models quietly broke the cost model every team had internalised. A standard completion returns an answer. A reasoning model first produces a thinking trace of four to sixteen thousand tokens - sometimes far more - and that trace counts against the context window, is billed as output, and routinely makes a request run an order of magnitude longer than a chat completion. Left on the default, the smartest models are also the most expensive and the slowest, and the gain is real only on the fraction of requests that actually needed the thinking. In 2026 the providers exposed the dial - OpenAI's reasoning effort levels, Anthropic's effort parameter that lets the model decide how much to think within a ceiling - and the practitioners who learned to use it report cutting cost by 40-60% with no loss on the work that matters. This educational deep-dive, for senior engineers and CTOs, explains what thinking tokens are and why they cost what they do, why effort is a model-specific contract rather than a universal setting, which tasks pay back the thinking and which burn it, and the production pattern that works: classify first, budget to match, default low, escalate on signal, and measure per task.</description>
      <media:content url="https://images.unsplash.com/photo-1512314889357-e157c22f938d?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Britain's AI Growth Lab: Regulatory Sandboxes Where UK Developers Can Ship Under Relaxed Rules - And The Copyright Line They Still Cannot Cross</title>
      <link>https://www.braiviq.com/playbook/uk-ai-growth-lab-regulatory-sandbox-2026-copyright-tdm-ofcom-chatbots-what-uk-developers-can-ship-pro-uk</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/uk-ai-growth-lab-regulatory-sandbox-2026-copyright-tdm-ofcom-chatbots-what-uk-developers-can-ship-pro-uk</guid>
      <pubDate>Thu, 01 Oct 2026 09:00:00 GMT</pubDate>
      <category>AI Strategy &amp; ROI</category>
      <description>Britain has done something few countries have managed with AI regulation: built an instrument that lets developers ship rather than one that only tells them what they may not do. The AI Growth Lab launched on 8 June 2026 - a set of sector-specific sandboxes in which businesses test AI products in real conditions, with some rules temporarily relaxed under licence and safeguards in place, with legal services and conveyancing as the first focus area. For an engineering team it is a path through the rules that would otherwise stall a product, and a pragmatic, pro-innovation piece of British design. It sits alongside two lines that remain firmly drawn, and an honest read has to hold all three. The government's March 2026 copyright report took the broad text-and-data-mining exception off the table with no replacement, leaving the narrow non-commercial research exception - so in Britain, training-data licensing and provenance are engineering requirements, not afterthoughts. And Ofcom has confirmed that Online Safety Act duties cover generative AI and chatbots, treating AI output exactly like user content, with enforcement and investigations already under way. This educational, openly pro-UK read explains what the sandbox is and how a team applies in practice, what the copyright decision means in code, what Ofcom's position means for a chatbot's design, and where the honest caveats lie.</description>
      <media:content url="https://images.unsplash.com/photo-1505664194779-8beaceb93744?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Building A Real-Time Alerts Engine For Trading Charts In Code: Evaluating Thousands Of Price And Indicator Conditions On Every Tick</title>
      <link>https://www.braiviq.com/playbook/building-real-time-alerts-engine-trading-charts-code-thousands-price-indicator-conditions-every-tick</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/building-real-time-alerts-engine-trading-charts-code-thousands-price-indicator-conditions-every-tick</guid>
      <pubDate>Wed, 30 Sep 2026 09:00:00 GMT</pubDate>
      <category>Trading</category>
      <description>Every charting platform offers alerts - tell me when the price crosses this level, when RSI goes above seventy, when the fast average crosses the slow one - and traders set them by the thousand. Behind that simple feature is an engine that must evaluate every rule against every relevant tick or bar, across every instrument, without lag, without missing a crossing that happened between two updates, without firing the same alert twenty times as price oscillates around a level, and without losing alerts when a connection drops. A naive implementation - loop over all rules on every tick - works for a hundred alerts and collapses at a hundred thousand. This playbook, from a team that specialises in trading charts and automation, is a code-side account of building an alerts engine that holds up: compiling user rules into typed predicates, indexing them so a tick checks only the rules it could possibly trigger, the surprisingly subtle semantics of a crossing, evaluating on bar close versus every tick, feeding indicator-based conditions from the incremental indicator engine, deduplication and cooldowns, reliable delivery with idempotency, catch-up after outages, and testing by deterministic replay.</description>
      <media:content url="https://images.unsplash.com/photo-1496096265110-f83ad7f96608?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Pre-Trade Risk Controls And The Kill Switch: What A Trading Firm's Dev Team Must Learn To Build For Algorithmic And AI-Driven Trading</title>
      <link>https://www.braiviq.com/playbook/pre-trade-risk-controls-kill-switch-algorithmic-ai-trading-dev-team-mifid-rts6-code-2026</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/pre-trade-risk-controls-kill-switch-algorithmic-ai-trading-dev-team-mifid-rts6-code-2026</guid>
      <pubDate>Wed, 30 Sep 2026 09:00:00 GMT</pubDate>
      <category>Case Studies</category>
      <description>Every order an algorithm sends to a market passes, in the microseconds before it leaves the firm, through a layer of checks that most people outside trading technology have never heard of and that regulators care about more than almost anything else. Pre-trade risk controls stop a mis-configured strategy, a corrupted parameter, a fat-fingered size or - increasingly - a model that has decided something unwise from reaching the market, and the kill switch stops an algorithm, a desk or the whole firm instantly when something is wrong. Under MiFID II's RTS 6 and the FCA's rules, a firm engaging in algorithmic trading must have both, and must prove they work. In 2026 the problem has acquired a new edge: AI-driven strategies and trading agents generate orders from models that cannot be fully audited in advance, which makes deterministic controls outside the model more necessary, not less. This playbook, from a team that builds trading technology, is a practical, code-side account of what a dev team must learn: the control set, building it deterministically in the order path at sub-millisecond latency with fail-closed semantics, the kill switch as a first-class system, conformance testing and drills, and the audit trail that turns controls into evidence.</description>
      <media:content url="https://images.unsplash.com/photo-1504917595217-d4dc5ebe6122?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Event-Driven Agents: Webhooks, Queues And Backpressure - Triggering Automations Reliably In Code</title>
      <link>https://www.braiviq.com/playbook/event-driven-agents-webhooks-queues-backpressure-triggering-automations-reliably-code-2026-workflow</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/event-driven-agents-webhooks-queues-backpressure-triggering-automations-reliably-code-2026-workflow</guid>
      <pubDate>Tue, 29 Sep 2026 09:00:00 GMT</pubDate>
      <category>Workflow Automation</category>
      <description>Most automations that run a business are not started by a person typing a prompt. They are started by an event: a webhook from a payment provider, a message on a queue, a file landing in a bucket, a record changing in the CRM, a form submitted on a website. The agent is the interesting part. The unglamorous layer between the event and the agent is what decides whether the automation is reliable - whether a webhook that arrives twice runs the agent twice, whether a burst of ten thousand events fans out into ten thousand expensive agent runs at once, whether an event that fails is lost forever or replayed, and whether anyone can trace a surprising agent action back to the event that caused it. This playbook is a code-side guide to that layer: webhook ingestion that verifies signatures and rejects replays and acknowledges fast, a durable queue between ingestion and processing, the outbox pattern, idempotency and deduplication against at-least-once delivery, per-entity ordering, backpressure and rate control so events do not become runaway cost, dead-letter queues and replay, and tracing from event to action. It is the plumbing that turns an agent into an automation you can run unattended.</description>
      <media:content url="https://images.unsplash.com/photo-1639815188546-c43c240ff4df?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>MCP Tool And Skill Supply-Chain Security: Scoped Sessions, Signed Archives And Digest Verification In Code</title>
      <link>https://www.braiviq.com/playbook/mcp-tool-supply-chain-security-scoped-sessions-signed-skill-archives-digest-verification-code-2026</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/mcp-tool-supply-chain-security-scoped-sessions-signed-skill-archives-digest-verification-code-2026</guid>
      <pubDate>Mon, 28 Sep 2026 09:00:00 GMT</pubDate>
      <category>AI Integration</category>
      <description>Agents no longer carry all their capabilities with them. They connect to MCP servers that expose tools, and they load skill archives that package instructions, scripts and resources - and in doing so they have acquired a software supply chain with exactly the attack surface of a package registry, with one difference: a compromised package runs code on a developer's machine, while a compromised tool or skill directs an agent that can act on your systems. Microsoft's Agent Framework 1.19.0 for Python shows where the industry is heading: MCP sessions scoped per invocation, requests authenticated to the correct identity and origin, skill archives restricted to a known format, and archive digests verified before anything loads. This playbook is a code-side guide to securing the agent supply chain: treating every MCP server and skill as untrusted until verified, pinning and verifying digests of skill archives, signing and verifying tool definitions, scoping sessions and credentials per invocation rather than per process, allow-listing servers and tools with least-privilege scopes, detecting tool-description drift - because a tool whose description changes is a prompt-injection vector - and auditing which server served which tool call, with a registry of approved servers and skills as the control point.</description>
      <media:content url="https://images.unsplash.com/photo-1563206767-5b18f218e8de?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Build For Agents, Not Screens: Agent Experience (AX) And Agent-First API Design In Code</title>
      <link>https://www.braiviq.com/playbook/build-for-agents-not-screens-agent-experience-ax-agent-first-api-design-code-2026-headless-mcp-skills</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/build-for-agents-not-screens-agent-experience-ax-agent-first-api-design-code-2026-headless-mcp-skills</guid>
      <pubDate>Sun, 27 Sep 2026 09:00:00 GMT</pubDate>
      <category>Agentic AI</category>
      <description>A number from this year's developer surveys should unsettle anyone who owns an API: 89% of developers now use generative AI in their daily work, but only 24% design their APIs with AI agents in mind. That gap is about to become expensive, because agents are becoming first-class users of software - calling APIs, reading documentation and executing tasks on behalf of people who never touch the interface. The biggest vendors have already moved: Salesforce's Headless 360 exposes its data, workflows and business logic as APIs, MCP tools and CLI commands rather than screens. MCP sits under the Linux Foundation. Agent Skills emerged as a standard early this year, and Cloudflare's discovery RFC landed weeks ago. Agent experience - AX - is now a discipline, and it is a superset of developer experience with harder requirements. This flagship playbook is the engineering: how an agent discovers what your system can do, how to design operations for autonomous callers who retry and parallelise, how to write errors an agent can recover from, how to authenticate and scope an agent identity, and how to migrate an existing API toward agent-first without breaking the humans still using it.</description>
      <media:content url="https://images.unsplash.com/photo-1537884944318-390069bb8665?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Inside LLM Inference Serving: Prefill, Decode, KV Cache, Continuous Batching, Speculative Decoding And Disaggregation - Explained For Senior Engineers</title>
      <link>https://www.braiviq.com/playbook/inside-llm-inference-serving-2026-prefill-decode-kv-cache-continuous-batching-speculative-decoding-disaggregation-senior-engineers</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/inside-llm-inference-serving-2026-prefill-decode-kv-cache-continuous-batching-speculative-decoding-disaggregation-senior-engineers</guid>
      <pubDate>Sat, 26 Sep 2026 09:00:00 GMT</pubDate>
      <category>Deployment &amp; Production</category>
      <description>Every senior engineer running AI in production pays for inference, but surprisingly few can explain what happens between a request arriving and tokens streaming back - and that layer decides your latency, your throughput and your bill. In 2026 the serving stack has matured into a recognisable end-state: vLLM or SGLang, paged attention with continuous batching, automatic prefix caching, an FP8 KV cache, speculative decoding with EAGLE-2, and prefill/decode disaggregation, with multi-tenant LoRA on top. Each of those is an answer to a specific physical problem in how transformers generate text. This educational deep-dive, for senior engineers and CTOs, walks the request path: why generation has two phases with opposite bottlenecks, why the KV cache is the resource everything fights over, how continuous batching and chunked prefill keep GPUs busy without starving anyone, when speculative decoding pays and when it does not, why the newest systems split prefill and decode onto different hardware, and how to reason about cost per token from first principles rather than from a price list.</description>
      <media:content url="https://images.unsplash.com/photo-1484557052118-f32bd25b45b5?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Britain Built The Evals Framework The World Uses: Inspect, The AI Security Institute, And Why UK Developers Should Be Proud - And Use It</title>
      <link>https://www.braiviq.com/playbook/britain-built-the-evals-framework-the-world-uses-inspect-aisi-2026-uk-developers-pro-uk-read</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/britain-built-the-evals-framework-the-world-uses-inspect-aisi-2026-uk-developers-pro-uk-read</guid>
      <pubDate>Sat, 26 Sep 2026 09:00:00 GMT</pubDate>
      <category>AI Strategy &amp; ROI</category>
      <description>There is a piece of AI infrastructure that laboratories, enterprises and researchers around the world run every day, and it was built by a British government body. Inspect - the open-source framework for frontier AI evaluations from the UK AI Security Institute, developed with Meridian Labs, MIT-licensed and written in Python - reached version 0.3.268 on PyPI on 22 September 2026, its 246th release since it was open-sourced in May 2024. Around it, Inspect Evals lists 171 benchmark implementations with more than 200 pre-built evaluations ready to run on any model, and a community registration process has been live since 8 May 2026. In a year when British technology stories have too often been about home-grown standards migrating to bodies abroad, this is the counterpoint: a UK institution that built, shipped, maintained and kept stewardship of a tool the world adopted. This educational, openly pro-UK read explains what Inspect is in code, why a UK-stewarded open evals standard matters for both sovereignty and safety, how a British engineering team should adopt it for its own agents and models, and where the honest caveats lie.</description>
      <media:content url="https://images.unsplash.com/photo-1505761671935-60b3a7427bad?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Building An Incremental Technical Indicator Engine In Code: Streaming RSI, MACD, Bollinger Bands And VWAP Without Recomputing The World</title>
      <link>https://www.braiviq.com/playbook/building-incremental-technical-indicator-engine-code-streaming-rsi-macd-bollinger-vwap-trading-charts</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/building-incremental-technical-indicator-engine-code-streaming-rsi-macd-bollinger-vwap-trading-charts</guid>
      <pubDate>Fri, 25 Sep 2026 09:00:00 GMT</pubDate>
      <category>Trading</category>
      <description>A live trading chart carries a dozen indicators - moving averages, RSI, MACD, Bollinger Bands, VWAP - and every one of them must update on every tick, on every timeframe, for every instrument on screen, without the chart stuttering and without the numbers drifting from what a reference calculation would give. The textbook definitions describe each indicator as a function over a whole price series. A production engine cannot afford to recompute a whole series each tick, so it must express every indicator as a stateful reducer that updates in constant time as new data arrives. That reframing is where most of the engineering lives, and getting it wrong produces the classic chart bugs: indicators that repaint, values that drift after hours of streaming, and signals on a forming bar that vanish when the bar closes. This playbook, from a team that specialises in trading charts, is a code-side account of building an incremental indicator engine: reducers with O(1) updates, warm-up periods, the forming-bar contract, chaining indicators without recomputation, multi-timeframe consistency, numerical determinism, and the testing that proves your streaming values match the reference.</description>
      <media:content url="https://images.unsplash.com/photo-1519241047957-be31d7379a5d?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>AI Trade Surveillance: What A Trading Firm's Dev Team Must Learn To Detect Spoofing And Layering On Streaming Order Data - With Alerts A Regulator Can Read</title>
      <link>https://www.braiviq.com/playbook/ai-trade-surveillance-trading-firm-dev-team-detect-spoofing-layering-streaming-order-data-explainable-alerts-code</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/ai-trade-surveillance-trading-firm-dev-team-detect-spoofing-layering-streaming-order-data-explainable-alerts-code</guid>
      <pubDate>Fri, 25 Sep 2026 09:00:00 GMT</pubDate>
      <category>Case Studies</category>
      <description>Every bank and trading firm wants AI in its trade surveillance and almost none has it: 89% say they want AI-enhanced surveillance, only 11% have it, around 70% are stuck in proof-of-concept or partial deployment, not one describes AI as fully embedded, and 22% admit their current infrastructure does not effectively manage market-abuse risk. The reason is not the models. Banks split almost evenly on the real blocker - data fragmented across silos, no standardised identifiers, and inconsistent quality - because surveillance is a data-engineering problem before it is a machine-learning one, and the market-abuse patterns that matter - spoofing, layering, wash trading, momentum ignition - are behavioural sequences that static thresholds cannot see. This playbook, from a team that builds trading technology, is a practical, code-side account of what a dev team must learn: reconstructing the full order lifecycle from streaming events with consistent identifiers, engineering the behavioural features that expose manipulation, layering rules, statistical baselines and sequence models, and - the part that decides whether the system is usable - producing every alert with an explainable evidence chain a compliance officer and a regulator can read.</description>
      <media:content url="https://images.unsplash.com/photo-1573495627361-d9b87960b12d?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Building Real-Time Voice Agents In Code: Speech-To-Speech Vs Cascaded Pipelines, Latency Budgets, Turn Detection And Barge-In</title>
      <link>https://www.braiviq.com/playbook/building-real-time-voice-agents-code-2026-speech-to-speech-vs-cascaded-latency-turn-detection-barge-in</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/building-real-time-voice-agents-code-2026-speech-to-speech-vs-cascaded-latency-turn-detection-barge-in</guid>
      <pubDate>Thu, 24 Sep 2026 09:00:00 GMT</pubDate>
      <category>AI Integration</category>
      <description>Voice is the interface where latency is the product. A text agent that takes two seconds to answer is fine. A voice agent that leaves two seconds of silence feels broken, talks over the caller, or gets interrupted and keeps going - and in 2026 the tooling to get this right has matured into two distinct architectures with different trade-offs. Cascaded pipelines chain speech-to-text, a language model and text-to-speech, giving control over each stage at the cost of accumulated latency. Native speech-to-speech models like the Gemini Live API - bidirectional WebSockets carrying 16kHz PCM audio, under 500 milliseconds without a separate ASR and TTS chain - and OpenAI's Realtime API collapse the pipeline into one model that hears and speaks. Around either sits the engineering that decides whether the agent feels natural: a latency budget of roughly 800 milliseconds to first audible response, voice activity detection, end-of-turn detection from models like LiveKit's turn detector, Pipecat Smart Turn and Deepgram Flux, barge-in that stops the agent the instant a user speaks, WebRTC or WebSocket transport, telephony integration, and tool calls that must not leave dead air. This playbook is the code-side guide to building voice agents that sound like they are listening.</description>
      <media:content url="https://images.unsplash.com/photo-1559523161-0fc0d8b38a7a?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Building A PII Detection And Redaction Pipeline In Code: Rules, NER, LLM Classification And Auditable Masking Before Anything Leaves The Building</title>
      <link>https://www.braiviq.com/playbook/building-pii-detection-redaction-pipeline-code-2026-ner-rules-llm-classification-auditable-masking-workflow-automation</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/building-pii-detection-redaction-pipeline-code-2026-ner-rules-llm-classification-auditable-masking-workflow-automation</guid>
      <pubDate>Wed, 23 Sep 2026 09:00:00 GMT</pubDate>
      <category>Workflow Automation</category>
      <description>Every UK business sends documents, messages and datasets across boundaries where personal data should not travel - to a supplier, to a model, to a customer who is not the subject, to an archive - and under UK GDPR a single unredacted record in the wrong place is a reportable breach. The workflow that prevents it is a PII detection and redaction pipeline, and in 2026 it is one of the highest-value automations a business can build, because the pieces have matured: deterministic rules for structured identifiers, named-entity recognition for names and addresses, and language-model classification for the contextual personal data that neither catches. This playbook is a code-side guide to building one properly: a layered detector where each layer catches what the others miss, confidence scoring that routes uncertain spans to a human rather than guessing, redaction strategies from irreversible masking to reversible tokenisation with a vault, per-field audit logs that prove what was masked and why, evaluation with precision and recall on labelled documents where a miss is a breach, and one pipeline that runs in both batch and streaming modes so the same protection applies to a nightly export and a live chat.</description>
      <media:content url="https://images.unsplash.com/photo-1593720213428-28a5b9e94613?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>When There Is No API: Computer-Use Agents Are The New Integration Layer For Legacy Systems - How To Architect Them In Code</title>
      <link>https://www.braiviq.com/playbook/when-there-is-no-api-computer-use-agents-new-integration-layer-legacy-systems-2026-code-architecture</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/when-there-is-no-api-computer-use-agents-new-integration-layer-legacy-systems-2026-code-architecture</guid>
      <pubDate>Tue, 22 Sep 2026 09:00:00 GMT</pubDate>
      <category>AI Integration</category>
      <description>Every enterprise has them: the legacy portal with no API, the native broker terminal, the Windows-only ERP client, the desktop system that still runs a critical process and cannot be replaced this decade. For twenty years the only ways to automate them were brittle screen-scraping RPA or a human. In 2026 that changed decisively: computer-use agents - agents that operate software through its human interface, observing the screen and producing clicks and keystrokes - moved from research demo to production primitive. Computer-using agents in Microsoft Copilot Studio are now generally available, Windows 365 for Agents gives agents governed desktop and browser environments at enterprise scale, and a whole infrastructure layer of browser-agent fleets (Browserbase, Steel, Kernel, Anchor, Hyperbrowser) ships with observability and replay. This flagship playbook, for senior engineers and architects, is a code-side guide to using computer use as an integration layer: how the observe-plan-act loop works, why a browser agent is the right default primitive with native-desktop reach added only where needed, how to combine deterministic scripting with model-driven action, and the access-control discipline that stops an agent with a mouse becoming an unbounded actor.</description>
      <media:content url="https://images.unsplash.com/photo-1537432376769-00f5c2f4c8d2?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Stop Parsing JSON With Regex: Structured Outputs And Constrained Decoding In Production - A Senior Engineer's Guide</title>
      <link>https://www.braiviq.com/playbook/structured-outputs-constrained-decoding-production-2026-stop-parsing-json-regex-senior-engineers-guide</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/structured-outputs-constrained-decoding-production-2026-stop-parsing-json-regex-senior-engineers-guide</guid>
      <pubDate>Tue, 22 Sep 2026 09:00:00 GMT</pubDate>
      <category>RAG &amp; LLM Engineering</category>
      <description>The boundary between an AI demo and a system other code can depend on is a single question: can you get reliably structured data out of the model? Every team has lived the failure - a prompt that begs for JSON, a regex that fishes it out of prose, a parser that crashes at 2am on a stray trailing comma. In 2026 this is a solved problem for teams that know the tooling, and the solution has gone viral among practitioners: native structured outputs backed by constrained decoding, where a JSON Schema is compiled into a finite-state machine that masks invalid tokens at generation time, so the output is schema-valid by construction rather than by luck. The trade-offs are now measured - prompt-only output fails 5-10% of the time, JSON mode 2-5%, provider structured outputs under 0.1%, and FSM-constrained decoding achieves 100% compliance - and so are the hidden costs, from degraded content quality under tight constraints to truncation under token limits. This educational deep-dive, for senior developers and CTOs, explains how constrained decoding works, how the providers differ, the three-layer architecture that makes it production-grade, and how to design schemas that are both machine-enforceable and model-friendly.</description>
      <media:content url="https://images.unsplash.com/photo-1515879218367-8466d910aaa4?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Britain Is Opening Everything: Smart Data Schemes, The FCA's Open Finance Roadmap, And What UK Developers Get To Build - A Pro-UK Read</title>
      <link>https://www.braiviq.com/playbook/britain-opening-everything-smart-data-schemes-fca-open-finance-roadmap-what-uk-developers-build-pro-uk-2026</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/britain-opening-everything-smart-data-schemes-fca-open-finance-roadmap-what-uk-developers-build-pro-uk-2026</guid>
      <pubDate>Tue, 22 Sep 2026 09:00:00 GMT</pubDate>
      <category>AI Strategy &amp; ROI</category>
      <description>Britain invented open banking, proved it works at national scale, and is now doing something no other major economy has attempted: extending the model to the whole economy. The Data (Use and Access) Act 2025 gives the government the legal power to mandate Smart Data schemes in any sector - finance, energy, telecoms, transport, retail, home buying - requiring the firms that hold customer and business data to share it, on the customer's instruction, through specified APIs and standards. The FCA published its open finance vision on 14 April 2026 as a roadmap to 2030. A discussion paper on the first open finance scheme follows in Q4 2026, with SME credit and mortgages as the priority areas, and a cross-sector Guidebook of binding standards is due by early 2027. For developers this is not policy background - it is a specification of what becomes buildable when data flows by right rather than by scraping or bilateral deal. This educational, openly pro-UK read explains what Smart Data schemes are in technical terms, why Britain's mandate-plus-standards model is the right design, the honest caveats, and the AI-native products UK engineers should be preparing to build.</description>
      <media:content url="https://images.unsplash.com/photo-1560472355-536de3962603?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Regression-Proof Your Agents: Why Agent Evaluation In CI/CD Is 2026's Most Under-Built Layer - And How To Build It In Code</title>
      <link>https://www.braiviq.com/playbook/agent-evaluation-in-ci-cd-2026-regression-proof-ai-agents-github-actions-span-level-evals-code</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/agent-evaluation-in-ci-cd-2026-regression-proof-ai-agents-github-actions-span-level-evals-code</guid>
      <pubDate>Tue, 22 Sep 2026 09:00:00 GMT</pubDate>
      <category>Deployment &amp; Production</category>
      <description>Every serious engineering team gates releases on tests. Almost none of them gate AI agent releases on anything that would actually catch an agent breaking - because a unit test cannot tell you that your agent now picks the wrong tool, passes malformed arguments, hands off to the wrong sub-agent, or quietly takes an unsafe path. In 2026 this became the most under-built and most consequential layer in the agent stack: Gartner's Market Guide for AI Evaluation and Observability Platforms forecasts that 60% of software engineering teams will be using these platforms by 2028, and AWS has published a reference implementation that runs agent evaluations inside GitHub Actions and fails the job when scores fall below a configured threshold. This flagship playbook, for senior engineers and CTOs, is a code-side guide to building agent evaluation into your CI/CD pipeline: what an agent regression actually is, why span-level evaluation of the whole workflow is the unit that matters, how to build an eval set and threshold gate that blocks bad releases, and how to keep it from becoming a flaky, ignored bottleneck.</description>
      <media:content url="https://images.unsplash.com/photo-1555066931-bf19f8fd1085?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Building A Bar Aggregation Engine In Code: From Raw Ticks To Time, Tick, Volume And Renko Bars For Multi-Timeframe Charts</title>
      <link>https://www.braiviq.com/playbook/building-bar-aggregation-engine-code-ticks-to-time-tick-volume-renko-bars-multi-timeframe-trading-charts</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/building-bar-aggregation-engine-code-ticks-to-time-tick-volume-renko-bars-multi-timeframe-trading-charts</guid>
      <pubDate>Mon, 21 Sep 2026 09:00:00 GMT</pubDate>
      <category>Trading</category>
      <description>Every candle a trader looks at is manufactured. Markets do not emit one-minute bars. They emit a torrent of individual ticks - trades and quotes with prices, sizes and timestamps - and somewhere between the feed and the chart an aggregation engine turns that torrent into the open-high-low-close bars that every chart, indicator and pattern detector consumes. Get it right and nobody notices. Get it subtly wrong - a bar boundary misaligned by a timezone, a late tick dropped, a higher timeframe that disagrees with the lower one it should be built from - and every chart in the building shows a false market. This is a domain we specialise in, and this playbook is a code-side account of how a bar aggregation engine is actually built: the tick-to-bar state machine, time bars with session and boundary handling, tick, volume, range and Renko bars that close on activity rather than the clock, deriving higher timeframes from lower ones so every timeframe agrees, the forming-candle contract with the chart, the hard problems of late and out-of-order data, and the correctness discipline - deterministic replay and property tests - that lets you trust every bar on screen.</description>
      <media:content url="https://images.unsplash.com/photo-1639754390580-2e7437267698?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>The Mainframe Problem: What A Bank's Dev Team Must Learn To Modernise COBOL With AI Agents - Without A TSB-Style Meltdown</title>
      <link>https://www.braiviq.com/playbook/mainframe-problem-bank-dev-team-modernise-cobol-with-ai-agents-without-tsb-style-meltdown-code-2026</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/mainframe-problem-bank-dev-team-modernise-cobol-with-ai-agents-without-tsb-style-meltdown-code-2026</guid>
      <pubDate>Mon, 21 Sep 2026 09:00:00 GMT</pubDate>
      <category>Case Studies</category>
      <description>Behind the sleek apps of most banks and trading firms sits a fact the industry does not advertise: the ledgers, settlement and core processing still run on decades-old COBOL on mainframes, maintained by a shrinking pool of specialists, expensive to license and nearly impossible to change quickly. For thirty years modernisation was too risky to attempt at scale. In 2026 AI coding agents changed the calculus - Morgan Stanley has modernised more than 17 million lines of COBOL, Natural and Perl using an in-house generative-AI platform, saving developers over a million hours, and tools like IBM watsonx Code Assistant for Z and Sourcegraph Cody now specialise in exactly this. But the counter-example every dev team must study is TSB's 2018 single-event migration, which locked roughly 1.9 million customers out of their accounts and cost on the order of £330 million. This playbook, from a team that builds financial systems, is a practical, code-side account of what a bank's dev team must learn: recovering intent from undocumented code with agents that explain before they translate, building a behavioural test harness and golden datasets before touching anything, verifying equivalence with data-level reconciliation, migrating by the strangler-fig pattern with dual-running - and never, ever doing the big-bang cutover.</description>
      <media:content url="https://images.unsplash.com/photo-1550745165-9bc0b252726f?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Agent Interoperability In Code: The A2A Protocol, Agent Cards And How Agents From Different Vendors Actually Talk To Each Other</title>
      <link>https://www.braiviq.com/playbook/agent-interoperability-in-code-a2a-protocol-agent-cards-cross-vendor-agent-communication-2026</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/agent-interoperability-in-code-a2a-protocol-agent-cards-cross-vendor-agent-communication-2026</guid>
      <pubDate>Mon, 21 Sep 2026 09:00:00 GMT</pubDate>
      <category>Agentic AI</category>
      <description>The first wave of enterprise agents was built one at a time, each a closed world. The second wave has a different problem: a typical large organisation now runs agents from its CRM vendor, its service-desk vendor, its own engineering team and a handful of specialist providers, and none of them can hand work to each other. Making agents interoperate - discover one another, delegate tasks, exchange results, across vendors and frameworks - has become the defining infrastructure question of agentic systems, and the Agent2Agent protocol (A2A), now open-governed under the Linux Foundation and shipping as enterprise-grade in frameworks like CrewAI, is the emerging standard for it. This playbook is a code-side guide to A2A and to architecting a multi-vendor agent estate: agent cards published at a well-known URL for discovery, the task lifecycle as the unit of collaboration, messages and artifacts, streaming and push notifications for long-running work, how A2A complements MCP rather than competing with it, and the registry, delegation, authentication and governance patterns that stop cross-agent handoffs becoming an unaudited chain.</description>
      <media:content url="https://images.unsplash.com/photo-1618005182384-a83a8bd57fbe?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>The SLM Shift: Why Senior Engineers Are Right-Sizing Models In 2026 - A 27B Model On One GPU, 10-30x Cheaper, Behind Your Own Firewall</title>
      <link>https://www.braiviq.com/playbook/small-language-models-right-sizing-2026-single-gpu-on-prem-10x-cheaper-senior-engineers-guide-code</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/small-language-models-right-sizing-2026-single-gpu-on-prem-10x-cheaper-senior-engineers-guide-code</guid>
      <pubDate>Mon, 21 Sep 2026 09:00:00 GMT</pubDate>
      <category>RAG &amp; LLM Engineering</category>
      <description>For two years the default architecture for anything AI was to call the biggest frontier model available for every task and pay whatever it cost. In 2026 the senior engineers getting the best results have quietly stopped doing that, and the reason is a shift that has gone viral among practitioners: small language models are now good enough, cheap enough and local enough to be the right default for most enterprise workloads. NVIDIA's newly announced Qwen3.8-27B is sized to run on a single GPU for real coding work with local files and tools. A 7-billion-parameter model is 10-30 times cheaper to serve than a 70-175 billion one. Enterprises report cutting inference costs by up to 75% and, for high-volume repetitive tasks, up to 90%, and a model that runs on a laptop or behind your own firewall removes an entire class of data-privacy and compliance problems. This educational deep-dive, for senior developers and CTOs, explains what changed, when a small model is the right choice and when it is not, and how to architect for right-sizing in code.</description>
      <media:content url="https://images.unsplash.com/photo-1580927752452-89d86da3fa0a?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Intelligent Document Processing Pipelines In Code: Ingest, Classify, Extract, Validate, And Route Only The Doubt To Humans</title>
      <link>https://www.braiviq.com/playbook/intelligent-document-processing-pipeline-code-2026-ingest-extract-validate-human-review-workflow-automation</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/intelligent-document-processing-pipeline-code-2026-ingest-extract-validate-human-review-workflow-automation</guid>
      <pubDate>Sun, 20 Sep 2026 09:00:00 GMT</pubDate>
      <category>Workflow Automation</category>
      <description>The highest-volume automation opportunity in most enterprises is not exotic - it is documents: invoices, purchase orders, KYC packs, contracts, claims, bank statements, arriving by email, upload and scan in every format imaginable, and still processed largely by people re-keying fields into systems. For years intelligent document processing promised to fix this and delivered brittle templates that broke on every new layout. In 2026 the stack finally makes end-to-end document automation reliable, because the pieces matured together: layout-aware extraction, constrained structured outputs that guarantee a schema, small models cheap enough for volume, and workflow engines with real human-in-the-loop checkpoints. This playbook is a code-side guide to architecting an intelligent document processing pipeline that holds up in production: ingest and normalisation, classification that routes each document to the right schema, LLM extraction against a per-document-type schema, deterministic validation that catches what models cannot, confidence scoring that sends only the doubtful fields to a human rather than whole documents, idempotent posting to downstream systems, and the per-field auditability and feedback loop that make the pipeline both trustworthy and self-improving.</description>
      <media:content url="https://images.unsplash.com/photo-1521791055366-0d553872125f?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Britain's Cyber Bill Puts The Duty On You, The AI Deployer - Not The Model Vendor: What UK Dev Teams Must Build - A Pro-UK Read</title>
      <link>https://www.braiviq.com/playbook/uk-cyber-security-resilience-bill-2026-duty-on-ai-deployers-not-vendors-what-uk-dev-teams-must-build-pro-uk</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/uk-cyber-security-resilience-bill-2026-duty-on-ai-deployers-not-vendors-what-uk-dev-teams-must-build-pro-uk</guid>
      <pubDate>Sun, 20 Sep 2026 09:00:00 GMT</pubDate>
      <category>AI Strategy &amp; ROI</category>
      <description>On 1 September 2026 the UK's Cyber Security and Resilience Bill entered Committee stage, and one decision inside it should reshape how every British engineering team thinks about AI in production. The government explicitly rejected proposals from the House of Lords to bring AI vendors and frontier-model developers within the Bill's scope. The cybersecurity minister's reasoning was blunt: regulating the vendors would not stop hostile actors misusing their products. Instead, the Bill targets the organisations that deploy and operate AI inside essential and critical services - and model security is handled separately through the AI Security Institute, which tests models with vendors before release. For developers, this is the crucial and under-reported point: in Britain, the legal duty for AI systems running in critical infrastructure lands on the deployer, on you, not on the lab that trained the model. This educational, openly pro-UK read explains what the Bill does, why the UK's operator-focused design is the sensible one, and the concrete security engineering a UK dev team must now build into the AI it runs.</description>
      <media:content url="https://images.unsplash.com/photo-1618044619888-009e412ff12a?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Building An AI Candlestick Pattern Recognition Engine In Code: From Rule-Based Detectors To ML Overlays On The Chart</title>
      <link>https://www.braiviq.com/playbook/building-ai-candlestick-pattern-recognition-engine-code-rule-based-detectors-ml-overlays-trading-charts</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/building-ai-candlestick-pattern-recognition-engine-code-rule-based-detectors-ml-overlays-trading-charts</guid>
      <pubDate>Sat, 19 Sep 2026 09:00:00 GMT</pubDate>
      <category>Trading</category>
      <description>Every serious charting platform now detects patterns for you - TradingView recognises 44 candlestick and 53 chart patterns automatically, TrendSpider spots over a hundred - and in 2026 a new generation of AI charting engines goes further, sending live candle data to machine-learning endpoints and rendering the predictions straight onto the chart as overlays. Underneath that convenient surface sits a genuinely interesting engineering problem that a team specialising in trading charts, as we do, has to solve properly: how do you turn a stream of OHLC bars into reliable, fast, explainable pattern detections, and how do you layer machine learning on top without producing a confident engine that hallucinates hammers? This playbook is a code-side tour of building a candlestick pattern recognition engine: the OHLC predicates that define classical patterns, why zero-dependency rule-based detection is the right foundation (and why a library like the no_std Rust candlestick crate exists), how ML classifiers add adaptive detection on top, the proxy architecture that feeds candles to a model and renders mark overlays back, and the correctness discipline that keeps the whole thing honest.</description>
      <media:content url="https://images.unsplash.com/photo-1614028674026-a65e31bfd27c?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>From Overnight Batch To Intraday: What An Investment Bank's Dev Team Must Learn To Build A Real-Time Risk Engine On Top Of Legacy</title>
      <link>https://www.braiviq.com/playbook/overnight-batch-to-intraday-risk-engine-investment-bank-dev-team-real-time-var-legacy-modernization-code</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/overnight-batch-to-intraday-risk-engine-investment-bank-dev-team-real-time-var-legacy-modernization-code</guid>
      <pubDate>Sat, 19 Sep 2026 09:00:00 GMT</pubDate>
      <category>Case Studies</category>
      <description>Ask a developer on an investment bank's risk technology team about the job they dread and a common answer is the overnight batch: the sprawling, fragile, hours-long run that computes the firm's Value-at-Risk and exposures once a day from data scattered across a dozen legacy systems - and that is increasingly the wrong answer to the wrong question. In 2026 the moments that generate the most consequential risk decisions - a central-bank surprise, an options-expiry cascade, a credit event, a geopolitical shock - compress the decision window to intraday or real time, and a number computed last night is a blind spot. Banks are re-architecting from batch to real-time engines, and they are doing it on top of legacy platforms that consume an estimated 70% of financial-services IT budgets and $350 billion a year industry-wide, and whose query patterns simply do not map onto live risk. This playbook is a practical, code-side account of what a bank's dev team must learn to make that transition: unifying fragmented risk data into a cross-asset model, streaming positions and prices instead of batching them, computing risk incrementally, using GPUs for the heavy analytics, and modernising incrementally without a big-bang rewrite that never ships.</description>
      <media:content url="https://images.unsplash.com/photo-1509228468518-180dd4864904?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>The AI Gateway Pattern: Routing, Fallback, Caching And Cost Control Across Multiple Models - The Layer Every Production AI System Now Needs</title>
      <link>https://www.braiviq.com/playbook/ai-gateway-pattern-code-2026-model-routing-fallback-caching-cost-control-multi-model-architecture</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/ai-gateway-pattern-code-2026-model-routing-fallback-caching-cost-control-multi-model-architecture</guid>
      <pubDate>Fri, 18 Sep 2026 09:00:00 GMT</pubDate>
      <category>AI Integration</category>
      <description>Look at the open-source projects trending among AI developers in the third week of September 2026 and a pattern jumps out: proxy gateways. Projects like OmniRoute and CLIProxyAPI are climbing the charts because teams have discovered that once you run more than one model - a frontier API for hard tasks, a cheap small model for volume, a local model for private data - every application that calls them directly becomes a tangle of per-provider code, duplicated retry logic, unmanaged spend and no single place to see what is happening. The AI gateway is the answer: a single proxy layer between your applications and every model they use, which owns routing, fallback, caching, rate limiting, cost accounting, credential management and observability, exactly as an API gateway does for microservices. This playbook is a code-side guide to the pattern: what a gateway is responsible for, how routing and fallback are designed, where caching genuinely pays, how to make cost visible and enforceable per team and per task, and how to introduce a gateway into an estate that already calls models everywhere.</description>
      <media:content url="https://images.unsplash.com/photo-1591370874773-6702e8f12fd8?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Agent Skills As Composable Workflow Units: How To Package Automation Into Reusable, Versioned, Testable Capabilities Your Agents Load On Demand</title>
      <link>https://www.braiviq.com/playbook/agent-skills-composable-workflow-automation-units-2026-packaging-reusable-agent-capabilities-code</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/agent-skills-composable-workflow-automation-units-2026-packaging-reusable-agent-capabilities-code</guid>
      <pubDate>Fri, 18 Sep 2026 09:00:00 GMT</pubDate>
      <category>Workflow Automation</category>
      <description>A quiet shift in how automation is built has become one of the most-starred trends in AI open source this September: agent skills. Instead of hand-writing every workflow as a monolithic prompt or a bespoke script, teams are packaging discrete capabilities - the instructions, scripts, resources and tool bindings needed to do one job well - into self-contained skills that any agent can discover and load on demand, with community catalogues like awesome-claude-skills growing fast and the emerging stack now described as skills plus proxy gateways plus local retrieval plus lightweight agents. For anyone architecting workflow automation, this is the unit of reuse the field has been missing: the difference between a pile of one-off automations and a library of composable, versioned, testable building blocks. This playbook is a code-side guide to designing agent skills as workflow units: what a skill is and is not, how to scope one so it composes, how to version and test it like software, how to bind it to tools and permissions safely, and how a catalogue of skills becomes the architecture of an automation platform rather than a collection of scripts.</description>
      <media:content url="https://images.unsplash.com/photo-1523961131990-5ea7c61b2107?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Agent Memory Is The New Production Layer: How To Architect What Your AI Agents Remember - In Code</title>
      <link>https://www.braiviq.com/playbook/ai-agent-memory-the-new-production-layer-2026-architecture-mem0-letta-zep-code-guide</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/ai-agent-memory-the-new-production-layer-2026-architecture-mem0-letta-zep-code-guide</guid>
      <pubDate>Thu, 17 Sep 2026 09:00:00 GMT</pubDate>
      <category>Agentic AI</category>
      <description>Eighteen months ago, 'agent memory' was not a category anyone shipped - you stuffed the last few messages back into the prompt and called it memory. In 2026 it is a distinct, production-grade engineering layer with its own frameworks (Mem0, Letta, Zep, and a field of others), its own benchmarks, and its own hard trade-offs, because the teams building agents that work over days and thousands of interactions discovered the same thing: an agent with no real memory is a brilliant amnesiac, re-learning the user, the task and the context every single session. This flagship playbook is for senior engineers and CTOs architecting the memory layer for real: what agent memory actually is beyond the chat history, the types of memory a serious agent needs (working, episodic, semantic, procedural), how the leading frameworks approach it, and the engineering decisions - what to store, when to retrieve, when to forget - that separate an agent that genuinely remembers from one that just has a long transcript.</description>
      <media:content url="https://images.unsplash.com/photo-1580894908361-967195033215?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Agentic RAG In Code: Moving Retrieval Inside The Agent Loop - A Senior Engineer's Guide To 2026's Production Pattern</title>
      <link>https://www.braiviq.com/playbook/agentic-rag-in-code-2026-self-rag-flare-graphrag-retrieval-inside-the-loop-senior-engineers-guide</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/agentic-rag-in-code-2026-self-rag-flare-graphrag-retrieval-inside-the-loop-senior-engineers-guide</guid>
      <pubDate>Wed, 16 Sep 2026 09:00:00 GMT</pubDate>
      <category>RAG &amp; LLM Engineering</category>
      <description>Classic RAG - retrieve some documents, stuff them in the prompt, generate an answer - was the pattern that made LLMs useful on private data, and it is now quietly obsolete for anything serious. The reason is simple: it retrieves once, blindly, before the model has reasoned about the question at all, so a vague query fetches vague context and the answer is only as good as that single guess. In 2026 the production pattern is agentic RAG, which flips the relationship: instead of retrieval happening in front of the model, retrieval happens inside the agent loop, as a tool the model can decide to use - it can rewrite a bad query, retrieve again, inspect what it got, decide whether it has enough evidence, and stop early or dig deeper. This educational deep-dive, for senior engineers and CTOs, explains what agentic RAG actually is, the patterns that define it (Self-RAG, FLARE, query rewriting, reranking, GraphRAG), and how to think about building retrieval that reasons.</description>
      <media:content url="https://images.unsplash.com/photo-1526498460520-4c246339dccb?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Securing The AI Coding Pipeline: What Engineering Leaders Must Do When Agents Write The Code</title>
      <link>https://www.braiviq.com/playbook/securing-the-ai-coding-pipeline-2026-when-agents-write-the-code-supply-chain-review-gates-code</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/securing-the-ai-coding-pipeline-2026-when-agents-write-the-code-supply-chain-review-gates-code</guid>
      <pubDate>Wed, 16 Sep 2026 09:00:00 GMT</pubDate>
      <category>Deployment &amp; Production</category>
      <description>In 2026, a large and growing share of the code shipped by professional teams was not typed by a human - it was written by an AI coding agent and reviewed (sometimes) by a person. That is a genuine productivity revolution, and it has quietly opened one of the most under-managed risk surfaces in software: when agents write the code, the old assumptions behind code security - that a human author understood every line, that dependencies were chosen deliberately, that a review caught what mattered - no longer hold by default. AI agents hallucinate plausible-looking package names that attackers now pre-register, follow insecure patterns at scale, and generate far more code than humans can carefully review. This playbook, for engineering leaders and senior developers, is a practical guide to securing the AI coding pipeline: the new risks that arrive when agents write code, and the concrete controls - review gates, dependency verification, scanning, and least-privilege agents - that let you keep the productivity without inheriting the danger.</description>
      <media:content url="https://images.unsplash.com/photo-1590650516494-0c8e4a4dd67e?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Building Execution Algorithms In Code: VWAP, TWAP, POV And Implementation Shortfall From The Ground Up</title>
      <link>https://www.braiviq.com/playbook/building-execution-algorithms-in-code-vwap-twap-pov-implementation-shortfall-child-order-scheduling-trading</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/building-execution-algorithms-in-code-vwap-twap-pov-implementation-shortfall-child-order-scheduling-trading</guid>
      <pubDate>Tue, 15 Sep 2026 09:00:00 GMT</pubDate>
      <category>Trading</category>
      <description>When an institution needs to buy a million shares, it does not send a single order - that would move the market against itself and pay a fortune in impact. Instead it hands the order to an execution algorithm that slices it into many small child orders released into the market over time according to a strategy. Nearly every institutional order today is routed through one of these, and building them well is a specialised, high-stakes corner of trading engineering that most developers never see. This playbook, from a team that specialises in trading systems, is a code-side tour of the core execution algorithms - VWAP, TWAP, POV (percent of volume) and implementation shortfall - what each one actually does, how the child-order scheduler at the heart of them works, and the engineering that separates an algorithm that quietly saves money on every order from one that leaks it. It is about the software of best execution: how you turn a big parent order into a stream of small ones, intelligently.</description>
      <media:content url="https://images.unsplash.com/photo-1612010167108-3e6b327405f0?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>The Backtesting Trap: What A Quant Dev Team Must Learn So Their Strategy Does Not Die In Production</title>
      <link>https://www.braiviq.com/playbook/the-backtesting-trap-quant-dev-team-look-ahead-bias-realistic-fills-slippage-market-impact-code-2026</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/the-backtesting-trap-quant-dev-team-look-ahead-bias-realistic-fills-slippage-market-impact-code-2026</guid>
      <pubDate>Tue, 15 Sep 2026 09:00:00 GMT</pubDate>
      <category>Case Studies</category>
      <description>Every quantitative trading firm runs on its backtesting engine - the software that replays historical market data to test whether a strategy would have made money. It is the single most important research tool a quant team has, and it is also the single most dangerous, because a backtest that is subtly wrong does not fail loudly. It produces a beautiful, confident equity curve for a strategy that will lose money the moment it meets a real market. This is the backtesting trap, and learning to avoid it is one of the hardest and highest-stakes things a quant dev team must master. This playbook, from a team that specialises in trading systems, is a practical, code-side account of why backtests lie: look-ahead bias, survivorship bias, unrealistic fills, ignored slippage and market impact, and overfitting - the specific ways a backtesting engine flatters a strategy - and the engineering discipline (point-in-time data, realistic execution modelling, walk-forward validation) that makes a backtest something you can actually trust.</description>
      <media:content url="https://images.unsplash.com/photo-1620325867502-221cfb5faa5f?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>What The UK's New Automated-Decision Rules Mean If You Build AI That Decides: DUAA 2025, Articles 22A-22D - A Developer's Pro-UK Read</title>
      <link>https://www.braiviq.com/playbook/uk-automated-decision-rules-duaa-2025-articles-22a-22d-what-they-mean-developers-building-ai-pro-uk</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/uk-automated-decision-rules-duaa-2025-articles-22a-22d-what-they-mean-developers-building-ai-pro-uk</guid>
      <pubDate>Tue, 15 Sep 2026 09:00:00 GMT</pubDate>
      <category>AI Strategy &amp; ROI</category>
      <description>While much of the AI world argues about hypothetical future regulation, the UK quietly changed the actual law that governs any developer building AI which makes decisions about people - and most engineers have not noticed. Since 5 February 2026, the Data (Use and Access) Act 2025 has replaced the old, restrictive Article 22 of the UK GDPR with new Articles 22A to 22D, which make solely automated decisions about individuals lawful in far more circumstances than before - provided you build in specific, documented safeguards. For developers, this is unusually good news wrapped in real obligations: Britain has chosen a pragmatic, pro-innovation path that lets you ship automated decisioning, but only if you engineer transparency, human review and the right to contest into the system from the start. This educational, openly pro-UK read explains what actually changed, what the safeguards mean in code and architecture, and why the UK's approach is a sensible one for the developers who have to build under it.</description>
      <media:content url="https://images.unsplash.com/photo-1499750310107-5fef28a66643?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Beyond The Chatbox: Building Generative Agent Interfaces That Show Reasoning, State And Trust - In Code</title>
      <link>https://www.braiviq.com/playbook/generative-agent-ui-beyond-the-chatbox-2026-building-agent-interfaces-in-code-state-trust-approval</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/generative-agent-ui-beyond-the-chatbox-2026-building-agent-interfaces-in-code-state-trust-approval</guid>
      <pubDate>Tue, 15 Sep 2026 09:00:00 GMT</pubDate>
      <category>AI Integration</category>
      <description>For three years, the interface to almost every AI system was the same: a text box and a scrolling stream of messages. The chatbox was a brilliant way to make LLMs accessible, and it is now the single biggest thing holding agent products back, because an autonomous agent that plans, calls tools, takes actions and runs for minutes is fundamentally the wrong thing to represent as a wall of chat text. In 2026 a clear movement emerged - captured in frameworks like Wavespace's 'Beyond the Chatbox' - to replace the single text stream with generative UI: interfaces that show the agent's reasoning, make its state legible, give explicit trust cues, and put human approval checkpoints exactly where consequential actions happen. This playbook, for engineers building agent products, is a code-side guide to why the chatbox fails for agents and how to design and build interfaces that make an autonomous agent understandable, trustworthy and controllable.</description>
      <media:content url="https://images.unsplash.com/photo-1633355444132-695d5876cd00?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>The Managed Agent Harness Has Arrived: What OpenAI's Agents API, LangGraph 1.2 And CrewAI A2A Mean For How You Architect Production Agents In Code</title>
      <link>https://www.braiviq.com/playbook/openai-agents-api-managed-agent-harness-2026-architecting-production-agents-code-build-vs-buy-runtime</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/openai-agents-api-managed-agent-harness-2026-architecting-production-agents-code-build-vs-buy-runtime</guid>
      <pubDate>Mon, 14 Sep 2026 09:00:00 GMT</pubDate>
      <category>Agentic AI</category>
      <description>For two years, every team building production agents wrote the same unglamorous plumbing by hand: the control loop that calls the model, executes tools and feeds results back, the logic that compacts context when a task runs long, the coordination between sub-agents, the crash recovery that lets a half-finished task resume instead of starting over. In September 2026 that plumbing became a product. OpenAI's Agents API entered public beta as a managed harness handling session orchestration, context compaction across long tasks, sub-agent coordination, lazy tool loading and crash recovery - with no fee beyond tokens and tool usage - while LangGraph passed 1.2 with durable execution and CrewAI made its agent-to-agent integration enterprise-grade. This flagship playbook is for senior engineers and CTOs deciding how to architect production agents now that the runtime layer is something you can buy: what a managed agent harness actually is, what it does and does not solve, and how to make the build-versus-buy call in code.</description>
      <media:content url="https://images.unsplash.com/photo-1517430816045-df4b7de11d1d?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>MCP Just Went Stateless: Architecting Remote Model Context Protocol Servers As Ordinary HTTP Workloads</title>
      <link>https://www.braiviq.com/playbook/mcp-goes-stateless-2026-07-28-spec-architecting-remote-model-context-protocol-servers-http-workloads-code</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/mcp-goes-stateless-2026-07-28-spec-architecting-remote-model-context-protocol-servers-http-workloads-code</guid>
      <pubDate>Sun, 13 Sep 2026 09:00:00 GMT</pubDate>
      <category>AI Integration</category>
      <description>The Model Context Protocol has become the universal connector between AI agents and the systems they need to reach - 97 million monthly SDK downloads and over 10,000 public servers in production by 2026 - but until recently, deploying a remote MCP server at scale was awkward because the protocol assumed a stateful, long-lived connection between client and server. The 2026-07-28 specification changed that decisively: MCP evolved into a stateless architecture in which a remote MCP server is no different from any other HTTP workload - cacheable, routable, horizontally scalable, and deployable on exactly the infrastructure you already run your APIs on. This playbook is an engineering-grade guide to what stateless MCP actually means in code, the new patterns it introduced (Tasks, subscriptions, progress notifications, and the Multi Round-Trip Requests pattern that replaced server-initiated requests), and how to architect a remote MCP server that scales like the rest of your web tier.</description>
      <media:content url="https://images.unsplash.com/photo-1667984390527-850f63192709?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Context Engineering In Code: How Senior Engineers Actually Build The Context Window In 2026</title>
      <link>https://www.braiviq.com/playbook/context-engineering-in-code-2026-how-senior-engineers-build-the-context-window-beyond-prompt-engineering</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/context-engineering-in-code-2026-how-senior-engineers-build-the-context-window-beyond-prompt-engineering</guid>
      <pubDate>Sun, 13 Sep 2026 09:00:00 GMT</pubDate>
      <category>RAG &amp; LLM Engineering</category>
      <description>Context engineering became the load-bearing AI skill of 2026 after Andrej Karpathy and Shopify's Tobi Lutke gave a name to what expert builders were already doing - but most of the discussion has stayed at the level of slogans (context beats prompting, quality of what the model sees matters most). This educational deep-dive is for senior engineers and CTOs who need the level below the slogan: what context engineering actually is as an engineering discipline, and how you build the context window in code. It covers the anatomy of a well-engineered context, the retrieval and assembly decisions that make or break it, the hard problem of managing a finite window on long-running tasks (compaction, summarisation, pruning tool results), and why in agentic systems the tools an agent can reach are themselves context. If you are past the point of asking for a magic prompt and want the engineering underneath, this is the playbook.</description>
      <media:content url="https://images.unsplash.com/photo-1600267204091-5c1ab8b10c02?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Building A Real-Time Trading Chart Engine In Code: WebGL Candlesticks, Streaming Updates And The Render Loop</title>
      <link>https://www.braiviq.com/playbook/building-real-time-trading-chart-engine-code-webgl-candlesticks-streaming-updates-render-loop-trading-charts</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/building-real-time-trading-chart-engine-code-webgl-candlesticks-streaming-updates-render-loop-trading-charts</guid>
      <pubDate>Sat, 12 Sep 2026 09:00:00 GMT</pubDate>
      <category>Trading</category>
      <description>A trading chart looks simple and is one of the most demanding pieces of UI engineering there is: it must render tens of thousands of candlesticks, stay perfectly interactive under pan, zoom and crosshair, update on every tick from a live market without stutter, and never show a trader a price that is a frame behind the truth. In 2026 the toolkit for doing this well has matured - TradingView's lightweight-charts stripped charting down to a fast WebGL/Canvas engine, SciChart and LightningChart push WebGL/WebAssembly rendering further, and the patterns for real-time financial charting in the browser are now well understood. This playbook, from a team that specialises in trading systems, is an engineering-grade tour of how a real-time trading chart engine actually works in code: why charts use GPU rendering, how the render loop and data pipeline are structured, how streaming updates are applied without redrawing the world, and the subtle correctness and memory traps that make trading charts uniquely hard.</description>
      <media:content url="https://images.unsplash.com/photo-1560221328-12fe60f83ab8?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>The Market Data Firehose: What An Investment Bank's Dev Team Must Learn To Build A Low-Latency Feed Handler And Order Book In Code</title>
      <link>https://www.braiviq.com/playbook/market-data-firehose-investment-bank-dev-team-low-latency-feed-handler-order-book-code-fix-sbe-itch</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/market-data-firehose-investment-bank-dev-team-low-latency-feed-handler-order-book-code-fix-sbe-itch</guid>
      <pubDate>Sat, 12 Sep 2026 09:00:00 GMT</pubDate>
      <category>Case Studies</category>
      <description>Ask developers joining an investment bank or trading firm what surprises them most, and a common answer is the market data problem: the sheer, relentless volume of it, and how hard it is to consume correctly and fast. A single venue can push millions of incremental messages per second, and the firm's systems must reconstruct a live order book from that firehose without ever falling behind the market - because a stale or wrong book means bad prices, bad risk and bad fills. This is a genuine, high-stakes pain point, and the tech a dev team must learn to handle it well is specialised and largely invisible from outside the industry: binary protocols like SBE and FAST rather than human-readable FIX on the hot path, direct exchange feeds like ITCH and CME's MDP 3.0, order-book reconstruction on dedicated cores, and latency budgets measured in microseconds heading toward nanoseconds. This playbook is a practical, code-side account of what building a low-latency feed handler and order book actually demands.</description>
      <media:content url="https://images.unsplash.com/photo-1560732488-6b0df240254a?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Britain Invented MCP And Let It Go: The Case For A UK Sovereign Open-Source Foundation - A Developer's Pro-UK Read</title>
      <link>https://www.braiviq.com/playbook/britain-invented-mcp-let-it-go-uk-sovereign-open-source-foundation-developers-pro-uk-read-2026</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/britain-invented-mcp-let-it-go-uk-sovereign-open-source-foundation-developers-pro-uk-read-2026</guid>
      <pubDate>Fri, 11 Sep 2026 09:00:00 GMT</pubDate>
      <category>AI Strategy &amp; ROI</category>
      <description>Here is a fact that should sting any British developer: some of the foundational open-source AI infrastructure the whole industry now runs on was built in London - and its governance and stewardship migrated to US-based bodies, because Britain had no home to keep it. In July 2026, OpenUK made this concrete, calling on the government to create a British equivalent of the US Linux Foundation: a sovereign open-source foundation to hold publicly funded AI harnesses, code, standards and datasets so that IP and governance generated with UK money stop drifting overseas. It is a quietly important, genuinely pro-UK idea, and one that speaks directly to developers rather than to policy abstractions. This educational read - biased, openly, toward Britain doing better - explains what the proposal actually is, why open-source governance is a real form of sovereignty that compute and data centres alone do not provide, and why it matters for UK developers and the companies they build.</description>
      <media:content url="https://images.unsplash.com/photo-1610986603166-f78428624e76?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Durable, Crash-Safe Agent Workflows In Code: Architecting Long-Running Automation With LangGraph 1.2 And Checkpointing</title>
      <link>https://www.braiviq.com/playbook/durable-crash-safe-agent-workflows-code-langgraph-1-2-long-running-automation-checkpointing-2026</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/durable-crash-safe-agent-workflows-code-langgraph-1-2-long-running-automation-checkpointing-2026</guid>
      <pubDate>Fri, 11 Sep 2026 09:00:00 GMT</pubDate>
      <category>Workflow Automation</category>
      <description>The demos that make agents look magical run for thirty seconds. The automations that actually run a business run for hours, days, or indefinitely - a workflow that ingests a document, waits for a human approval, calls three systems, retries a flaky one, and resumes cleanly after the server it was running on is redeployed. Building automation that survives that reality is a distinct engineering discipline, and it has a name that went mainstream in 2026 as LangGraph passed its 1.2 milestone: durable execution. This playbook is a code-side guide to architecting long-running, crash-safe agent workflows: what durable execution actually means, how checkpointing lets a workflow resume exactly where it stopped instead of restarting and repeating side effects, how to build in human-in-the-loop pauses that can wait indefinitely, and the idempotency and state-design discipline that makes the whole thing trustworthy. If your automation has to be reliable, not just impressive, this is the layer that gets you there.</description>
      <media:content url="https://images.unsplash.com/photo-1667372393086-9d4001d51cf1?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Spec-Driven Development: Why 2026's Biggest Shift In Building With AI Is Writing The Spec, Not The Prompt</title>
      <link>https://www.braiviq.com/playbook/spec-driven-development-2026-write-the-spec-not-the-prompt-ai-coding-agents-playbook</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/spec-driven-development-2026-write-the-spec-not-the-prompt-ai-coding-agents-playbook</guid>
      <pubDate>Thu, 10 Sep 2026 09:00:00 GMT</pubDate>
      <category>Agentic AI</category>
      <description>The single most viral shift in how developers work with AI in 2026 has a name - spec-driven development (SDD) - and it rests on a simple, hard-won realisation: AI coding agents are brilliant at writing code and terrible at guessing what you meant. Ad-hoc prompting produces a plausible first attempt and then an endless loop of 'no, not like that, regenerate'. SDD flips the workflow: you write a clear, structured specification first, and the agent builds from it - and the results are striking, with teams reporting an order of magnitude fewer 'regenerate from scratch' cycles and 40-hour features shipped in under 8 hours of human time. Every major AI coding tool has now shipped its own flavour of it. This flagship playbook explains what spec-driven development actually is, why it works, and how senior engineers and teams are using it to ship production AI code.</description>
      <media:content url="https://images.unsplash.com/photo-1591696331111-ef9586a5b17a?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>You Can't Run What You Can't See: LLM And Agent Observability In Production, Explained For Engineering Leaders</title>
      <link>https://www.braiviq.com/playbook/llm-agent-observability-production-2026-cant-run-what-you-cant-see-engineering-leaders-guide</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/llm-agent-observability-production-2026-cant-run-what-you-cant-see-engineering-leaders-guide</guid>
      <pubDate>Wed, 09 Sep 2026 09:00:00 GMT</pubDate>
      <category>Deployment &amp; Production</category>
      <description>When an ordinary web service misbehaves in production, you have logs, metrics and traces to find out why. When an AI agent misbehaves - takes a wrong action, loops, hallucinates, quietly degrades - most teams have almost nothing, because they never built the observability to see inside it. That gap is one of the biggest reasons AI agents get stuck in demos and never earn trust in production. In 2026 a whole category of tooling has emerged to close it - agent observability - built on a simple principle: you cannot debug, evaluate or govern in production what you cannot see, and seeing inside an agent means capturing structured, hierarchical telemetry across every reasoning step, tool call and handoff. This educational playbook, for senior engineers and CTOs, explains what LLM and agent observability actually is, why it is different from ordinary monitoring, and why it is now essential infrastructure for anyone running AI in production.</description>
      <media:content url="https://images.unsplash.com/photo-1518432031352-d6fc5c10da5a?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Britain's AI Growth Zones And Compute Roadmap: What The £68bn Infrastructure Bet Means For UK Developers - An Honest, Pro-UK Read</title>
      <link>https://www.braiviq.com/playbook/uk-ai-growth-zones-compute-roadmap-2026-68bn-infrastructure-bet-what-it-means-uk-developers-pro-uk</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/uk-ai-growth-zones-compute-roadmap-2026-68bn-infrastructure-bet-what-it-means-uk-developers-pro-uk</guid>
      <pubDate>Wed, 09 Sep 2026 09:00:00 GMT</pubDate>
      <category>AI Strategy &amp; ROI</category>
      <description>While much of the AI debate is about models and hype, Britain has been quietly making one of the most consequential and least-discussed bets of all: on the physical foundations of AI - the compute and the data centres. The numbers are genuinely large. The UK's AI compute capacity grew tenfold in a year, from 2 to 21 ExaFLOPs, with a target of 420 by 2030. £68bn of investment has been pledged into designated AI Growth Zones, and the government is fast-tracking the data-centre buildout the country needs. For developers and enterprises building AI in Britain, this matters in a very concrete way - because compute and infrastructure are the ground everything else is built on. This is an honest, pro-UK read on what Britain's AI Growth Zones and compute roadmap actually mean for UK developers, why building out the physical foundations is a genuinely important bet, and where the honest limits lie.</description>
      <media:content url="https://images.unsplash.com/photo-1587202372775-e229f172b9d7?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Building An Order And Execution Management System (O/EMS) In Code: The Trade Lifecycle From Capture To Settlement</title>
      <link>https://www.braiviq.com/playbook/building-order-execution-management-system-oems-code-trade-lifecycle-capture-to-settlement-trading</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/building-order-execution-management-system-oems-code-trade-lifecycle-capture-to-settlement-trading</guid>
      <pubDate>Tue, 08 Sep 2026 09:00:00 GMT</pubDate>
      <category>Trading</category>
      <description>Behind every trade a firm makes sits a system that manages its entire life - from the decision to trade, through validation and compliance, to execution in the market, to settlement and the books. Traditionally this was two systems: an Order Management System (OMS) handling the order lifecycle and compliance, and an Execution Management System (EMS) handling how orders get executed in real time. In 2026 the industry is decisively converging them into a single, unified O/EMS - one continuous system from portfolio decision to post-trade - because the old split created reconciliation overhead, fractured data and duplicated support. This playbook is a developer-and-enterprise-grade tour of how an O/EMS actually works in code: the trade lifecycle it manages, why OMS and EMS are merging, and the architecture that makes a unified execution stack work.</description>
      <media:content url="https://images.unsplash.com/photo-1568234928966-359c35dd8327?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Building A Real-Time Trading Blotter And P&amp;L Dashboard In Code: Live Positions, Orders, Fills And Profit-And-Loss That Never Lie</title>
      <link>https://www.braiviq.com/playbook/building-real-time-trading-blotter-pnl-dashboard-code-live-positions-orders-fills-trading-charts</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/building-real-time-trading-blotter-pnl-dashboard-code-live-positions-orders-fills-trading-charts</guid>
      <pubDate>Tue, 08 Sep 2026 09:00:00 GMT</pubDate>
      <category>Trading</category>
      <description>Ask a trader what they stare at all day and it is not a candlestick chart - it is the blotter: the live, constantly-updating view of their orders, fills, positions and profit-and-loss. It is the single most important screen in trading, because it is where a trader sees, in real time, what they hold, what is working, what is filling, and whether they are making or losing money right now. Building one that is fast, correct and readable under a live market is a deceptively hard and highly specialised job - and one where a subtle bug doesn't just look wrong, it shows a trader the wrong P&amp;L, which is dangerous. This is a domain BraivIQ specialises in, and this playbook covers how a real-time trading blotter and P&amp;L dashboard actually works in code: the data behind it, the calculations that must be exactly right, and the rendering that keeps it live and legible.</description>
      <media:content url="https://images.unsplash.com/photo-1559526324-593bc073d938?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>The Regulatory Reporting Nightmare: What A Trading Firm's Dev Team Must Learn To Automate Compliance Reporting And Data Integration With AI</title>
      <link>https://www.braiviq.com/playbook/automating-regulatory-reporting-data-integration-trading-firm-dev-team-code-latest-tech-2026</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/automating-regulatory-reporting-data-integration-trading-firm-dev-team-code-latest-tech-2026</guid>
      <pubDate>Mon, 07 Sep 2026 09:00:00 GMT</pubDate>
      <category>Case Studies</category>
      <description>Ask developers at an investment bank or trading firm what quietly consumes the most soul-destroying hours, and a common answer is not the trading systems - it is regulatory reporting and the data integration behind it. Regulators demand a steady stream of detailed, accurate, filing-ready reports, and producing them means pulling data from many disjointed systems, reconciling it, and assembling it into exactly the right format, on time, every time - work that teams still do with an enormous amount of manual effort, chasing data across systems that were never designed to talk to each other. It is a genuine, expensive, high-stakes pain point, and in 2026 it is one of the highest-value places a trading dev team can apply AI and modern data engineering. This playbook is the practical, real-world account of what a trading firm's dev team must learn to automate regulatory reporting and the data integration underneath it.</description>
      <media:content url="https://images.unsplash.com/photo-1554224154-22dec7ec8818?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Multi-Agent Orchestration In Production: What Actually Survived - Coordination, Failure Modes And The Build-Versus-Buy Decision</title>
      <link>https://www.braiviq.com/playbook/multi-agent-orchestration-production-2026-coordination-langgraph-failure-modes-build-vs-buy-code</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/multi-agent-orchestration-production-2026-coordination-langgraph-failure-modes-build-vs-buy-code</guid>
      <pubDate>Sun, 06 Sep 2026 09:00:00 GMT</pubDate>
      <category>Workflow Automation</category>
      <description>The dream of 2025 was a swarm of AI agents collaborating to do complex work - and 2026 was the year that dream met production reality. Teams discovered that getting multiple agents to work together reliably is a genuinely hard coordination problem, and that most naive multi-agent systems fail in specific, repeatable ways: a study of popular multi-agent frameworks across 150-plus tasks identified 14 distinct failure modes across design, inter-agent misalignment, and verification. But the teams that got it right proved multi-agent systems can deliver real value when engineered properly - which is why coordination has become the new frontier of scaling AI. This playbook covers what actually survived contact with production: how multi-agent orchestration works in code, the failure modes to design against, the frameworks that emerged, and the build-versus-buy decision every team now faces.</description>
      <media:content url="https://images.unsplash.com/photo-1667372393119-3d4c48d07fc9?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Sandboxing AI Agents In Production: The Runtime Security Playbook For Agents That Browse, Call APIs, Write Files And Push Changes</title>
      <link>https://www.braiviq.com/playbook/sandboxing-ai-agents-production-runtime-security-firecracker-gvisor-wasm-isolation-2026</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/sandboxing-ai-agents-production-runtime-security-firecracker-gvisor-wasm-isolation-2026</guid>
      <pubDate>Fri, 04 Sep 2026 09:00:00 GMT</pubDate>
      <category>Deployment &amp; Production</category>
      <description>In 2026, AI agents don't just answer - they browse the web, call APIs, write files, query databases, trigger workflows, send emails and push production changes. Which raises a question every engineering team deploying agents now has to answer: what happens when an agent, running model-generated instructions it was never fully in control of, does something it shouldn't - on your real systems? The answer the industry has converged on this year is the sandbox: a controlled, isolated runtime that sits between your model and your production systems and lets an agent act without letting it do harm. This flagship playbook is the developer-and-enterprise-grade guide to sandboxing AI agents - why it has become non-negotiable, the isolation technologies to choose between, and how to build the runtime security that makes production agents safe.</description>
      <media:content url="https://images.unsplash.com/photo-1607705703571-c5a8695f18f6?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Running AI Inside The Firewall: What A Trading Firm's Dev Team Must Learn To Deploy LLMs In A Locked-Down, Air-Gapped Regulated Environment</title>
      <link>https://www.braiviq.com/playbook/running-ai-inside-the-firewall-trading-firm-air-gapped-private-llm-regulated-deployment-2026</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/running-ai-inside-the-firewall-trading-firm-air-gapped-private-llm-regulated-deployment-2026</guid>
      <pubDate>Fri, 04 Sep 2026 09:00:00 GMT</pubDate>
      <category>Case Studies</category>
      <description>Every developer at an investment bank or trading firm has hit the same wall: you want to use AI to work faster, but you cannot paste your code, your trades or your customer data into ChatGPT - because policy, and regulations like PCI DSS and GLBA, flatly forbid sending sensitive financial data to a public tool. For a regulated trading dev team, the public AI everyone else uses is simply off-limits. So how do these teams get AI's productivity without breaking the rules that protect their data? The answer, increasingly, is to run AI inside the firewall: private, self-hosted and even fully air-gapped LLMs that never let data leave the controlled environment. This playbook is the practical, real-world account of what a trading firm's dev team actually has to learn to do exactly that.</description>
      <media:content url="https://images.unsplash.com/photo-1601737487795-dab272f52420?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Agent Evaluation Is Now Its Own Discipline - And A Commercial Category: What Senior Engineers And CTOs Need To Know</title>
      <link>https://www.braiviq.com/playbook/agent-evaluation-discipline-commercial-category-senior-engineers-cto-chat-eval-vs-agent-eval-2026</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/agent-evaluation-discipline-commercial-category-senior-engineers-cto-chat-eval-vs-agent-eval-2026</guid>
      <pubDate>Thu, 03 Sep 2026 09:00:00 GMT</pubDate>
      <category>Agentic AI</category>
      <description>In 2024, 'evaluating' an AI meant checking whether its answers were good - a spreadsheet of prompts and outputs someone eyeballed. In 2026 that is nowhere near enough, because agents don't just answer - they take multi-step journeys, calling tools, making decisions and acting, and evaluating them means judging the whole trajectory, not a final reply. As the industry put it: chat eval was a spreadsheet. Agent eval is a system. Evaluation has become so central that it turned into a commercial category - OpenAI acquired an evaluation company, and a major open-source agent-evaluation framework launched with backing from across the industry. This educational playbook, for senior engineers and CTOs, explains why agent evaluation is a distinct and now-essential discipline, how it differs from evaluating a chatbot, and why it has become the thing that separates agents that ship from agents that stay stuck in demos.</description>
      <media:content url="https://images.unsplash.com/photo-1638029202288-451a89e0d55f?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Britain Bets On Open-Source AI: What DSIT's Compute-For-Builders Push And The AI Security Institute Mean For UK Developers - An Honest, Pro-UK Read</title>
      <link>https://www.braiviq.com/playbook/britain-open-source-ai-bet-dsit-compute-builders-ai-security-institute-uk-developers-pro-uk-2026</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/britain-open-source-ai-bet-dsit-compute-builders-ai-security-institute-uk-developers-pro-uk-2026</guid>
      <pubDate>Thu, 03 Sep 2026 09:00:00 GMT</pubDate>
      <category>AI Strategy &amp; ROI</category>
      <description>While the AI conversation obsesses over a handful of giant proprietary models, Britain has been quietly making a different, developer-friendly bet: backing open-source AI builders directly. In 2026 the government's science department is handing open-source AI developers hundreds of thousands of pounds of compute from the national AI Research Resource, pairing them with expert mentors, and giving young UK developers a direct line into government - while the AI Security Institute publishes serious technical research on the exact risks that matter to people building with AI. For developers and enterprises building on open models in Britain, this is easy to miss and genuinely significant. This is an honest, pro-UK read on why Britain's open-source AI bet and its safety work are a real advantage for UK developers, and where the honest limits lie.</description>
      <media:content url="https://images.unsplash.com/photo-1500380804539-4e1e8c1e7118?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Building A Smart Order Router In Code: Scanning Venues, Splitting Orders And Routing For Best Execution</title>
      <link>https://www.braiviq.com/playbook/building-smart-order-router-code-venue-scanning-order-splitting-best-execution-trading</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/building-smart-order-router-code-venue-scanning-order-splitting-best-execution-trading</guid>
      <pubDate>Wed, 02 Sep 2026 09:00:00 GMT</pubDate>
      <category>Trading</category>
      <description>When you place a trade in a market fragmented across dozens of venues, a deceptively hard question has to be answered in real time: where should this order actually go? The system that answers it is the Smart Order Router - the piece of trading infrastructure that monitors every venue it is connected to, works out the best place (or places) to send each order after accounting for price, fees, latency and the likelihood of getting filled, and can split a large order into smaller pieces spread across venues and time. It is one of the most important and demanding systems in electronic trading, and at execution-focused firms it runs on co-located servers with routing logic in C++ or on FPGAs. This playbook is a developer-and-enterprise-grade tour of how a smart order router actually works in code.</description>
      <media:content url="https://images.unsplash.com/photo-1618044733300-9472054094ee?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Visualising Execution Quality In Code: Building Transaction-Cost-Analysis And Slippage Dashboards For Trading</title>
      <link>https://www.braiviq.com/playbook/visualising-execution-quality-transaction-cost-analysis-slippage-dashboards-code-trading-charts</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/visualising-execution-quality-transaction-cost-analysis-slippage-dashboards-code-trading-charts</guid>
      <pubDate>Wed, 02 Sep 2026 09:00:00 GMT</pubDate>
      <category>Trading</category>
      <description>A trade is not done when it fills - it is done well or badly, and the difference is worth real money. Transaction Cost Analysis (TCA) is the discipline of measuring exactly how well trades were executed: whether they got good prices, how much was lost to spread, slippage and market impact, and how the costs compare to benchmarks. But raw TCA numbers buried in a table help no one. The value comes when you visualise execution quality so a trader or a desk can see, at a glance, where they are trading well and where they are bleeding money. This is a domain BraivIQ specialises in, and this playbook covers how to build TCA and slippage dashboards in code - the metrics that matter, the visualisations that make them legible, and the real-time, pre-to-post-trade discipline that turns execution data into better trading.</description>
      <media:content url="https://images.unsplash.com/photo-1554260570-e9689a3418b8?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Before The Tool Call: Pre-Action Authorization And Tool-Call Governance For Production AI Agents</title>
      <link>https://www.braiviq.com/playbook/pre-action-authorization-tool-call-governance-ai-agents-code-deterministic-policy-permission-2026</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/pre-action-authorization-tool-call-governance-ai-agents-code-deterministic-policy-permission-2026</guid>
      <pubDate>Tue, 01 Sep 2026 09:00:00 GMT</pubDate>
      <category>AI Integration</category>
      <description>Sandboxing an AI agent contains what its code can do if it runs. But there is a different, equally important question a production agent forces on you: should this specific action be allowed to happen at all? When an agent decides to call a tool - transfer funds, delete records, email a customer, modify a database - you often want a deterministic answer to 'is the agent permitted to do this, right now, given who it's acting for and the context?' before the action executes, not after. That is pre-action authorization: a policy layer that sits between the agent's decision and the tool's execution, and gates the action deterministically. This playbook explains why pre-action authorization has become a distinct and essential part of the 2026 agent stack, how it differs from sandboxing, and how to build tool-call governance for agents you can actually trust with real capabilities.</description>
      <media:content url="https://images.unsplash.com/photo-1584433144859-1fc3ab64a957?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Building A GPU-Accelerated Options Pricing And Risk Engine In Code: Monte Carlo, The Heston Model, And The Rent-Versus-Build Compute Decision</title>
      <link>https://www.braiviq.com/playbook/gpu-accelerated-options-pricing-risk-engine-code-monte-carlo-heston-rent-vs-build-compute</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/gpu-accelerated-options-pricing-risk-engine-code-monte-carlo-heston-rent-vs-build-compute</guid>
      <pubDate>Mon, 31 Aug 2026 09:00:00 GMT</pubDate>
      <category>Trading</category>
      <description>Pricing a single vanilla option is a formula. Pricing and risk-managing a book of thousands of exotic options across a live volatility surface, recomputing the Greeks as the market moves, is one of the most compute-hungry problems in finance - and in 2026 it runs on GPUs. But GPU-accelerated derivatives pricing is full of subtle engineering traps: the parallelism only works in certain directions, the models are unforgiving, and the single biggest cost decision - rent the compute or build it - is now a live strategic question every quant desk faces. This flagship playbook is a developer-and-enterprise-grade tour of how a GPU options pricing and risk engine actually works in code, where the speedups genuinely come from, and how to make the compute decision that shapes the whole system.</description>
      <media:content url="https://images.unsplash.com/photo-1591238372338-22d30c883a86?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>What A Trading Firm's Dev Team Actually Has To Learn To Ship AI: Legacy Modernisation, The Verification Crunch And Model Risk - A Real-World Playbook</title>
      <link>https://www.braiviq.com/playbook/trading-firm-dev-team-learn-ship-ai-legacy-modernisation-verification-crunch-model-risk-2026</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/trading-firm-dev-team-learn-ship-ai-legacy-modernisation-verification-crunch-model-risk-2026</guid>
      <pubDate>Mon, 31 Aug 2026 09:00:00 GMT</pubDate>
      <category>Case Studies</category>
      <description>The headline numbers from banking's AI push are staggering: Goldman reports 3 to 4 times engineering productivity from AI coding agents, Citi has saved around 100,000 developer hours a week through automated code review, and one firm converted three million lines of COBOL into clear specifications in eight weeks. But behind those numbers is a harder, less-quoted story that every investment-banking and trading dev team runs into: AI adoption is straining testing, model validation and auditability precisely where it matters most - in high-volume trading, risk and real-time systems. This playbook is the practical, real-world account of what a trading firm's engineering team actually has to learn to ship AI safely: where the wins really are, the pain point nobody warns you about, and the disciplines that separate a productivity gain from a production incident.</description>
      <media:content url="https://images.unsplash.com/photo-1573164574472-797cdf4a583a?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>AI Agent Memory Is Now A First-Class Engineering Problem: The Three Tiers Every Senior Engineer And CTO Must Understand</title>
      <link>https://www.braiviq.com/playbook/ai-agent-memory-first-class-engineering-problem-three-tiers-senior-engineers-cto-2026</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/ai-agent-memory-first-class-engineering-problem-three-tiers-senior-engineers-cto-2026</guid>
      <pubDate>Mon, 31 Aug 2026 09:00:00 GMT</pubDate>
      <category>Agentic AI</category>
      <description>In 2024, 'memory' for an AI agent meant one thing: pick a vector database and do RAG. In 2026 that answer is embarrassingly incomplete. Agent memory has become a genuine engineering discipline - with real benchmarks, measurable trade-offs, distinct architectural tiers, and a fast-growing body of operational knowledge - and it is one of the defining reasons some agents behave intelligently over time while others forget, contradict themselves and drift. If your agents feel stateless, forgetful or inconsistent, the problem is almost certainly memory. This educational playbook, for senior engineers and CTOs, explains what agent memory actually is beyond RAG, the three tiers you need to understand, and why treating memory as a first-class architectural concern is now essential to building agents that work.</description>
      <media:content url="https://images.unsplash.com/photo-1667372335962-5fd503a8ae5b?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Visualising The Volatility Surface And The Greeks In Code: 3D Rendering, Interpolation And Real-Time Options Analytics For Trading Interfaces</title>
      <link>https://www.braiviq.com/playbook/visualising-volatility-surface-greeks-code-3d-rendering-options-trading-charts-interfaces</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/visualising-volatility-surface-greeks-code-3d-rendering-options-trading-charts-interfaces</guid>
      <pubDate>Sun, 30 Aug 2026 09:00:00 GMT</pubDate>
      <category>Trading</category>
      <description>For an equity trader, a price chart is enough. For an options trader, the essential picture is a three-dimensional one: the volatility surface, showing implied volatility across every strike and expiry at once, and the Greeks that describe how the book's risk changes as the market moves. Rendering these well - a smooth, interactive 3D surface that updates in real time, heatmaps of risk across a book, all readable at a glance under a live market - is one of the most specialised and demanding jobs in trading-interface engineering. This is a domain BraivIQ specialises in, and this playbook covers how options analytics visualisation actually works in code: the data behind the surface, the interpolation that smooths it, the 3D rendering that makes it usable, and the real-time discipline that keeps it honest.</description>
      <media:content url="https://images.unsplash.com/photo-1620641788421-7a1c342ea42e?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Britain's Technology-Agnostic AI Rulebook For Finance: Why The UK's 'No Special AI Law' Approach Is A Quiet Advantage For Developers - An Honest, Pro-UK Read</title>
      <link>https://www.braiviq.com/playbook/uk-technology-agnostic-ai-rulebook-finance-no-special-ai-law-advantage-developers-pro-uk-2026</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/uk-technology-agnostic-ai-rulebook-finance-no-special-ai-law-advantage-developers-pro-uk-2026</guid>
      <pubDate>Sun, 30 Aug 2026 09:00:00 GMT</pubDate>
      <category>AI Strategy &amp; ROI</category>
      <description>While much of the world reaches for bespoke, prescriptive AI laws, Britain has made a deliberate and distinctive choice for its financial sector: no special AI Act, but a technology-agnostic approach that regulates AI through the existing, well-understood frameworks that already govern finance. In 2026 the government formalised the push - directing 19 regulators to publish plans for enabling safe AI innovation - while the Bank of England, PRA and FCA reaffirmed they will oversee AI through existing rules rather than new AI-specific ones. For developers and enterprises building AI in UK finance, this is easy to overlook and genuinely consequential. This is an honest, pro-UK read on why the technology-agnostic approach is a quiet advantage, where its limits lie, and what it means for the teams actually shipping AI in a regulated environment.</description>
      <media:content url="https://images.unsplash.com/photo-1642132652860-471b4228023e?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>AI SRE Is Here: Building Agentic Incident Response That Cuts Time-To-Mitigation From Hours To Minutes - A Production Engineering Playbook</title>
      <link>https://www.braiviq.com/playbook/ai-sre-agentic-incident-response-code-autonomous-remediation-runbooks-guardrails-production-2026</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/ai-sre-agentic-incident-response-code-autonomous-remediation-runbooks-guardrails-production-2026</guid>
      <pubDate>Sun, 30 Aug 2026 09:00:00 GMT</pubDate>
      <category>Deployment &amp; Production</category>
      <description>One of the most striking real-world AI results of 2026 was not a chatbot or a coding demo - it was an agent that autonomously handled more than 35,000 production incidents and cut time-to-mitigation for a major cloud service from over 40 hours to around 3 minutes. This is 'AI SRE' - agentic AI applied to the on-call, incident-response and site-reliability work that keeps production systems alive - and it is one of the highest-impact and most demanding places to deploy an agent, because the agent operates on live production during its worst moments. This playbook covers how agentic incident response actually works in code: the detect-diagnose-remediate loop, runbooks as tools, the guardrails that make autonomy safe on production, and why this is both enormously valuable and not to be done casually.</description>
      <media:content url="https://images.unsplash.com/photo-1629654291663-b91ad427698f?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>The Quant Research-To-Production Pipeline In Code: Reproducibility, Experiment Tracking And Shipping Trading Signals Without The Gap</title>
      <link>https://www.braiviq.com/playbook/quant-research-to-production-pipeline-code-reproducibility-experiment-tracking-shipping-signals</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/quant-research-to-production-pipeline-code-reproducibility-experiment-tracking-shipping-signals</guid>
      <pubDate>Sun, 30 Aug 2026 09:00:00 GMT</pubDate>
      <category>Workflow Automation</category>
      <description>In quantitative trading, the graveyard is full of signals that looked brilliant in a researcher's notebook and died in production - not because the idea was wrong, but because the pipeline between research and live trading was broken. Non-reproducible experiments, subtle differences between the backtest and the live system, untracked changes, and point-in-time data mistakes turn promising research into production failures with alarming regularity. The research-to-production gap is one of the defining engineering challenges of a quant team. This playbook covers how to build the pipeline that closes it: reproducible research, experiment tracking, the discipline that keeps backtest and live consistent, and the workflow architecture that ships a signal from idea to production safely.</description>
      <media:content url="https://images.unsplash.com/photo-1607706009771-de8808640bcf?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Building A High-Performance Limit Order Book And Matching Engine In Code: Price-Time Priority, Lock-Free Data Structures And 10M+ Orders Per Second</title>
      <link>https://www.braiviq.com/playbook/limit-order-book-matching-engine-code-price-time-priority-lock-free-low-latency-trading</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/limit-order-book-matching-engine-code-price-time-priority-lock-free-low-latency-trading</guid>
      <pubDate>Sat, 29 Aug 2026 09:00:00 GMT</pubDate>
      <category>Trading</category>
      <description>The matching engine is the beating heart of every exchange and trading venue - the piece of code that maintains the order book and pairs buyers with sellers, deterministically, millions of times a second. It is also one of the most demanding systems in all of software engineering: it must be correct to the cent, fair to the microsecond, and fast enough that latency is measured in nanoseconds. In 2026 a new generation of engineers is building these systems in Rust, using lock-free data structures to hit throughputs north of ten million orders per second. This flagship playbook is a developer-and-enterprise-grade tour of how a limit order book and matching engine actually work in code - the data structures, the matching rules, the concurrency, and the reasons this remains one of the hardest and most fascinating problems in systems programming.</description>
      <media:content url="https://images.unsplash.com/photo-1651340981821-b519ad14da7c?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>AI Coding Agents Are In Production: Why Verification, Not Code Generation, Is Now The Bottleneck - A Playbook For Senior Engineers And CTOs</title>
      <link>https://www.braiviq.com/playbook/ai-coding-agents-production-verification-bottleneck-senior-engineers-cto-playbook-2026</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/ai-coding-agents-production-verification-bottleneck-senior-engineers-cto-playbook-2026</guid>
      <pubDate>Sat, 29 Aug 2026 09:00:00 GMT</pubDate>
      <category>Agentic AI</category>
      <description>The debate about whether AI can write production code is over: as of mid-2026, around 90% of professional developers use AI coding agents at work at least weekly and 68% use them daily. But the teams actually getting value have learned something the hype missed - the bottleneck is no longer generating code, it is verifying it. When agents can produce more code than your team can review, review capacity becomes the constraint on everything. This educational playbook, aimed at senior engineers and CTOs, explains the real state of AI coding agents in 2026, why verification is the new limiting factor, how the senior role is shifting from writing code to orchestrating and governing a digital workforce, and what it means for how you build and staff an engineering organisation.</description>
      <media:content url="https://images.unsplash.com/photo-1498050108023-c5249f4df085?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Sovereign Compute And The UK's AI Bet: What Britain's Push For Sovereign AI Means For Developers And Enterprises - An Honest, Pro-UK Read</title>
      <link>https://www.braiviq.com/playbook/uk-sovereign-compute-ai-developers-enterprises-britain-honest-pro-uk-read-2026</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/uk-sovereign-compute-ai-developers-enterprises-britain-honest-pro-uk-read-2026</guid>
      <pubDate>Sat, 29 Aug 2026 09:00:00 GMT</pubDate>
      <category>AI Strategy &amp; ROI</category>
      <description>At London Tech Week 2026, the UK government committed £400 million to AI chips and sovereign compute infrastructure, part of a broader bet that Britain should own critical AI capability rather than rent all of it from overseas hyperscalers. For developers and enterprises, 'sovereign compute' is not an abstract policy phrase - it is about where your models run, whose laws reach your data, and whether you have genuine control and resilience or merely a data-residency label. This is an honest, pro-UK read on what sovereign compute actually means in code and infrastructure terms, why it matters for UK developers and businesses, the real debate about open source and control, and where the honest caveats lie.</description>
      <media:content url="https://images.unsplash.com/photo-1558346490-a72e53ae2d4f?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Market Data At Scale: Choosing A Time-Series Database And Building A Tick Store For Trading With kdb+, ClickHouse And QuestDB</title>
      <link>https://www.braiviq.com/playbook/market-data-tick-store-time-series-database-trading-kdb-clickhouse-questdb-code</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/market-data-tick-store-time-series-database-trading-kdb-clickhouse-questdb-code</guid>
      <pubDate>Fri, 28 Aug 2026 09:00:00 GMT</pubDate>
      <category>Deployment &amp; Production</category>
      <description>Every serious trading and quant operation runs on a tick store - a time-series database holding the firehose of trade prints, quote updates and order-book snapshots that markets generate, often billions of rows for a single research database and trillions across history. Choosing and building that store is one of the most consequential infrastructure decisions a trading-tech team makes, because it determines how fast you can research, backtest and analyse - and how much it costs. For years the answer was kdb+. In 2026 open-source challengers like ClickHouse and QuestDB have changed the calculus. This playbook is a developer-and-enterprise-grade guide to time-series databases for market data, how a tick store is architected, and how to choose between the options.</description>
      <media:content url="https://images.unsplash.com/photo-1544383835-bda2bc66a55d?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Visualising The Order Book In Code: Depth Charts, Heatmaps And Level-2 Market Data Rendering For Trading Interfaces</title>
      <link>https://www.braiviq.com/playbook/visualising-order-book-code-depth-charts-heatmaps-level-2-market-data-trading-charts</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/visualising-order-book-code-depth-charts-heatmaps-level-2-market-data-trading-charts</guid>
      <pubDate>Fri, 28 Aug 2026 09:00:00 GMT</pubDate>
      <category>Trading</category>
      <description>A price chart tells you where the market has been. The order book tells you where it might go - the live wall of resting bids and asks that reveals supply, demand and liquidity in real time. Visualising it well is one of the most valuable and technically demanding jobs in trading-interface engineering: rendering the depth chart, the heatmap of liquidity over time, and the fast-scrolling ladder of Level-2 data, all updating many times a second without dropping a frame. This is a domain BraivIQ specialises in, and this playbook covers how order-book visualisation actually works in code - the data, the visual forms, and the rendering techniques that keep it smooth under a relentless market-data feed.</description>
      <media:content url="https://images.unsplash.com/photo-1640340434855-6084b1f4901c?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Streaming Market-Data Pipelines In Code: Kafka, Backpressure And Exactly-Once Processing For Trading Automation</title>
      <link>https://www.braiviq.com/playbook/streaming-market-data-pipelines-code-kafka-backpressure-exactly-once-trading-automation</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/streaming-market-data-pipelines-code-kafka-backpressure-exactly-once-trading-automation</guid>
      <pubDate>Fri, 28 Aug 2026 09:00:00 GMT</pubDate>
      <category>Workflow Automation</category>
      <description>Between the market and every trading decision sits a pipeline - the streaming infrastructure that ingests raw market data, processes and enriches it, and delivers it to strategies, risk systems, analytics and storage, continuously and reliably. Build it badly and you get lag, gaps, duplicated events and silent data loss - each of which can turn a good trading strategy into a losing one. Build it well and you have a backbone the whole operation can trust. This playbook covers how to architect a streaming market-data pipeline in code: the streaming platform, handling backpressure when data outpaces consumers, achieving exactly-once processing where it matters, and the reliability patterns that keep trading automation fed with clean, timely data.</description>
      <media:content url="https://images.unsplash.com/photo-1611262588024-d12430b98920?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Building A Market-News And Sentiment RAG Pipeline For Trading Signals In Code: Ingestion, Retrieval, LLM Analysis And The Look-Ahead Trap</title>
      <link>https://www.braiviq.com/playbook/market-news-sentiment-rag-pipeline-trading-signals-code-llm-engineering</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/market-news-sentiment-rag-pipeline-trading-signals-code-llm-engineering</guid>
      <pubDate>Fri, 28 Aug 2026 09:00:00 GMT</pubDate>
      <category>RAG &amp; LLM Engineering</category>
      <description>Markets move on information, and a huge amount of that information arrives as unstructured text - news, filings, transcripts, social posts - far faster than any human can read it. Using LLMs and retrieval to turn that text into structured, timely signals is one of the most sought-after applications of AI in trading. But it is also riddled with subtle traps that make a pipeline look brilliant in a backtest and useless or misleading in production - above all, look-ahead bias and point-in-time correctness. This playbook covers how to build a market-news and sentiment pipeline in code: ingesting and structuring the text firehose, retrieval and LLM analysis, and the point-in-time discipline that separates a genuine signal from a backtest illusion.</description>
      <media:content url="https://images.unsplash.com/photo-1504711434969-e33886168f5c?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Architecting An Agentic Trading System In Code: The Event-Driven Decision Loop, Multi-Agent Design, Backtest-Live Parity And Risk Engine</title>
      <link>https://www.braiviq.com/playbook/agentic-trading-system-architecture-code-event-loop-backtesting-risk-engine-multi-agent</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/agentic-trading-system-architecture-code-event-loop-backtesting-risk-engine-multi-agent</guid>
      <pubDate>Wed, 26 Aug 2026 09:00:00 GMT</pubDate>
      <category>Trading</category>
      <description>Agentic AI has arrived in trading, and 2026's open-source proof-of-concepts - multi-agent hedge funds with tens of thousands of GitHub stars - have made one thing clear: the model is the easy part, the architecture is the whole game. A production agentic trading system is not an LLM told to 'trade well'. It is a disciplined event-driven decision loop wrapping specialised reasoning agents, fed strictly point-in-time data, running the identical code path in backtest and live, and gated by a risk engine that has the final word over every order. This flagship playbook is the developer-and-enterprise-grade architecture for building one - and the reproducibility and look-ahead-bias traps that quietly invalidate most attempts.</description>
      <media:content url="https://images.unsplash.com/photo-1642790106117-e829e14a795f?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>AI In Trading Systems: A Technical Playbook For Machine Learning, Backtesting, Execution And Risk Controls In Automated Markets</title>
      <link>https://www.braiviq.com/playbook/ai-trading-systems-playbook-machine-learning-backtesting-risk-controls-execution</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/ai-trading-systems-playbook-machine-learning-backtesting-risk-controls-execution</guid>
      <pubDate>Wed, 26 Aug 2026 09:00:00 GMT</pubDate>
      <category>Trading</category>
      <description>Applying machine learning to trading is one of the hardest problems in applied AI - and one of the easiest to fool yourself on. Markets are adversarial, non-stationary and mostly noise. A backtest that looks brilliant is far more often a bug than an edge. This playbook is an honest, engineering-first look at building AI-driven trading systems: the pipeline from data to execution, the backtesting traps that manufacture fake profits, the risk controls that keep a system alive, and the sober reality that most strategies do not work. Educational engineering guidance, not financial advice.</description>
      <media:content url="https://images.unsplash.com/photo-1642543348745-03b1219733d9?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Building A Real-Time Trading Chart Engine In The Browser: WebGL Rendering, Streaming Market Data And TradingView-Grade Performance In Code</title>
      <link>https://www.braiviq.com/playbook/real-time-trading-chart-engine-code-webgl-canvas-streaming-market-data-browser</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/real-time-trading-chart-engine-code-webgl-canvas-streaming-market-data-browser</guid>
      <pubDate>Tue, 25 Aug 2026 09:00:00 GMT</pubDate>
      <category>Trading</category>
      <description>Trading charts are deceptively hard. A candlestick chart looks simple until you try to stream live ticks into it, render millions of historical bars, overlay indicators, and keep it all at 60 frames per second while the user pans and zooms - at which point naive DOM and SVG approaches collapse completely. This is a domain BraivIQ specialises in, and this playbook is the engineering reality: why high-performance financial charts are built on WebGL and WebAssembly, how the streaming data path is architected separately from the render path, and the specific techniques - decimation, ring buffers, incremental updates, worker threads - that get you TradingView-grade performance in code.</description>
      <media:content url="https://images.unsplash.com/photo-1620266757065-5814239881fd?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>The Production Agent Architecture Playbook: Planning, Tool Use, Memory And Guardrails For Agents That Survive Contact With Reality</title>
      <link>https://www.braiviq.com/playbook/production-agent-architecture-playbook-planning-tools-memory-guardrails</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/production-agent-architecture-playbook-planning-tools-memory-guardrails</guid>
      <pubDate>Tue, 25 Aug 2026 09:00:00 GMT</pubDate>
      <category>Agentic AI</category>
      <description>Most AI agents work brilliantly in a demo and fall apart in production. The gap is architecture. A demo agent needs a prompt and a tool. A production agent needs a control loop, a planning strategy, a typed tool layer, bounded memory, retries, budgets, guardrails and observability - and it needs them designed deliberately, not bolted on after the first incident. This is the reference architecture BraivIQ uses to ship agents that run unattended against real systems: the components, how they fit together, and the failure modes each one exists to prevent.</description>
      <media:content url="https://images.unsplash.com/photo-1516110833967-0b5716ca1387?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Context Engineering For CTOs And Senior Engineers: The Discipline That Quietly Replaced Prompt Engineering - And Now Decides Whether Your AI Works</title>
      <link>https://www.braiviq.com/playbook/context-engineering-for-cto-senior-engineers-discipline-that-replaced-prompt-engineering</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/context-engineering-for-cto-senior-engineers-discipline-that-replaced-prompt-engineering</guid>
      <pubDate>Mon, 24 Aug 2026 09:00:00 GMT</pubDate>
      <category>RAG &amp; LLM Engineering</category>
      <description>If your engineers are still 'prompt engineering', they are optimising the wrong layer. The most important shift in applied AI since 2025 has a name - context engineering, coined by Andrej Karpathy in mid-2025 - and it has taken over serious AI engineering discussions for a reason: it is the difference between AI that demos and AI that works in production. This is an educational deep-dive for CTOs and senior engineers on what context engineering actually is, why prompting alone stopped being enough, and why the teams winning with AI treat the context window as a scarce resource to be engineered - an information-architecture discipline, not a writing exercise.</description>
      <media:content url="https://images.unsplash.com/photo-1579403124614-197f69d8187b?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Building A Production RAG System: The Complete Playbook For Chunking, Retrieval, Reranking And Evaluation</title>
      <link>https://www.braiviq.com/playbook/production-rag-system-playbook-chunking-retrieval-reranking-evaluation</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/production-rag-system-playbook-chunking-retrieval-reranking-evaluation</guid>
      <pubDate>Mon, 24 Aug 2026 09:00:00 GMT</pubDate>
      <category>RAG &amp; LLM Engineering</category>
      <description>Retrieval-augmented generation is easy to prototype and hard to make reliable. A weekend RAG demo stuffs some documents into a vector store and calls an LLM. A production RAG system has to answer correctly, cite sources, refuse when it does not know, and stay accurate as the corpus grows to millions of documents. The difference is in the pipeline: how you chunk, how you retrieve, how you rerank, and - the part almost everyone skips - how you evaluate. This is BraivIQ's end-to-end reference for RAG that holds up in production.</description>
      <media:content url="https://images.unsplash.com/photo-1607706189992-eae578626c86?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Why Britain Is A Trading-Technology Superpower: How The FCA, London's Market Infrastructure And UK AI Policy Give Developers An Edge - An Honest, Pro-UK Read</title>
      <link>https://www.braiviq.com/playbook/britain-trading-technology-advantage-fca-london-market-infrastructure-developers-uk</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/britain-trading-technology-advantage-fca-london-market-infrastructure-developers-uk</guid>
      <pubDate>Sun, 23 Aug 2026 09:00:00 GMT</pubDate>
      <category>AI Strategy &amp; ROI</category>
      <description>It is fashionable to be gloomy about Britain, and easy to miss what is in plain sight: the UK is one of the very best places on earth to build trading and financial technology. London is a top-tier global financial centre with the market infrastructure, capital and dense engineering talent to match, and the FCA's pragmatic, outcomes-based approach to algorithmic trading and AI gives developers something rarer and more valuable than a light touch - regulatory clarity. This is an unapologetically pro-UK but honest read, for developers and enterprises, on why Britain's combination of market infrastructure, regulatory approach and AI policy is a genuine competitive advantage in trading technology.</description>
      <media:content url="https://images.unsplash.com/photo-1513635269975-59663e0ac1ad?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>The MCP Integration Playbook: Connecting LLMs To Your Enterprise Systems Without Building A Dozen Bespoke Bridges</title>
      <link>https://www.braiviq.com/playbook/mcp-integration-playbook-connecting-llms-to-enterprise-systems</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/mcp-integration-playbook-connecting-llms-to-enterprise-systems</guid>
      <pubDate>Sun, 23 Aug 2026 09:00:00 GMT</pubDate>
      <category>AI Integration</category>
      <description>The hardest part of enterprise AI is rarely the model - it is plumbing the model into the systems where your data and actions actually live: the CRM, the ERP, the ticketing system, the data warehouse, the internal APIs. Historically every one of those connections was a bespoke integration. The Model Context Protocol changes the economics: build to one open standard and any compliant AI client can use your tools and data. This playbook explains what MCP is, when to use it, and how to integrate LLMs with enterprise systems securely and maintainably.</description>
      <media:content url="https://images.unsplash.com/photo-1591808216268-ce0b82787efe?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Integrating Trading Infrastructure In Code: FIX, WebSockets, REST Broker APIs And MCP For AI-Native Trading Systems</title>
      <link>https://www.braiviq.com/playbook/integrating-trading-infrastructure-code-fix-protocol-websocket-broker-apis-mcp</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/integrating-trading-infrastructure-code-fix-protocol-websocket-broker-apis-mcp</guid>
      <pubDate>Sat, 22 Aug 2026 09:00:00 GMT</pubDate>
      <category>AI Integration</category>
      <description>Connecting a trading system to the outside world is a study in choosing the right protocol for each job. Institutional order flow runs on FIX for sub-millisecond, session-based reliability. Real-time market data streams over WebSockets. Account operations and historical data go over REST, and increasingly, all of it is exposed to AI agents through the Model Context Protocol. Get the integration architecture wrong and you get missed fills, dropped ticks, duplicate orders and brittle bridges. This developer's playbook covers the hybrid-protocol reality of modern trading integration and how to make it clean, resilient and AI-native.</description>
      <media:content url="https://images.unsplash.com/photo-1610989001873-03968eed0f08?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Deploying LLM Applications To Production: A Playbook For Latency, Cost, Caching And Observability</title>
      <link>https://www.braiviq.com/playbook/deploying-llm-applications-latency-cost-caching-observability-playbook</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/deploying-llm-applications-latency-cost-caching-observability-playbook</guid>
      <pubDate>Sat, 22 Aug 2026 09:00:00 GMT</pubDate>
      <category>Deployment &amp; Production</category>
      <description>The prototype worked. Now it has to run for thousands of users, respond fast enough that people do not leave, cost little enough that the unit economics work, and stay up when a provider has a bad day. Deploying an LLM application is a different discipline from building one - it is where token cost becomes a real budget line, where latency becomes a conversion problem, and where 'it works on my machine' meets rate limits and outages. This is BraivIQ's production playbook for shipping LLM apps that are fast, affordable and observable.</description>
      <media:content url="https://images.unsplash.com/photo-1517180102446-f3ece451e9d8?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Durable Trade Processing And Reconciliation In Code: Event-Driven Workflows, Idempotency And Durable Execution For The Financial Back Office</title>
      <link>https://www.braiviq.com/playbook/durable-trade-processing-reconciliation-code-event-driven-temporal-idempotency-back-office</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/durable-trade-processing-reconciliation-code-event-driven-temporal-idempotency-back-office</guid>
      <pubDate>Fri, 21 Aug 2026 09:00:00 GMT</pubDate>
      <category>Workflow Automation</category>
      <description>The trade does not end when it executes - it begins a lifecycle through booking, confirmation, clearing, settlement and accounting, reconciled at every step across a dozen systems that must all agree. This is some of the least glamorous and most unforgiving software in finance: get it wrong and you get breaks, failed settlements and regulatory pain. Naive scripts and cron jobs cannot survive the crashes, retries and partial failures this domain throws at them. This playbook covers how to build trade processing and reconciliation properly in code - event-driven, idempotent, and built on durable execution so a workflow survives anything short of the building burning down.</description>
      <media:content url="https://images.unsplash.com/photo-1625225233840-695456021cde?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Choosing An AI Workflow Automation Backbone: n8n, Make, Zapier And Temporal Compared For Real Production Workloads</title>
      <link>https://www.braiviq.com/playbook/ai-workflow-automation-backbone-n8n-make-temporal-durable-execution</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/ai-workflow-automation-backbone-n8n-make-temporal-durable-execution</guid>
      <pubDate>Fri, 21 Aug 2026 09:00:00 GMT</pubDate>
      <category>Workflow Automation</category>
      <description>Every AI automation eventually needs a backbone: the thing that runs the workflow, handles the steps, retries the failures and survives a server restart mid-run. Pick the wrong one and you either hit a ceiling you cannot engineer past, or you over-build a durable execution engine to send a Slack message. This playbook compares the real options - visual tools like n8n, Make and Zapier versus code-first durable execution like Temporal - and gives BraivIQ's framework for choosing, plus the reliability patterns every AI workflow needs regardless of tool.</description>
      <media:content url="https://images.unsplash.com/photo-1489875347897-49f64b51c1f8?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Deploying Low-Latency AI Inference For Trading: The Latency Budget, Hot Path Versus Slow Path, GPU Serving And Colocation In Code</title>
      <link>https://www.braiviq.com/playbook/low-latency-ai-inference-trading-code-gpu-serving-colocation-hot-path-observability</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/low-latency-ai-inference-trading-code-gpu-serving-colocation-hot-path-observability</guid>
      <pubDate>Thu, 20 Aug 2026 09:00:00 GMT</pubDate>
      <category>Deployment &amp; Production</category>
      <description>In trading, latency is not a performance metric - it is alpha. A model that is right but late is worthless, which makes deploying AI into a trading system a fundamentally different engineering problem from deploying it into a web app. The core discipline is a latency budget spent ruthlessly, and an architecture that keeps slow, powerful LLM reasoning off the critical path while fast, deterministic models make the split-second decisions. This playbook covers how to deploy AI inference for trading in code: the latency budget, the hot-path/slow-path split, GPU serving trade-offs, colocation, and the tail-latency observability that decides whether the system is actually fast when it matters.</description>
      <media:content url="https://images.unsplash.com/photo-1606765962248-7ff407b51667?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>The LLM Evaluation Playbook: Moving From Vibe Checks To Real Metrics So You Can Ship AI Changes With Confidence</title>
      <link>https://www.braiviq.com/playbook/llm-evaluation-playbook-from-vibes-to-metrics-testing-ai-systems</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/llm-evaluation-playbook-from-vibes-to-metrics-testing-ai-systems</guid>
      <pubDate>Thu, 20 Aug 2026 09:00:00 GMT</pubDate>
      <category>RAG &amp; LLM Engineering</category>
      <description>Almost every team building with LLMs evaluates the same way: someone changes a prompt, tries a few examples, decides it 'feels better', and ships. That is a vibe check, and it is why so many AI features regress silently. You cannot improve what you do not measure, and you cannot measure an LLM system with your gut. This playbook is BraivIQ's practical approach to LLM evaluation: building an eval set, choosing the right methods for the job, using LLM-as-judge responsibly, and wiring evals into your workflow so every change is tested, not guessed.</description>
      <media:content url="https://images.unsplash.com/photo-1555949963-aa79dcee981c?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Guardrails And Safety For Production LLM Systems: Defending Against Prompt Injection, Data Leakage And Unsafe Actions</title>
      <link>https://www.braiviq.com/playbook/llm-guardrails-safety-production-prompt-injection-defense-playbook</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/llm-guardrails-safety-production-prompt-injection-defense-playbook</guid>
      <pubDate>Wed, 19 Aug 2026 09:00:00 GMT</pubDate>
      <category>Deployment &amp; Production</category>
      <description>An LLM in production is a component that follows instructions - including malicious ones hidden in the content it processes. That single property is the root of most AI security problems: prompt injection, data exfiltration, unsafe tool use, and outputs that damage users or the business. Guardrails are how you contain a probabilistic, instructable component so it can be trusted with real data and real actions. This playbook sets out the layered defences BraivIQ builds into every production LLM system, from input validation to action gating to output checks.</description>
      <media:content url="https://images.unsplash.com/photo-1581092918056-0c4c3acd3789?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Measuring AI ROI: A CFO-Grade Framework For Proving The Return On Your AI Investment</title>
      <link>https://www.braiviq.com/playbook/measuring-ai-roi-framework-baseline-attribution-total-cost-ownership</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/measuring-ai-roi-framework-baseline-attribution-total-cost-ownership</guid>
      <pubDate>Tue, 18 Aug 2026 09:00:00 GMT</pubDate>
      <category>AI Strategy &amp; ROI</category>
      <description>AI budgets are moving from experimental line items to accountable investments, and the question every board now asks is the hard one: what did we get for it? Most AI ROI cases fall apart under scrutiny because they never captured a baseline, count vanity metrics instead of value, or ignore the real total cost of ownership. This playbook is BraivIQ's practical framework for measuring AI ROI properly - baselining before you build, choosing metrics that map to money, accounting for full cost, and attributing outcomes honestly - so your AI investment survives a finance review instead of collapsing under it.</description>
      <media:content url="https://images.unsplash.com/photo-1543286386-713bdd548da4?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
    <item>
      <title>Case Study: How An Agentic Support Assistant Cut Average Handle Time While Improving Resolution Quality</title>
      <link>https://www.braiviq.com/playbook/case-study-agentic-support-assistant-cut-handle-time-support-operations</link>
      <guid isPermaLink="true">https://www.braiviq.com/playbook/case-study-agentic-support-assistant-cut-handle-time-support-operations</guid>
      <pubDate>Mon, 17 Aug 2026 09:00:00 GMT</pubDate>
      <category>Case Studies</category>
      <description>A support operation drowning in repetitive tickets is one of the highest-ROI places to deploy agentic AI - and one of the easiest to get wrong. Bolt a naive chatbot onto the front and you frustrate customers and erode trust. Design an agentic assistant properly, with retrieval, tool access, guardrails and human escalation, and you cut handle time, lift resolution quality and free your best agents for the hard cases. This anonymised case study walks through how BraivIQ approached exactly that engagement: the architecture, the guardrails, the rollout, and the lessons that generalise to any support automation.</description>
      <media:content url="https://images.unsplash.com/photo-1573164713988-8665fc963095?auto=format&amp;fit=crop&amp;w=1200&amp;q=80" medium="image" />
    </item>
  </channel>
</rss>
