thekb.eu — Architecture & Construction

Un SDLC piloté par l'IA : le cycle SFEIR à 11 phases (et pourquoi l'industrie y converge)

Tue, 16 Jun 2026 00:00:00 GMT

This SFEIR article formalizes an AI-driven software development cycle in **eleven phases (0 to 10)** and argues that the industry is converging toward this type of model. The starting point is a diagnosis: in 2025, organizations deployed AI tools without transforming their operating model, producing a paradox summed up by the phrase "everything changes… and nothing changes" — execution speed multiplies without a proportional gain. The real challenge, then, is not choosing the right tools, but **rethinking the software lifecycle** itself for machine-led execution. The SFEIR cycle chains together: **0 Setup** (stack detection, project memory initialization), **1 Define** (specification — human gate), **2 Plan** (architecture arbitration — human gate), **3 Build** (agent-driven development), **4 Verify** (automated testing and coverage), **5 Review** (four parallel audits: code, security, tests, performance), **6 Compound-1** (capturing lessons before deployment), **7 Ship** (production acceptance — human gate), **8 Ops** (monitoring and rollback), **9 Compound-2** (lessons from runtime) and **10 Deprecation** (retirement and capitalization). Three **immovable human gates** — Define, Plan, Ship — frame a set of otherwise automatic phases; two **compounding moments** (Compound-1 and Compound-2) turn lessons into reusable rules that feed subsequent cycles. Three principles structure the approach. First, **AI executes, it does not assist**: agents produce complete artifacts (code, tests, documentation) across entire phases, and a **proof-of-execution** discipline captures actual outputs — the system never trusts the agent's claims. Second, **the human retains control of intent** through the three gates: the human decides what to build, the machine optimizes execution. Finally, **the system learns cumulatively**, each cycle enriching the next. The results put forward support the thesis: a corporate site redesign that went from six months to one day, **−30% of correction iterations after ten cycles** (a bug reported twice becomes an automated rule), reviews across four parallel angles, an augmentation cost of about €10/hour, and a target of 850 fully AI-augmented consultants by the end of 2026. The article claims an **industry-wide convergence** with the ADLC (two gates, "intent verified exactly twice"), Google's whitepaper on the new SDLC (41% AI code, 85% of devs on agents), and DORA 2025 (AI as an "amplifier"). It finally delineates suitable use cases (back offices, APIs, migrations, automatically verifiable outputs) and unsuitable ones (unconstrained novel design, safety-critical systems awaiting standards, ungoverned data environments), and recommends starting with a rigorous specification gate and proof of execution. First installment of a seven-part series.

The End of Code Review: Coding Agents Supersede Human Inspection

Thu, 11 Jun 2026 00:00:00 GMT

In this position paper published on arXiv (software engineering category), Martin Monperrus defends a thesis that runs head-on against a founding practice of the SDLC: coding agents have reached a level of capability such that **human code review is no longer a necessary component of a quality pipeline**. The argument rests on two claims. First, a **parity — or even a superiority — of capability**: autonomous LLM-based systems fulfill all the traditional goals of review (finding defects, improving quality, ensuring compliance, sharing knowledge) at lower cost and with higher throughput, without human fatigue or inconsistency. Second, a **scaling problem**: the dominant hybrid model — the agent writes the code, the human reviews it — provides neither real quality assurance nor the ability to keep up with AI-assisted production velocity; above all, it generates a **false sense of security**. Monperrus situates his target historically, taking aim at inspection de Fagan (1976), and draws on the work of Bacchelli & Bird showing that review catches, in practice, fewer bugs than developers imagine. Benchmarks (SWE-bench, ~20-40% of issues resolved depending on the model, with rapid progression curves) serve as evidence of capability. In place of human review, he proposes a **multi-agent adversarial verification pipeline**: an agent generates the code; one or more independent reviewer agents inspect it (defects, security, style); a verification layer adds automated tests and formal methods; a consensus mechanism has several agents vote to accept or reject. The bottleneck of a single human reviewer is replaced by distributed, tireless inspection. The human does not disappear: they refocus on specification and high-level requirements, architectural trade-offs, oversight of critical domains, edge cases, and remain the final approval gate for sensitive systems. The author explicitly addresses the objections — hallucinations and prompt injection, the limits of automated testing (hence property-based testing), loss of domain expertise (offset by fine-tuning and RAG) — without dodging them. On the SDLC side, he links review to DORA metrics: speeding up review throughput speeds up deployment. His recommendations are pragmatic: pilot first on low-risk components, keep an initial hybrid workflow (agents flag, humans approve), measure agent-versus-human detection rates, make rejection decisions explicit, and build feedback loops. A deliberately provocative text, but a valuable counter-thesis to the dogma of the "inviolable human review gate".

The pattern lineage: Why fifty years of design patterns may hold the key to growing the architects AI cannot replace

Wed, 10 Jun 2026 00:00:00 GMT

Philippe Ensarguet (Orange) starts from a seemingly administrative question — designing an upskilling path toward the architect role — to articulate a deeper intuition. This role is critical to the "platformization" of a telecom operator (bringing together the IT and network worlds, separated for decades, into programmable platforms). Yet it becomes critical at the exact moment its training pipeline is breaking down: demand for architects is rising (platforming, cloud-native, IA agentique shift complexity from components to the relationships between them), while the talent supply chain is dismantling itself. The traditional path ran through years of writing code; AI now absorbs an increasing share of that work. If the entry-level work that once forged architects is delegated to machines, where will the next generation come from? The answer, according to Ensarguet, has been sitting on the shelf for fifty years. He returns to the original meaning of a pattern, as defined by building architect Christopher Alexander (1977): a named, recurring solution to a problem within a context, including the forces in tension and the consequences. It is not a recipe — it is transmissible judgment. The Gang of Four book (1994), which emerged from the Hillside Group convened by Kent Beck and Grady Booch, gave the industry its first shared vocabulary — its lasting value being the format (problem, context, forces, solution, consequences), not the 23 patterns themselves. Ensarguet traces a genealogical tree: POSA (1996), Fowler (2002), Hohpe & Woolf (2003), Nygard (2007, Circuit Breaker), the cloud catalogues (2012+), microservices and Kubernetes (2018-2019), up to the agentic corpora now taking shape (Anthropic's "Building Effective Agents," Andrew Ng's four patterns, the two-axis framework by Huang & Zhou in 2026 — echoing the GoF's two axes thirty years earlier). Beneath the catalogues, six invariant forces persist: coupling/cohesion, abstraction boundary, failure isolation, state governance, indirection, feedback loop — joined by a seventh, the non-determinism introduced by agentic systems. This "pattern literacy" is the resilient skill, and the only one that finally bridges IT and network (control plane / user plane = indirection; network slicing = Bulkhead; intent-based networking = feedback loop). AI then becomes an ally: freed from implementation, training can become deliberate — the machine produces options, the human supplies the judgment. What must be taught is the grammar, not the catalogues: catalogues age; the way of thinking they encode does not. Ensarguet is publishing this thesis precisely to stress-test it through debate.

How AI Changes the SDLC: A Six-Stage Guide

Mon, 08 Jun 2026 00:00:00 GMT

This Augment Code guide, written by Paula Hingel, proposes a **six-stage** model for understanding how AI agents are restructuring the software development lifecycle. Its central thesis: AI does not uniformly improve the SDLC — it raises throughput in some stages while increasing instability risk in others. This imbalance is not a technological inevitability but the symptom of uneven adoption carried out **without redrawing review boundaries**. The article draws on the **DORA 2025 report**, which establishes a positive correlation between AI adoption and delivery throughput/product performance, but a **negative one with delivery stability**: process maturity matters more than the tool. The six stages are reread through this lens. (1) **Requirements & Planning**: the specification becomes the control mechanism that steers the agent; the human focuses on requirement quality and resolving ambiguity. (2) **Design & Architecture**: more decisions require explicit human review, to avoid "vibe architecting" — infrastructure or integration choices made in seconds, faster than governance can keep pace with. (3) **Implementation**: the developer shifts from writing code to orchestration, validation, and approval. (4) **Testing & QA**: the core risk is **circular validation**, where AI-generated tests confirm AI-generated code instead of verifying the actual requirement; a precise specification is the safeguard. (5) **Deployment**: throughput gains create stability risks, hence the need for strengthened rollback controls. (6) **Maintenance & Operations**: agents take on detection and remediation, while the human handles exceptions and hardening. Three structural risks are named: **erosion of the junior pipeline** (automating foundational tasks faster than junior roles are redesigned shrinks the future pool of seniors), circular validation, and governance gaps at scale. Mirroring these, three roles emerge: **Intent Engineering** (translating ambiguous objectives into testable specs), Agentic DevOps/Infra (orchestrating agents), and AI Governance/Assurance. The guide is backed by data: 70% of dev time spent understanding existing code, a CMU study (807 repositories) showing +30% static-analysis issues and +40% complexity, and Meta's DRS system (>10,000 changes landed during a code freeze). It closes with five operational recommendations: audit one stage before scaling, stress-test governance, make specification central, define explicit rollback policies, and redesign the junior role around review.

Solving the Identity Crisis for AI Agents

Thu, 21 May 2026 00:00:00 GMT

Engineering article published on **Uber**'s blog by six engineers (Matt Mathew, Prasad Borole, Meng Huang, Sergey Burykin, Gaurav Goel, Bayard Walsh) on **May 21, 2026**, laying out the **AI agent identity and access-control doctrine** deployed in production at Uber for several thousand internal agents. **Pivotal thesis**: existing identity models (human + workload) do not describe **agency** — *« an agent is best defined as an entity that is authorized to act for or in the place of another »* — and lose **provenance** across the hops of an agentic workflow. **Two operational problems identified**: (1) ***« Current Identity Model Doesn't Describe Agency »*** — delegation is the default mode, workflows are compositional (agents calling agents calling tools), behavior is dynamic (plans evolve based on intermediate results); (2) ***« Original Provenance Isn't Effectively Carried Forward Across Agents to Systems »*** — *« Execution context (originating user, intermediate agents) is dropped across agent hops. »* **Proposed architecture** as an extension of Uber's Zero Trust Architecture: **Agent Registry** (source of truth for agent↔workload mappings) + **AI Agent Mesh** (inter-agent data plane) + **STS (Security Token Service)** (issuance of short scoped JWTs) + **MCP Gateway** (policy enforcement point for tool invocation) + **AI Gateway** (mediation of external LLM calls with guardrails) + **SPIRE** (workload credential provider). **Cryptographic mechanics**: workloads fetch cryptographically signed **SVIDs (SPIFFE Verifiable IDs)** from SPIRE → the SDK requests a JWT from the STS via the workload identity → the STS verifies the agent's authorization against the Agent Registry → a short token (TTL on the order of minutes) is issued for a **specific single-hop destination** (targeted `Audience` claim). **Pivotal doctrine**: ***« Single-hop, short-lived tokens. Every JWT minted by the STS is intended for a single hop, with a specific Audience claim and a short time-to-live in the order of minutes. »*** **Actor-chain preservation**: multi-hop example with on-call engineer `user1` → Oncall Agent (Workload-1) → Investigation Agent (Workload-2) → MCP Gateway; the final JWT carries a verifiable **actor chain `[user1, oncall-agent, investigation-agent]`**, enabling tool-level access decisions based on the **full request history**. **Standardization**: a **Standardized A2A (Agent-to-Agent) Client** that automates STS exchanges and actor-chain propagation — *« the secure path is also the easiest path for developers to implement A2A calls »* — phased migration of legacy agents. **Production metrics**: ***« P99 latency for the STS Token Exchange API is consistently below 40 milliseconds »***, thousands of internal agents onboarded, a real-time observability dashboard tracing multi-agent sessions. **Long-term vision — three-layer framework**: (1) Identity & Trust Foundation (verifiable agent identity + delegation chains), (2) Dynamic Access Control (context-based permissions + human-in-the-loop), (3) Unified Enforcement Plane (centralized, observable policy). **Standards alignment**: the IETF **WIMSE** working group + draft `draft-klrc-aiagent-auth-01` *AI Agent Authentication and Authorization*, conceptually grounded in **OAuth 2.0 Token Exchange (RFC 8693)** and **SPIFFE/SPIRE** (CNCF graduated). The first reference publication from a non-AI-lab hyperscaler (logistics/mobility) that industrializes agent security at the infrastructure level, bridging the doctrinal gap between skills/harness frameworks (Vincent, Lattice, PROJ-AI) and enterprise-grade identity questions.

How the X Algorithm Actually Works in 2026 — and What That Means for Growth

Sat, 16 May 2026 00:00:00 GMT

Internal teardown report on the open-source release **`xai-org/x-algorithm`** (May 15, 2026) — the **For You feed** algorithm of **X (formerly Twitter)** in 2026, with four audience-tuned growth recommendation tracks (personal/founder, brand/company, generalized framework, client/consulting deliverable). **Pivot thesis**: ***« The famous 2023 weight table — replies count more than likes by a big multiplier — describes a system that no longer exists in this form. »*** The 2026 algorithm is a **transformer (Phoenix, Grok-1-derived)** that learns weights from your engagement history, scored against a **19-dimension multi-action surface**, gated by an offline content-understanding service (**Grox**). **The shape of scoring now matters far more than the numbers — and the numbers themselves are not in the public release**. **4-component architecture**: (1) **Home Mixer** (Rust, request-time orchestrator, hydrate → source → filter → score → select → filter); (2) **Thunder** (Rust, Kafka-fed in-memory store of recent posts, sub-ms lookups for in-network candidates); (3) **Phoenix** (JAX ML, two-tower retrieval + ranking transformer, ~Grok-1-derived); (4) **Grox** (offline, spam/safety/PTOS/banger classifiers + multimodal v5 embedder). **The 19 actions predicted by Phoenix** (key change vs. 2023): favorite, reply, repost, photo_expand, click, profile_click, vqv (video quality view gated by min duration), share, share_via_dm, share_via_copy_link, dwell, quote, quoted_click, follow_author, not_interested, block_author, mute_author, report, dwell_time (continuous). **Final score** = `Σ (weight × P(action))` modified by **3 structural multipliers**: (a) **OON_WEIGHT_FACTOR < 1** (out-of-network penalty), (b) **author diversity decay** `(1-floor) × decay_factor^position + floor` (exponential attenuation of repeated posts from the same author within a single render), (c) **video duration gate** (vqv only contributes if `video_duration_ms > MIN_VIDEO_DURATION_MS`). **Key caveat**: **no numeric weight value** (`FAVORITE_WEIGHT`, `OON_WEIGHT_FACTOR`, `AUTHOR_DIVERSITY_DECAY`, `MIN_VIDEO_DURATION_MS`...) is in the release — everything is `crate::params::*`, managed by an internal X feature-switch service for A/B testing. ***« Anyone telling you 'replies are worth N.N× more than likes in 2026' is fabricating a number that is not derivable from the OSS release. »*** **Key differences vs. 2023**: (1) removal of every hand-engineered feature (*« We have eliminated every single hand-engineered feature and most heuristics from the system »*); (2) a single model predicting 19 actions vs. multiple single-action models; (3) Grox separates content understanding from ranking; (4) new first-class signals (continuous dwell, gated vqv, follow_author, 3 share variants); (5) two-tower OON retrieval (vs. SimClusters+heuristics) with multimodal text+image+ASR-video embeddings. **Three layers of reach** (generalized framework): Eligibility (binary, Grox+filters) → Retrieval (probabilistic, two-tower ANN) → Ranking (continuous, weighted-sum + multipliers). **Two laws of mechanical growth**: (1) In-network is multiplicative, OON is additive; (2) The model's job is to predict you, not reward you. **Deliberate honesty boundary**: released Phoenix checkpoint = mini (2 layers, 4 heads, 256-dim, 537K sports-post corpus), not the production model; Thrift integrations stubbed (`panic!("Not implemented")` in `candidate_features.rs`); brand-safety lists, topic ID mappings, language penalties, ad-blending rules absent from the public release.

The Ontology Pipeline™, Refresh: Where We Were, Where We Are, and Where We're Headed

Mon, 04 May 2026 00:00:00 GMT

**Jessica Talisman MLS** (Semantic Engineer + Information Architect, 25+ years of experience, ex-Adobe RDF knowledge graphs + ex-Amazon information architecture, founder of **Ontology Pipeline Framework** + **Contextually LLC**) publishes on **Modern Data 101** (Substack, ~20,000 members) on **May 4, 2026** a major revision of her **Ontology Pipeline™** framework originally published in January 2025. **Pivot thesis**: since November 2022 (ChatGPT), demand for *semantic infrastructure* has exploded but has created **massive confusion** — *"vendors offering shortcuts that bypass essential foundational work, creating liabilities disguised as assets"*. The initial **5-step** pipeline (controlled vocabulary → metadata standards → taxonomy → thesaurus → ontology → knowledge graph) remains valid but **must be supplemented by 2 critical additions**: **(1) Governance** as ongoing engineering practice (not post-project documentation); **(2) AI Partnership** with a clear distinction between augment and replace. **Market diagnosis**: *"a structurally invalid taxonomy is not a taxonomy"*, *"lists are not knowledge infrastructure"*, AI-generated taxonomies sold as strategy, vendors misusing the term *"ontology"*, cookie-cutter solutions presented as methodology. **Educational crisis**: demand for semantic engineers massively outstrips the supply of trained practitioners; the gap is filled by people *"who know vocabulary without methodology"*. **Explicit normative position**: *"AI that generates a taxonomy wholesale is producing a liability disguised as asset; AI that assists trained engineers is just plain smart."* **Acceptable AI roles**: entity extraction, gap analysis, drafting candidate vocabularies for review, population/validation support. **Unacceptable AI roles**: *wholesale taxonomy generation without human validation against standards*. **Referenced standards**: SKOS, OWL, RDF, SPARQL. **Credibility**: framework validated across **6 institutions over 10 years**. **Recommendations for 3 audiences**: (a) Organizations — invest in formal education, treat knowledge infrastructure as AI backbone, governance as ongoing, AI as an accelerator not a replacement; (b) Practitioners — competency questions before modeling, validate against SKOS/OWL/RDF, definitional difficulty signals pause, maintenance continues; (c) Leaders — workforce upskilling without self-funded education, allocate resources to knowledge infrastructure as a strategic necessity, governance before deployment. **Striking quotes**: *"the work cannot be skipped"*, *"governance is the engineering practice that keeps an ontology coherent across change"*, *"teaching this is hard. Learning it is harder."* **Major relevance** for data leaders / CDOs / architects building the semantic foundations of their AI agents. To be connected with: Seale Semantic Agent (2026-04-17) — *(Model+Harness)+(Ontology+Data) — ontology as the only moat*; Foundation Capital Context Graphs (2025-12-22); Bain part 2/5 *redesign data foundations for agent readiness* (2026-05); DORA ROI 2026 *AI-accessible internal data + healthy data ecosystems* (2026-04-21); Habert PROJ-AI six-zone doctrine (2026-05-05). Convergence with the 2026 *"data foundations as moat"* corpus.

There is a growing disconnect in the way people think about building AI agents

Fri, 17 Apr 2026 00:00:00 GMT

Tony Seale, The Knowledge Graph Guy, identifies a growing disconnect in the way the industry builds AI agents. On one hand, the industry is investing heavily in orchestration frameworks: LangGraph, CrewAI, AutoGen, Semantic Kernel, OpenAI Agents SDK, AWS Bedrock, Google ADK — each with its own orchestration graphs, state machines, and routing logic. On the other, leading-edge practitioners have moved to the "powerful model in a powerful harness" paradigm (Claude Code, Codex, OpenClaw, Hermes). **The collapse of frameworks.** Early frameworks were necessary when models couldn't handle multi-step tasks on their own. Anthropic quote: "Every component in a harness encodes an assumption about what the model can't do on its own, and those assumptions can quickly go stale as models improve." Scaffolding built for a limited model handicaps an intelligent model. It should decrease over time, not accumulate. What remains is simple: a powerful model in a powerful harness. Many, interacting, collaborating. No framework required. **Isolated agents are not enough.** Access to the computer ≠ understanding. Give an agent 1000 documents: it searches, hopes, guesses. Multiply that by 50 agents without a shared world model and you get intelligence that is isolated but incoherent in combination. At enterprise scale, the information environment needs structure — a shared domain model, with the human in the loop. **The symmetry.** The answer is to apply the same simplification on the data side. The model sits in a harness that gives it access to the computer; the data sits in an ontology that gives it structure and meaning. The ontology defines what exists, its properties, its relationships — the interface through which agents understand data. Two symmetric patterns: (powerful model + powerful harness) and (powerful data + powerful ontology). **The Semantic Agent.** Their combination produces the Semantic Agent: (Model + Harness) + (Ontology + Data). It doesn't just generate, it starts to understand. Everything else is scaffolding — useful for a while, but bound to come down. **What you own.** Everyone has access to the same frontier models; anyone can build a harness. That's commodity, and it's thinning out every day. What is NOT commodity: your ontology, your domain model, the structured and linked knowledge that captures how your organization understands the world. Frameworks are a transitional phase. Models are rented. The only thing left to build — and that you own — is knowledge.

Building for trillions of agents

Sat, 07 Mar 2026 00:00:00 GMT

Aaron Levie, CEO of Box, publishes a strategic essay on the fundamental transformation of software in a world where AI agents become the primary users of every application. He observes that since late 2025, agents have crossed a decisive threshold: they now have their own sandboxed compute environment, can write and execute code, interact with APIs and CLIs, and manage their own files and long-term memory. This architecture, initially defined by coding agents (Claude Code, Devin, Codex, Cursor, Replit), has extended to all knowledge work with agents such as Claude Cowork, Perplexity Computer, Manus and OpenClaw, the latter running 24/7 in a persistent environment. Levie predicts that every employee will have numerous agents, with 100 to 1000 times more agents than people within a company, amounting to trillions of agents globally. Adapting Paul Graham's famous advice ("Make something people want"), Levie proposes a new paradigm: "Make something agents want". Agents will themselves choose the most suitable tools, without being influenced by traditional marketing. The major consequence: everything must become API-first. Without an API, a feature does not exist for agents. CLIs and MCP servers become indispensable. Levie cites Jared Friedman of YC, who warns that tools that do not allow sign-up via API are "dead to agents". Business models must also evolve: the per-seat model no longer suffices when an agent can accomplish hours of human work in a few lines of text. Models based on consumption and volume will be needed, potentially even allowing agents to manage their own payments. Levie then describes the infrastructure ecosystem required: sandbox environments (E2B, Daytona, Modal, Cloudflare), file management (Box), identity and email for agents (Agentmail), web search (Parallel, Exa), payments (Stripe, Coinbase), and potentially microtransactions. Security, compliance and governance become major issues when agents handle sensitive data in regulated workflows (pharma, banking). Agents will need their own identities with strict controls over their actions and data access. In conclusion, Levie states that we are entering a new era of software in which tools must be designed specifically for agents operating at an unprecedented scale.

Introducing Markdown for Agents

Thu, 12 Feb 2026 00:00:00 GMT

Cloudflare announces a new feature that automatically converts HTML content into Markdown in real time, specifically designed for AI agents. The starting observation is simple: HTML is extremely inefficient for consumption by language models. A simple heading that requires 3 tokens in Markdown consumes 12 to 15 in HTML. At the scale of a full web page, the conversion delivers an 80% reduction in the number of tokens used, with direct gains in cost and latency. The mechanism relies on HTTP content negotiation, an existing web standard. When an AI agent sends a request with the `Accept: text/markdown` header, Cloudflare's edge network intercepts the origin server's HTML response and converts it on the fly into Markdown before returning it to the agent. This approach is particularly elegant because it requires no modification on the origin server side: everything happens on Cloudflare's infrastructure. The article also presents the Content Signals framework, which allows website publishers to express their preferences regarding the use of their content. Three signals are defined: `ai-train` (training permission), `search` (indexing for search) and `ai-input` (use as input by AI agents). This mechanism gives publishers granular control over how agents interact with their content. The authors point out that popular coding agents such as Claude Code already send the `Accept: text/markdown` header, which reflects organic adoption of this approach. For more complex use cases, Cloudflare offers complementary alternatives: Workers AI with the `AI.toMarkdown()` method for programmatic conversion, and the Browser Rendering API for pages requiring JavaScript rendering. Cloudflare Radar makes it possible to track markdown usage patterns across different AI crawlers, offering valuable visibility into the evolution of this ecosystem. In addition, Cloudflare is launching a Toolshed bringing together more than 400 MCP (Model Context Protocol) tools, positioning itself as a central platform for AI agent tooling. The feature is available in beta for subscribers to the Pro, Business and Enterprise plans. This initiative is part of a broader trend in which web infrastructure adapts to serve not only human browsers but also autonomous AI agents, which are becoming major consumers of web content.

AI's trillion-dollar opportunity: Context graphs

Mon, 22 Dec 2025 00:00:00 GMT

Jaya Gupta and Ashu Garg of Foundation Capital develop a thesis on the emergence of a new generation of systems of record centered on decision traces rather than traditional business objects. The previous generation of enterprise software created a trillion-dollar ecosystem by becoming systems of record: Salesforce for customers, Workday for employees, SAP for operations. The current question is whether these systems will survive the shift to AI agents. The authors agree with Jamin Ball's analysis that agents do not replace systems of record but raise their requirements. However, they identify a critical missing layer: decision traces. These capture the exceptions, waivers, precedents, and cross-system context that currently live in Slack, deal desk conversations, escalation calls, and employee memory. The fundamental distinction opposes rules (what should generally happen) to decision traces (what happened in this specific case, under which policy, with which exception, on which precedent). Agents need access not only to the rules but to the history of their application. "Systems of agents" startups have a structural advantage: they sit in the execution path. They see the full context at the moment of decision and can persist these traces as durable artifacts. The accumulation of these traces forms a "context graph": a living record of decisions linked across entities and over time, where precedent becomes queryable. Incumbents cannot build this context graph. Operational systems like Salesforce store the current state, not the state at the moment of decision. Data warehouses like Snowflake receive data via ETL after decisions are made, losing the decision context. The authors identify three paths for startups: replacing existing systems of record (such as Regie for sales engagement platforms), replacing specific modules (such as Maximor for finance), or creating new systems of record for categories of truth never captured before (such as PlayerZero for production engineering). Signals for identifying these opportunities include high headcount on manual workflows, decisions rich in exceptions, and the existence of "glue" organizations (RevOps, DevOps, SecOps) that exist precisely because no system captures the cross-functional workflow.

Clouded Judgement 12.12.25 - Long Live Systems of Record

Fri, 12 Dec 2025 00:00:00 GMT

Jamin Ball publishes a contrarian analysis against the dominant narrative that agents IA would render traditional systems of record obsolete. His central thesis: agents do not replace these systems, they raise the bar for what a good system of record must deliver. The author begins by critiquing recurring statements claiming that "agents are the new system of record" or that "workflows are swallowing systems of record." While he acknowledges a kernel of truth in these claims, he warns against an overvaluation that could lead companies to eliminate what they need most: a reliable source of truth. Ball illustrates the fundamental problem with the example of calculating ARR (Annual Recurring Revenue). In a typical company, sales, finance, accounting, and legal teams may use different definitions and conflicting data sources for this same metric. This ambiguity, manageable when humans are involved, becomes critical when agents automate decisions. The fragility point of agent-driven workflows lies in their ability to pull the right value from the right system at the right time. If an early step in a quote-to-cash workflow retrieves the wrong price list, the wrong contract term, or a stale ARR figure, everything downstream will confidently automate the wrong thing. Ball proposes an evolutionary vision in which data warehouses and lakehouses become "truth registries" - registries of truth providing the semantic layers and governance frameworks agents need to operate safely. In this architecture, traditional SaaS interfaces lose importance while the underlying data infrastructure becomes critical. The author insists on a fundamental distinction: a system of record is not a product category but a canonical source of truth. This nuance shifts the perspective on what companies must build in the age of agents. The article also includes SaaS market data showing a median NTM revenue multiple of 4.9x, with high-growth companies commanding 14.5x versus 3.7x for slow-growth ones. This analysis was explicitly referenced by Foundation Capital in their thesis on context graphs as the starting point for their thinking on the evolution of systems of record.

Acontext: Context Data Platform for Cloud-Native AI Agents

Thu, 11 Dec 2025 00:00:00 GMT

Acontext is an open-source context data platform developed by the memodb-io organization, designed to build cloud-native AI agents. The project provides a complete infrastructure covering context storage, context engineering, agent observability, and self-learning through skill distillation from completed tasks. The architecture is designed for cloud-native environments: scalable and distributed infrastructure, multi-language support (Python and JavaScript/TypeScript), REST API and SDK, modular and extensible architecture, integration with major agent frameworks, and support for CI/CD workflows. Five features structure the platform. Context storage preserves the contexts and artifacts produced by agents. Context engineering automates the preparation and optimization of contexts injected into agents. Observability ensures tracking of agent tasks and collection of user feedback. Self-learning distills reusable skills from completed tasks, enabling continuous performance improvement. Finally, a unified dashboard offers complete visualization of all activities. On the adoption side, as of December 11, 2025, the project showed approximately 1,721 GitHub stars and 137 forks, with an active community on Discord, packages published on PyPI and npm, and multilingual documentation (8 supported languages). Targeted use cases include developing autonomous agents equipped with contextual memory, continuous performance improvement through learning, centralization of contextual data for multi-agent systems, and analysis and optimization of agentic workflows. The project's strengths lie in its comprehensive approach (storage + context engineering + learning within a single platform), its open-source nature with an active community, its cloud-native design, and its rich documentation. The opportunities are significant: Acontext could become a standard for agent context management, integrate more broadly into the AI ecosystem, target the enterprise market with professional support, and serve as a research platform for agent learning. Challenges remain real: a learning curve for new users, competition in an emerging market where several solutions are positioning themselves, performance management at scale, and protection of sensitive data contained within contexts. Acontext fills a significant gap in AI agent infrastructure by providing context engineering and self-learning capabilities essential to autonomous agents. The project deserves the attention of teams working on complex agentic systems requiring advanced context management and continuous learning.

Small Bets, Big Impact: Building GenBI at a Fortune 100 (Northwestern Mutual)

Sun, 23 Nov 2025 00:00:00 GMT

Asaf Bord, Engineering Leader at Northwestern Mutual (a 160-year-old financial services company), shares his experience building a **GenBI** (Generative Business Intelligence) system in an extremely risk-averse environment. The company's motto, "generational responsibility," imposes absolute stability, making AI innovation difficult to sell and to deploy. To succeed, Bord adopted a **"small bets" (incremental rollout)** strategy and a "Crawl, Walk, Run" approach. Instead of promising an all-knowing agent immediately, they started by targeting the BI experts themselves, then managers, using AI to accelerate their work rather than replace them. The technical architecture reflects this caution. Rather than letting AI generate complex SQL across the entire database (risky), they built a pipeline of specialized agents: 1. **Metadata Agent**: Understands the context of the question. 2. **RAG Agent**: First checks whether an **existing certified report** contains the answer. They found that 80% of BI requests simply consisted of finding the right report. Automating this delivers immense value with minimal risk. 3. **SQL Agent**: Steps in only if no report exists, to generate targeted queries. 4. **BI Agent**: Formulates the final answer. A key point of their success was the use of **real, "messy" data** from the start, involving business users in the research process. This validated real-world feasibility and created allies ("champions") within the company. In addition, the project was broken into 6-week sprints, each stage delivering standalone value (e.g., the metadata improvements for AI benefited the whole company), allowing management to keep control over the investment. Bord concludes with an economic reflection: AI challenges the "per-seat" billing model of SaaS software, since a single user can now produce the value of ten.

Empowering Support to Ship Code: Solving App Erosion

Sun, 23 Nov 2025 00:00:00 GMT

Lisa Orr, engineering leader at Zapier, presents how the company combats "app erosion" by empowering support teams to ship code. Using the Grand Canyon analogy - where natural erosion creates beauty over millions of years - she contrasts it with app erosion, which continuously degrades Zapier's 8,000+ integrations built over 14 years. The problem is critical: third-party APIs change constantly, creating a **backlog crisis** where tickets arrive faster than they can be resolved. This generates reliability issues, poor customer experience, and potential churn. Faced with this reality, Zapier launched two parallel experiments two years ago. **Experiment 1** transforms the support role: from simple triage to active bug fixing. The approach is cautious, with guardrails: focus on 4 target apps, mandatory engineering review, limited to app fixes. The motivation is strong because erosion represents a major source of bugs, support is eager to learn (many want to become engineers), and some members were already helping informally. **Experiment 2 - Scout** uses generative AI to accelerate fixes. The process begins with "dog fooding" (Orr herself fixes apps), observing engineers and support, and identifying pain points. Key discovery: **50% of the time is spent gathering the context** needed to understand the problem. Scout's architecture comprises three main components: 1. **Context Analyzer**: Automatically gathers tickets, error logs, API documentation, source code 2. **Diff Generator**: Creates fixes based on the analyzed context 3. **Test Generator**: Generates tests to validate the fixes The results are remarkable. The **merge request success rate reaches 97%**, with only 3% requiring minor modifications. Resolution time drops from **72 hours to a few minutes**. The cultural impact is profound: support feels valued, engineering is freed up for innovation, and the boundary between roles blurs. Orr emphasizes that this transformation is not merely a technical optimization but a strategic necessity. In an ecosystem where integrations are central and erosion is inevitable, the capacity for agile maintenance becomes a competitive advantage. Empowering support through AI represents a fundamental organizational evolution for surviving in a world of perpetually changing APIs.

What We Learned Deploying AI within Bloomberg’s Engineering Organization

Sun, 23 Nov 2025 00:00:00 GMT

Lei Zhang, head of technology infrastructure at Bloomberg, details how a 9,000-engineer organization deploys AI in a structured and effective way. With a massive, mission-critical codebase (financial markets), Bloomberg cannot afford chaotic adoption. Zhang distinguishes AI for "coding" (writing new features) from AI for **"Software Engineering"** (maintenance, operations). Bloomberg emphasizes this second, often-overlooked aspect, which carries high ROI: 1. **Uplift Agents**: Agents dedicated to migrations and mass security patches, capable of proposing explained patches across the entire codebase. 2. **Incident Response Agents**: During an outage, AI is used to instantly scan logs, telemetry, and configurations. Its strength lies in being "fast and unbiased" (unlike humans, who carry preconceptions about the likely cause). To manage this scale, Bloomberg applies the **"Paved Path"** principle: making the right method easy and the wrong one difficult. They built a centralized platform offering an AI gateway (Gateway), simplified PaaS deployment for internal tools, and above all an **MCP Hub** (Model Context Protocol) to share connectors and prevent every team from recreating the same tools. On the human side, Zhang notes that adoption is stronger among individual contributors than among managers. To address this, Bloomberg has integrated AI into the training curriculum for new hires. These "juniors" then become vectors of change, challenging seniors with new methods. Zhang concludes by noting that AI is changing engineering's **"cost function"**: certain tasks that were once expensive (migrations, documentation) become cheap, prompting a rethink of software development's usual trade-offs.

The Evolution from RAG to Agentic RAG to Agent Memory

Mon, 03 Nov 2025 00:00:00 GMT

In this technical article, Leonie Monigatti presents the architectural evolution from vanilla RAG (2020) to Agent Memory, tracing the progression in how AI systems access and manage external knowledge, with a focus on the bidirectional flow of information into and out of LLM context windows. **Vanilla RAG (2020): the foundation layer** Retrieval-Augmented Generation introduced single-shot retrieval from external knowledge sources. Simple architecture: offline storage + a single retrieval per query. Central question: "How to retrieve?" Semantic search via vector databases augments the LLM with relevant external information. Limitation: deterministic, single-pass retrieval, with no adaptive query refinement. **Agentic RAG: dynamic retrieval capability** The evolution introduces tool calls allowing the agent to determine whether additional information is needed. The pseudo-code illustrates the transition: ``` SearchTool available → The agent evaluates relevance → Multiple retrieval turns possible ``` The question shifts: "How to retrieve?" becomes "Should I retrieve?" The agent autonomously decides when and where to retrieve information. Retrieval becomes more strategic, contextual, and iterative. But operations remain read-only: information flows only into the context window. **Agent Memory: full data management** "The next logical step after the evolution from vanilla RAG to Agentic RAG." Introduces a WriteTool alongside the SearchTool. Major paradigm shift: read-write operations. The question becomes: "How is information managed?" The pseudo-code shows the transformation: ``` SearchTool (read) + WriteTool (write) → Bidirectional information flow → Persistent learning ``` Information flows in both directions: not only retrieval, but also storage and modification during inference. Agents' persistent learning capabilities are fundamentally changed as a result. **Demonstrated practical applications** **Personalized user experiences**: storing conversation history ensures continuity across sessions. User preferences and interaction patterns are persisted. **Automatic memory creation**: the system extracts and stores important details (preferences, dates, names) without an explicit user command. Proactive memory management. **Multi-source memory systems**: architecture supporting distinct memory types: - **Procedural memory**: workflows, know-how - **Episodic memory**: past interactions, context history - **Semantic memory**: facts, domain knowledge The separation enables specialized retrieval strategies per memory type. **New challenges introduced** The article, balanced in its treatment, highlights the challenges: **Memory corruption**: write operations can introduce errors and outdated information. Validation strategies are needed. **Management complexity**: versioning, conflict resolution, and retention policies become necessary. More power = more complex governance. **Privacy**: persistent storage raises questions of data retention, consent, and the right to be forgotten. **Paradigm shift summarized** The evolution represents a fundamental shift from retrieval-centered systems to full data management. RAG retrieved knowledge, Agentic RAG decided when to retrieve, Agent Memory manages the entire knowledge lifecycle. Key quote: "Agent memory represents paradigm shift from retrieval-focused systems to comprehensive data management." Framework progression: static augmentation → dynamic retrieval → persistent learning. Each stage builds on the previous capabilities by adding a layer of autonomy. Agent Memory enables agents to learn from interactions, build knowledge bases, and personalize responses based on accumulated experience. The transformation from a retrieval tool into a data management platform fundamentally redefines LLM agent architecture.

La Révolution AI4* : Analyse Stratégique de l'Impact de l'IA sur le Cycle de Vie de la Production Logicielle

Sat, 01 Nov 2025 00:00:00 GMT

Strategic deep-research analysis examining the fundamental transformation of the software industry through the "AI4\*" (AI for Everything) concept: systemic overhaul of the production value chain, a shift from a labor-intensive artisanal process to an automated, intelligence-guided industrial paradigm. **6 pillars transformed by AI** **AI4Project** (Project Management): Data-driven predictive estimation (Operum, Idealink generate plans in minutes) vs. "finger-in-the-wind estimation". Paradox: estimating AI projects themselves is notoriously complex - hidden costs (data, talent at $100-200k/year, GPU) $20k basic chatbot → $500k+ advanced systems. The NIST AI RMF becomes a *central* planning component (no longer optional) - managing new risks (algorithmic bias, security flaws in generated code, black-box transparency). **AI4UX** (Human-Machine Interaction): Generative design (Uizard, Moonchild, Figma generate wireframes/UI from natural-language prompts). Adaptive interfaces with real-time personalization. "Synthetic users" (AI agent personas) test prototypes instead of recruiting human panels - early feedback. The AI Design Framework redefines the UX designer's role: from "interface creator" to "human-agent interaction architect". **AI4Dev** (Development): **Vibe Coding** (Karpathy, February 2025) - natural language to describe the goal → AI generates code → iterative experimentation. Lowers the barrier to entry (non-programmers build apps), ultra-fast prototyping. BUT the **Vibe Coding Hangover** - code accepted "without being fully understood", exponential quality/security debt, "development hell". Creates the **"Vibe Check"** economy: CodeRabbit, Qodo AI review agents "fix bugs/defects introduced by vibe coding", scanning "AI slop". New role: developer → "guiding engineer". **AI4Ops** (Operations): AIOps (Gartner, 2016) applies AI to automate IT operations. Three-level evolution: (1) Predictive Maintenance (AI alerts humans) → (2) Automated Remediation (AI triggers a pre-written solution) → (3) **Autonomous Operations/Self-Healing Systems** (ultimate goal: autonomously diagnosing/resolving new problems without human intervention). Platforms: Dynatrace (preventive operations), ServiceNow (Predictive AIOps), Splunk, New Relic, IBM, OpenText. **AI4Data** (Governance): Duality - governance as a *prerequisite* for trustworthy AI AND a *domain* benefiting from AI automation. "Governance *for* AI": ungoverned data → biased/non-compliant AI. "AI *for* Governance": automatic discovery/cataloging, automated compliance (EU AI Act, GDPR), auto-generated documentation/audit trails, continuous quality/risk analysis. Production examples from Brazil: **Cielo** (agentic AI for autonomous money-laundering detection/chargeback analysis), **Zup StackSpot** (orchestration of AI agent fleets across the development cycle). **AI4Cloud** (Infrastructure): Double FinOps dichotomy. (1) "AI for FinOps" - automates right-sizing/anomaly detection/spend forecasting. (2) **"FinOps for AI"** (critical problem) - AI workloads have volatile/unpredictable cost profiles (GenAI training/inference/GPU). New metrics (cost-per-token vs. instance/hour), new constraints (GPU scarcity), a new mental model ("cost per outcome", "frugal architecture"). 5 optimization strategies: models, GPU (NVIDIA MIG, continuous batching), infrastructure (caching), data, commercial (Savings Plans, Spot instances). **GenAI Landing Zone** - reference architecture integrating the 6 pillars on a governed foundation (Foundation Guardrails, real-time cost observability, compliant sandboxes, AWS Step Functions orchestration). **Major cross-cutting strategic trend**: Transition from **Copilots → Autonomous Agents** (agentic workforce). Agents deployed for fraud detection (Cielo), synthetic users as UX testers, code review agents, AI4Ops self-healing systems. **4 interdependent strategic conclusions**: (1) Vibe vs. Check paradox (generation speed creates quality debt requiring AI governance), (2) Rise of the agentic workforce (orchestration of agent fleets), (3) FinOps-for-AI crisis (volatile costs bottleneck scaling), (4) Governance as critical path (the pilot-to-production gap = a governance gap, GenAI Landing Zone integrates compliance/cost/security by default). **4 recommendations for CTOs/CIOs**: Invest in governance before speed (guardrails before massive GenAI rollout), resolve the FinOps-for-AI crisis now (cost as a design metric, frugal architecture), prepare the organization for agents (transform roles: developers→guides, UX→interaction strategists, Ops→autonomous-systems managers), centralize to scale (centralized governance platforms + GenAI Landing Zone vs. disparate pilots).

Agent reliability: What's missing in Enterprise AI agent architecture?

Wed, 29 Oct 2025 00:00:00 GMT

Patrick Joubert, CEO of Rippletide, identifies a critical gap in enterprise AI agent deployment: 64% of technology leaders want to deploy agentic AI within the next 24 months (Gartner), but only 17% have actually deployed it in production. Root cause: **trust** — enterprises are not ready to delegate decision-making to systems they cannot fully control, explain, and govern. **Critique of the hyperscalers' blind spot** Microsoft (Azure AI Agent Service/Framework), Google (Vertex AI Agent Builder/Engine), and AWS (Bedrock multi-agent) dominate the landscape but share a blind spot: **decision governance**. Specific limitations: Azure lacks built-in decision orchestration and audit traceability (increasingly required by enterprises). Google Vertex AI leaves policy enforcement, guardrails, and decision logging largely up to the user. AWS Bedrock relies on the LLM as the de facto decision-maker rather than on a dedicated reasoning layer. **Shared architectural problem**: dependence on the LLM as de facto orchestrator — a single entity that both reasons and decides. Result: enterprises inherit **opaque decision pipelines** where the justification for an agent's choices is inaccessible. Without an explicit separation of reasoning / policy enforcement / execution → accountability collapses, and leaders hesitate to sign off on agentic systems that cannot be audited or explained. **Acknowledged hyperscaler strengths**: massive scalability (near-unlimited compute, global availability), rich ecosystems and integrations (toolkits, APIs, connectors), trusted infrastructure and support (security, compliance, SLAs), rapid innovation and model access. But infrastructure-level scale and compliance do NOT translate into decision-level governance. **The fundamental LLM limitation behind the lack of reliability** LLMs are probabilistic, tasked with predicting the next token. They were **never designed to reason** and deliver the best solution to a query. Extraordinary pattern recognition and language generation, BUT **no deterministic reasoning and no verifiable causality**. This architecture explains why agents hallucinate, go off the rails, make unexplainable decisions, and generate opaque outputs that cannot be traced or audited. **Gartner prediction**: **40% of agentic AI projects canceled by 2027** due to excessive costs, unclear ROI, and inadequate risk controls caused by the absence of possible governance. The market is consolidating: the next maturity phase hinges **not on bigger models, but on better, traceable decisions**. **Rippletide's Hypergraph Database solution** **Core innovation**: overcoming the inherent LLM limitations that prevent the deployment of reliable, compliant, and governable agents. All data is represented in a single **unified hypergraph**; the agent proceeds step by step, **genuinely reasoning** and evaluating the best decision at each step before executing. **3 enterprise-grade outcomes**: (1) **Reliability**: **hallucination rate <1%** for production agents (vs. purely probabilistic LLM approaches) (2) **Compliance by design**: **guardrails built into the database** are factored into every decision. The hypergraph architecture guarantees that certain parts of the graph are inaccessible → the agent always adheres to the rules. Guardrails are **tailored** to each enterprise's context and regulatory environment. (3) **Governance by design**: the agent is **auditable at any time**, all decisions are **traced and verifiable** through the hypergraph structure. **Decision Layer / Decision Core concept** **Critical layer of the Agentic Enterprise**: a dedicated reasoning layer, separate from LLM orchestration. Adds the rigorous decision logic and governance missing from earlier designs. Explicit separation of reasoning / policy enforcement / execution. **Use case 1: Autonomous Coding Agent** Generates code, fixes bugs, deploys software. Without governance: a risk (the database-wipe incident illustrated this). With the Decision Layer: it checks plans against a list of "safe actions," writes code and runs tests autonomously, production deployment requires human sign-off unless the change is low-risk, and it **remembers past incidents** through the hypergraph memory (it won't repeat a dangerous migration that previously caused an outage). It acts like a junior developer: takes initiative but knows when to ask for approval. Could eventually handle **entire SDLC workflows** from ticket to deployment (BCG prediction: future AI agents deploying tested applications through pipelines with human approval — the Decision Layer makes this safe and acceptable for CTOs/CIOs). **Use case 2: Autonomous Analyst Agent** Prepares analytical reports and recommendations. With the Decision Layer: it does in seconds what a team of analysts would take days to do, aggregating data from silos, applying business rules, producing the report, and **justifying every insight with traceable data**. Example: "Sales dropped 5% due to a stockout in Region X (ERP/CRM-sourced facts) → I recommend reallocating supply: Policy 14, mitigation plans." Instead of a black-box chart: an explanation. Reasoning **auditable by regulators and internal auditors** (critical in finance/healthcare). **Vision**: AI agents move from fragile prototypes → **trusted colleagues** running core business operations with the consistency, precision, and compliance of a seasoned professional.

TOON - Token-Oriented Object Notation: JSON for LLMs at half the token cost

Wed, 22 Oct 2025 00:00:00 GMT

TOON is an innovative data serialization format designed specifically to optimize calls to large language models. Unlike JSON, which requires verbose syntax with repetitive quotes and braces, TOON drastically reduces token consumption—a directly billable resource in LLM interactions. The project demonstrates reductions of 30 to 60% in tokens compared to JSON, with some scenarios reaching up to 65% savings depending on the structured data. The format's architecture merges concepts from YAML (indentation for hierarchy) with CSV (tabular format for uniform data). This hybrid approach proves particularly effective for repetitive structures—collections of identical objects where each record shares the same fields. The minimal syntax eliminates redundant delimiters, using only spaces to indicate nesting and commas for internal separations. Technically, TOON encodes critical metadata in array headers: `key[N]{field1,field2}:` indicates N elements with specified fields. This explicit approach improves validation by LLMs and facilitates parsing of complex structures. Benchmarks reveal a data retrieval accuracy of 86.6% versus 83.2% for JSON, demonstrating that compactness does not sacrifice model comprehension. Use cases range from analytical data exports to GitHub repository lists, including nested e-commerce orders. For organizations managing massive volumes of LLM requests, this optimization generates substantial savings on API costs, while developers benefit from syntax that is more readable than conventional binary compression. The project, created on October 22, 2025 by Johann Schopplich, represents a pragmatic response to a concrete economic problem: every token consumed in an LLM interaction has a direct financial cost. By halving JSON's verbosity while maintaining—or even improving—model comprehension, TOON offers an immediate competitive advantage for AI-intensive applications. The innovation lies in the balance between technical optimization and human readability. Unlike binary compression formats that become opaque, TOON remains interpretable, facilitating debugging and maintenance. This characteristic proves crucial in production environments where the transparency of data exchanged with LLMs becomes a governance and compliance concern.

MCP-UI: The Future of Agentic Interfaces (Conference Talk)

Sat, 18 Oct 2025 00:00:00 GMT

**Dual Problem and Solution** Liad Yosef (AI & MCP Lead at Monday.com, co-moderator of the UI work group) presents MCP-UI as a solution to a dual problem. First, text-based interfaces create walls of text for users. Second, and more critical, providers (Shopify, Airbnb, Amazon) **lose their identity** when they send only text - the chat decides how to display it, depriving them of their place in the value chain. MCP-UI allows each application to send "UI chunks" - pieces of their identity - preserving visual recognition and user experience perfected over years. **Technical Architecture and Security** MCP-UI is an **open protocol** + SDK for sending UI via MCP and standardizing host/UI communication. The architecture relies on **sandboxed iframes** guaranteeing security: the UI code does not access the host's origin, cannot steal cookies/memory, and communicates only via **post messages**. Three content types are supported: external URLs, raw HTML, **remote DOM** (a powerful concept separating structure definition from rendering - the same MCP server can send an identical response to different clients that will render it with their own components). **Communication Spectrum and State** MCP-UI defines a **communication spectrum** representing levels of UI responsibility over user actions: **(1) Notify** - UI executes a backend action and notifies the chat; **(2) Tool call** - UI requests triggering a specific tool; **(3) Prompt** - UI requests execution of a prompt; **(4) Intent** - UI sends the user's intent, the host decides what to do. This **islands** architecture (different UI islands composed within a single context) requires sophisticated state management across **4 levels**: agent context (for the agentic flow), internal app state (preferences, steppers via cookies/localStorage), backend (data not relevant to the agentic flow but needed for synchronization), and state shared between components. **Concrete Demonstration: Sprint Management** The demo shows an engineering manager asking "sprint status". Instead of useless text, MCP-UI returns an **interactive Monday widget** with a visual breakdown. Clicking "stuck tasks" → displays the task "implementing authentication" assigned to Sarah. Clicking "analyze" → the communication mechanism sends a prompt to the agent which, connected to Gmail via another MCP server, **fetches emails automatically** discovering Sarah is sick, Jordan knows the code. The widget injects a colorized analysis suggesting reassignment to Jordan. Clicking "reassign" → an intent message triggers an MCP tool call completing the flow. Crucially: **the provider did not build the Gmail integration** - the agent made the connection using existing context. **Multi-Layer Theming** To avoid a "compilation of third-party UIs" experience, MCP-UI supports **sophisticated theming**: custom CSS (Shopify already implements it), CSS variables, theme tokens, and **remote DOM** (the most powerful - remote UI rendered with host components, guaranteeing visual consistency while preserving the provider's structure/interactions). **Adopters and Ecosystem** Massive adoption already underway: **Shopify full deployment**, Postman, Goose, Libra chat (hosts); **Hugging Face** (all spaces expose MCP-UI), 11 Labs, MCP storefront (providers). Community SDKs in Ruby, Python, TypeScript, Go. Community project at **mcpui.dev** with complete guides. **Future Vision: Recomposed Fragmented Web** Transformative vision: today one opens 10 different tabs (Amazon, Calendar, Booking) for a single task (planning a birthday), each with a complex UI 90% of which is irrelevant. Future: a personal assistant composes **UI atoms** from providers - Google Calendar sends an event chunk, Amazon a product list chunk, Booking a listings+map chunk. No provider-to-provider integration is needed - the assistant has full context. Result: **deconstructible apps** into reusable components, Jarvis made accessible because integration overhead disappears. **Roadmap Challenges** Three major challenges: **(1) Auth/SSO** - currently state is baked into context/UI or in-UI auth, need for seamless SSO; **(2) Native clients** - ChatGPT/Claude going native, many do not support iframes/webviews, exploring an **abstract payload** convertible to HTML or native with **capabilities negotiation**; **(3) Standardization adoption** - technology ready, needs community momentum.

The AI Platform Shift: Redefining What Software Is, and How Leaders Should Respond

Wed, 15 Oct 2025 00:00:00 GMT

Philippe Ensarguet argues that artificial intelligence represents a fundamental transformation of software, comparable to previous major computing revolutions, rather than a simple incremental improvement. His analysis rests on the observation that every computing platform shift has radically redefined the very nature of software: from the mainframe era to personal computers, then to the web, to mobile, and now to AI. The central thesis is that platform shifts do not merely improve existing software but fundamentally rewrite how applications are designed, developed, and used. Each transition created new possibilities that were impossible or unthinkable within the previous paradigm. AI follows this historical trajectory by introducing qualitatively different capabilities. Ensarguet identifies five defining characteristics of AI-era software: it will be adaptive (adjusting its behavior based on context and user), composable (dynamically assembling modular capabilities), intent-driven (understanding goals rather than following explicit commands), context-aware (integrating complex situational information), and conversational (favoring natural dialogue over traditional interfaces). The article warns against the most common temptation for established organizations: simply adding AI to their existing workflows and products. This approach, according to Ensarguet, misses the opportunity to fundamentally reimagine what software can accomplish. He compares this mistake to early attempts to "port" desktop applications to the web without rethinking the user experience to leverage the web's unique capabilities. For technology leaders, Ensarguet recommends a strategy of proactive adaptation. Rather than waiting for established best practices to emerge, organizations must actively experiment with new interaction models and build AI-native architectures. This approach requires accepting the uncertainty and ambiguity inherent to platform transitions. The article highlights the structural advantage startups hold during these moments of transition. Unencumbered by legacy systems and established mental models, they can explore new possibilities more freely. Established companies must consciously overcome their organizational inertia to compete with this agility. The practical implications include the need to rethink the fundamental problems software seeks to solve, rather than simply optimizing existing solutions. Teams must explore new interaction paradigms where the user expresses intent and context rather than following predefined workflows. Systems must be designed to be flexible and adaptive from the outset. Ensarguet concludes with a powerful observation: "Platform shifts are inevitable. How quickly we adapt to them is not." This quote encapsulates the strategic imperative for technology leaders: recognizing that AI transformation is not optional, but that the timing and manner of adaptation can determine organizational success or failure. The future of software will not consist of improved versions of today's applications, but of fundamentally different applications that we are only beginning to imagine.

Everything you need to know about building ChatGPT apps

Fri, 10 Oct 2025 00:00:00 GMT

The Gadget team shares its experience report after several days of intensive development on OpenAI's new ChatGPT Apps SDK. The article details the three essential components of a ChatGPT application: an MCP server compliant with the Model Context Protocol, an extension enabling user interfaces to be displayed within conversations, and optionally an OAuth 2.1 server with OIDC for authentication. For building MCP servers, the article recommends using the Streamable HTTP transport rather than the SSE version presented in OpenAI's official examples. The provided examples use an in-memory session map that is unsuited to serverless platforms. The MCP Inspector is recommended for initial debugging, since ChatGPT's error messages are not very informative. Implementing OAuth 2.1 authentication represents a paradigm shift: unlike the usual practice of redirecting to an external provider such as Google, here the application itself must act as the OAuth provider for OpenAI. This requires implementing the OIDC discovery endpoints that allow ChatGPT to obtain tokens. The most innovative feature is the ability to serve interactive UI widgets to users. These widgets are in fact sandboxed iframes that load a static HTML document, cached at application installation time. This constraint mandates the development of client-side single-page applications, with no dynamic server-side rendering. The team recommends Vite for TypeScript compilation, bundling, hot-module-reloading and Tailwind support. A dedicated Vite plugin is available on GitHub. For communication with the backend from a widget, two approaches exist. The `window.openai` object injected by OpenAI allows MCP tools to be called with authentication handled automatically and visibility for the LLM into the interactions. The alternative via direct `fetch` requires handling authentication manually and loses the LLM's contextual awareness. CORS is a major challenge, with three distinct configurations to manage: MCP routes, OAuth 2.1 routes, and frontend assets. For the first two, a permissive `Access-Control-Allowed-Origin: *` header is recommended, since authentication already secures the calls. For widget assets, the origin `https://web-sandbox.oaiusercontent.com` used by OpenAI must be allowed. The article concludes that the ecosystem is still very young but promising, with ready-to-use templates available at Gadget to accelerate getting started.

From RAG to Rigor Mortis: Why Retrieval-Augmented Generation looks like dying

Wed, 08 Oct 2025 00:00:00 GMT

The article examines the potential decline of Retrieval-Augmented Generation (RAG) in the face of the rapid evolution of AI technology. The author explains how RAG emerged as a solution to the limited context windows of early AI models, enabling systems to retrieve and use relevant document fragments. However, with the rapid expansion of context windows in modern AI models (growing from 8K to potentially millions of tokens), RAG could become obsolete. The article highlights five key challenges of RAG that contribute to its potential decline. First, document chunking loses contextual meaning, artificially fragmenting information. Second, embedding technologies have inherent limitations in their ability to fully capture the semantic richness of content. Third, hybrid search adds unnecessary complexity to the information retrieval process. Fourth, reranking introduces additional latency and costs into the processing pipeline. Finally, managing RAG infrastructure is becoming increasingly complex and costly to maintain. The author argues that emerging technologies such as Claude Code demonstrate a shift toward direct, context-rich search, without complex retrieval mechanisms. Since AI models can now handle entire documents within their context windows, elaborate RAG infrastructure could become superfluous. This evolution represents a paradigm shift in how AI systems are designed and built. Rather than fragmenting and retrieving information, future systems will be able to process vast amounts of context directly, enabling a more holistic and nuanced understanding. The article notes that this transition has significant implications for organizations and developers who have invested heavily in RAG infrastructure. The skills required to build AI systems are evolving, shifting from complex retrieval engineering toward designing agentic systems capable of intelligently navigating large contextual spaces. The author suggests that organizations must prepare for this technological transition, recognizing that RAG was only an intermediate stage in the evolution of AI. Future systems will favor full-context understanding over fragmented retrieval. The central quote perfectly captures this perspective: "RAG was never the destination—it was a temporary detour." This statement encapsulates the idea that RAG was a pragmatic solution to technical limitations that are now being overtaken by rapid technological innovation. In conclusion, the article calls for a reassessment of current AI architectures and anticipation of emerging paradigms that will replace traditional RAG approaches.

CEA unveils ExpressIF 3: RISC-V AI SoC for Edge Computing

Wed, 01 Oct 2025 00:00:00 GMT

The CEA (Commissariat à l'énergie atomique et aux énergies alternatives) unveils **ExpressIF 3**, the latest generation of its **RISC-V-based AI system-on-chip (SoC)** designed for edge computing applications. The product represents a significant milestone for **European technological sovereignty**, offering an alternative to dominant American and Asian chip architectures while providing specialized **AI acceleration capabilities** for embedded systems. **RISC-V foundation: a strategic choice** The CEA's decision to rely on the **open RISC-V instruction set architecture** rather than proprietary ARM or x86 reflects strategic sovereignty considerations. The open nature of RISC-V allows **full control over chip design** without licensing fees or geopolitical dependencies. This approach is particularly important for European industries requiring guaranteed long-term access to chip technology, independent of international trade tensions. **AI acceleration architecture** ExpressIF 3 integrates **dedicated neural network accelerators** optimized for inference workloads typical of edge deployments. The architecture is designed for efficient execution of convolutional neural networks (CNNs), transformers, and other common AI models while maintaining **low power consumption**, critical for battery-powered devices. Performance targets applications requiring **real-time inference**: autonomous vehicles, industrial robotics, smart cameras, IoT sensors. **Edge computing focus** The design philosophy favors deployment **at the edge rather than in the cloud**. Rather than sending data to remote servers for processing, ExpressIF 3 enables **on-device AI inference**, reducing latency, improving privacy, and eliminating connectivity dependencies. This edge-first approach is increasingly important for applications requiring: immediate response times (autonomous vehicles), privacy preservation (medical devices), operation in connectivity-constrained environments (industrial settings). **Energy efficiency** A critical metric for embedded systems: **watts per inference**. ExpressIF 3 is optimized for **milliwatt-scale consumption** while maintaining acceptable performance. This efficiency is achieved through: specialized AI accelerators avoiding the inefficiency of general-purpose CPUs, aggressive clock gating reducing idle consumption, a memory hierarchy minimizing costly DRAM accesses, voltage/frequency scaling adapted to workload intensity. **Software ecosystem** Hardware alone is not enough — successful adoption requires a **complete software stack**. The CEA is developing: RISC-V toolchains and compilers, AI framework support (TensorFlow Lite, ONNX), driver stacks, development boards, reference designs, documentation and tutorials. Building the ecosystem represents a multi-year but essential effort for commercial adoption. **Target applications** Priority markets: **automotive** (ADAS systems, cabin monitoring, autonomous driving), **industry** (predictive maintenance, quality inspection, robotics), **IoT** (smart cameras, sensor networks, edge gateways), **medical devices** (portable diagnostics, monitoring equipment). Each domain prioritizes different trade-offs between performance, consumption, and cost. **European industrial strategy** ExpressIF 3 fits into the **broader European effort** toward technological independence. Dependencies on American cloud platforms and Asian chip manufacturing are identified as strategic vulnerabilities. French and European investments in domestic chip design and production aim to **reduce these dependencies** while building competitive domestic industries. **Competitive landscape** ExpressIF 3 competes with: Nvidia Jetson (high performance, higher consumption), Google Coral (TPU-based edge inference), Intel Movidius (computer vision focus), ARM SoCs with NPU. **Differentiation comes from**: the open RISC-V architecture, European origin offering sovereignty benefits, optimizations specific to target applications, competitive pricing enabled by the absence of ARM licensing. **Path to commercialization** The transition from research prototype to commercial product requires: partnerships with semiconductor foundries for manufacturing, engagement with system integrators and OEMs, certification processes for automotive/medical applications, competitive pricing despite lower volumes than industry giants. Success will demonstrate the viability of a **European path** in the critical field of AI hardware.

HOW CLAUDE CODE IS BUILT

Mon, 15 Sep 2025 00:00:00 GMT

Gergely Orosz's article offers a rare look into the development of Claude Code, Anthropic's AI-based development tool that has rapidly generated over $500 million in annual revenue. Through interviews with founding engineers Boris Cherny and Sid Bidasaria, as well as product lead Cat Wu, the article explores the genesis, architecture, and "AI-first" engineering approach behind this groundbreaking tool. Claude Code began in September 2024 as a simple prototype by Boris Cherny, initially capable only of identifying the music being played. The decisive breakthrough came from giving it access to the file system and bash commands, allowing it to explore codebases and answer questions by autonomously reading and following file imports. This discovery revealed a "product overhang": the model's capability already existed, but no product was fully harnessing it. The prototype quickly gained popularity within Anthropic, with 50% of engineers using it daily just five days after an internal test release in November 2024. Despite internal debate over keeping the tool as a competitive advantage, Anthropic decided to launch it publicly to deepen its understanding of model safety and capabilities. The team, initially just Boris alone, grew to about a dozen engineers by July, working with a high degree of autonomy and a focus on rapid prototyping. The usefulness of Claude Code extended beyond developers, with data scientists also adopting it for queries and visualizations. The tool contributed to a 67% increase in the number of pull requests at Anthropic, despite a doubling of engineering headcount, demonstrating a substantial productivity gain. Claude Code's technology stack is "on distribution" for the Claude model, using technologies the model already masters: TypeScript, React with Ink for the terminal user interface, Yoga for layout, and Bun for building and packaging. Remarkably, about 90% of Claude Code's code is written by Claude Code itself, illustrating a "dogfooding" approach taken to the extreme. The architecture favors simplicity, acting as a lightweight interface that exposes tools and UI hooks to the Claude model, which performs the bulk of the complex work. The team constantly refines the system, often removing code and simplifying prompts as new model versions are released. A crucial aspect is the permissions system, designed to prevent the AI from making irreversible changes without user consent. It offers granular control, allowing users to grant permissions once, for future sessions, or to deny them, with multi-level configuration options. The development process is characterized by extreme speed. The team ships 60 to 100 internal releases per day and one external release daily. Prototyping is exceptionally fast: Boris Cherny built about 20 UI prototypes for a "to-do list" feature in just two days, iterating rapidly based on prompts and feedback. This rapid iteration, made possible by AI agents, considerably accelerates the design and implementation of new features, fundamentally changing the pace of prototyping. Claude Code also introduces innovative terminal user-experience features, leveraging the interactive nature of LLM-powered terminals.

MCP remplace le navigateur : Voici comment les développeurs devraient se préparer

Mon, 15 Sep 2025 00:00:00 GMT

The Model Context Protocol (MCP) is redefining how AI agents interact with online services, marking a significant shift away from traditional user-centered web browsing. Peter Aideloje explores how MCP is poised to replace the browser, what this transition means for developers, and how they can prepare for it. MCP is an open protocol that allows AI agents to securely connect to, access, and interact with external tools, data sources, and APIs. Its primary purpose is to provide AI agents with structured, reliable access to context and functionality beyond their training data. Unlike web browsing, where humans interact with pages through a browser, MCP allows an AI agent to autonomously discover and invoke tools on a server, based on user input and the AI's objective. This approach provides direct, structured access to data or functionality without needing to parse HTML or simulate clicks, thereby reducing inconsistencies. MCP's potential to replace the traditional browser is driven by delegation to AI agents, direct interactions with structured functionality, intent-based execution, and growing AI adoption across the industry. Instead of browsing, filtering, and filling out forms, users will simply express what they want, and MCP will enable assistants to carry out these tasks. For developers, particularly frontend engineers, the rise of MCP means a radical shift in how digital experiences are designed. Instead of building pixel-perfect user interfaces for humans, developers will need to build AI-oriented "websites": MCP servers that expose functionality in a way assistants can understand. These servers do not deliver HTML and CSS, but instead define clear schemas made up of tools (functions the AI can call), resources (structured, read-only data), and prompts (reusable templates that guide the assistant's interaction with users). Schema precision replaces layout polish. Security is also evolving, shifting from human-centered models to AI-mediated interactions, requiring rethinking of permissions, trust boundaries, audit trails, and rate limiting. MCP APIs must be designed with machine understanding as a priority, with stricter contracts, explicit error handling, and richer metadata. To prepare, developers should become familiar with how MCP servers work, design endpoints with clear intent, get accustomed to AI-driven UX patterns, expect more cross-functional collaboration, and get involved early to help shape the future. MCP offers opportunities for seamless user experiences and new UX paradigms, but also presents challenges around debugging AI behavior, ensuring reliability, and building trust.

Block's Goose and the Future of Agentic Interfaces via Model Context Protocol

Mon, 25 Aug 2025 00:00:00 GMT

Block's Goose blog publishes a deep dive into **MCP-UI**, a technology that, according to the team, does away with the "endless walls of text" of AI agent conversations. The article draws on an episode of the "Wild Goose Case" podcast bringing together the creators of MCP-UI, **Ido Salomon and Liad Yosef of Monday.com**, and **Andrew Harvard of Block**, to explore how this technology reshapes the future of agentic interfaces. **The text-only interface problem** Asking an agent for help with a purchase today results in a wall of text: product names, prices, descriptions, followed by copy-pasted URLs and multiple tabs — the user redoes all the work. As Ido Salomon puts it, everyone has experienced that "rage quit" moment in front of an assistant that returns nothing but text. These interfaces work for early adopters, not for the general public. **MCP-UI: protocol and SDK** MCP-UI (Model Context Protocol User Interface) makes it possible to embed **rich, interactive web components** directly into agent conversations. The underlying philosophy is simple: why discard decades of web UI/UX expertise when it can instead be augmented with AI? Liad Yosef notes that more than a decade of web interfaces refined for human cognitive limits should not disappear with the rise of agents. The system leverages the embedded resources of the MCP specification: an MCP server can return UI components instead of plain text. Four key contributions: rich components (catalogs, seat maps, forms), **brand preservation** (Shopify keeps its own experience), secure integration, and **cross-platform compatibility**. **Technical foundations** Security is paramount: components are rendered in **sandboxed iframes** that communicate with the host only via post messages, preventing third-party code from manipulating the parent application. Three content types are supported: external URLs, raw HTML, and remote DOM (rendered in separate workers). Getting started is minimal: `createUIResource({ type: 'html', content: '<h1>Hello World</h1>' })`. **Demonstrations and ecosystem** The demos show visual shopping (interactive Shopify catalog with add-to-cart), trip planning (seat selection on a visual map, automatic destination weather), and restaurant discovery (cards with photos, ratings, menus, direct ordering) — all without leaving the conversation. Success rests on four stakeholder groups: agent developers (such as the Goose team), MCP server developers, service providers (Shopify, Square), and end users. The approach creates a **network effect**: a component implemented once works across all compatible agents. **Vision** Beyond prettier interfaces: an **accessibility revolution** ("what could be more accessible than an agent that knows you and builds the UI to your preferences?") and, eventually, **generative UI** producing interfaces tailored to each user's needs.

MCP-UI: The Future of Agentic Interfaces

Mon, 25 Aug 2025 00:00:00 GMT

**The Problem with Purely Textual Interfaces** Traditional AI agent interfaces suffer from a fundamental limitation: they force users to consume all information via text responses. When requesting product recommendations, trip planning, or restaurant searches, users receive overwhelming walls of text with descriptions, links, and data requiring manual copy-pasting and tab-juggling. This defeats the purpose of having an intelligent assistant and creates a poor user experience, especially for non-technical users. The text-only approach works for early adopters but creates barriers to mainstream adoption, limiting agents' usefulness for everyday tasks. **MCP-UI Technical Architecture** MCP-UI (Model Context Protocol User Interface) is both a protocol and an SDK enabling the integration of rich interactive web components directly into AI agent conversations. The system leverages the embedded resources of the MCP specification, allowing MCP servers to return interactive UI components rather than plain text. These components are rendered in **sandboxed iframes** that communicate with the host application solely via secure post messages, ensuring that third-party code cannot access or manipulate the parent application. The implementation supports **three content types**: external URLs (existing web apps in iframes), raw HTML (custom HTML with CSS and JavaScript), and remote DOM (UI rendered in separate workers for enhanced security). Developers can start with simple HTML resources and progressively enrich them with interactive features. **Key Benefits and Use Cases** MCP-UI preserves decades of web UI/UX expertise while augmenting it with AI capabilities. It maintains brand identity for companies like Shopify, provides seamless cross-platform compatibility across different AI agents, and creates a **network effect** where UI components work universally once implemented. The technology addresses accessibility by enabling agents to build interfaces tailored to individual preferences and needs. It also creates standardization, eliminating the need for separate integrations for each AI platform. **Concrete Demonstrations** Three compelling examples: **(1) Visual Shopping** - Shopify catalogs with images, prices, and interactive elements where clicking adds items to the cart; **(2) Trip Planning** - visual airplane seat selection maps with automatic weather lookup for destinations; **(3) Restaurant Discovery** - local restaurant browsing with photo cards, ratings, menus, and direct ordering capabilities, all within the conversational flow. **Future Implications** MCP-UI points toward an **accessibility revolution** where agents build personalized interfaces, **generative UI** creating tailor-made experiences for individual users, **multi-modal experiences** extending beyond the visual into voice and native mobile components, and **cross-platform standardization**. The current challenge is adoption rather than technical feasibility, with major players like Shopify already implementing MCP support across all their stores. **Technical Implementation Details** The stakeholder ecosystem involves four groups: agent developers implementing MCP-UI support, MCP server developers building UI components, service providers creating rich interfaces, and end users benefiting from intuitive interactions. Getting started requires minimal code - developers can begin with basic HTML resources like `createUIResource({ type: 'html', content: '<h1>Hello World</h1>' })` and expand from there. The technology is already supported in Goose and available via comprehensive documentation and an active Discord community. MCP-UI represents a fundamental shift from text-heavy AI interactions toward rich, visual, and intuitive experiences that bridge the web as we know it and the agentic future under construction.

Model Once, Represent Everywhere: UDA (Unified Data Architecture) at Netflix

Thu, 12 Jun 2025 00:00:00 GMT

Netflix presents UDA (Unified Data Architecture), a groundbreaking infrastructure based on a knowledge graph to address the chronic fragmentation of data models across its Content Engineering ecosystem. The fundamental problem: core business concepts such as "actor" or "movie" are independently redefined in each system (GraphQL Gateway, asset management, media computing), creating duplication, terminological inconsistencies, quality issues, and limited connectivity. **Foundational architecture: RDF/SHACL knowledge graph** UDA adopts RDF and SHACL as technical foundations, but confronts major operational challenges at enterprise scale: RDF lacked a usable information model, SHACL was not designed for enterprise data with local schemas and typed keys, teams lacked shared authoring practices, and ontology tooling offered no support for collaborative modeling. Solution: a "named-graph-first" information model in which each named graph conforms to a governing model, itself a named graph within the knowledge graph. **Upper Metamodel: the model of all models** Upper constitutes the formal language for describing business domains or systems, organizing concepts into domain models: controlled vocabularies defining key entity classes, attributes, and relations. Crucially, Upper is a bootstrapping upper ontology: self-referential (it models itself), self-describing (it defines the concept of a domain model), self-validating (it conforms to its own model). Upper projects to a Java Jena-based API and a federated GraphQL schema in the Enterprise Gateway. Since all domain models are conservative extensions of Upper, seamless runtime integration guarantees consistent data semantics. **Mappings and projections: connection and automation** Mappings connect domain model elements to data container representations (GraphQL resolvers, Data Mesh sources, Iceberg tables). Everything is addressable: from the domain model down to the specific attribute, from the Iceberg table down to the individual column. Mappings enable bidirectional discovery: from the business concept to the physical system storing the data, and vice versa. Projections produce concrete containers implementing characteristics derived from the registered domain model, with automatic transpilation to GraphQL/Avro schemas preserving semantics. **Production adopters: PDM and Sphere** PDM (Primary Data Management) manages authoritative controlled vocabularies using the SKOS (W3C) model. It takes a domain model as input, automatically generates the UI, and provisions Domain Graph Services and Data Mesh pipelines via UDA projections. Consuming vocabularies are unaware of SKOS—they work with familiar domain terminology. Sphere: a UDA-powered self-service operational reporting system. Discovery happens via business concepts ("actors", "movies"), not technical tables. The UDA knowledge graph generates SQL queries via graph traversal, eliminating manual joins and technical mediation. Aggregated metadata is presented with unified vocabulary, and data landscape boundaries and islands are identified automatically. **Transformational impact** UDA turns conceptual models into an active control plane: it not only documents concepts but generates schemas, provisions services, orchestrates data movement, and enforces consistency automatically. Future developments: Protobuf/gRPC support, materialization of instance data into the knowledge graph, and resolution of the original Graph Search challenges that inspired this work.