Modern UAV systems increasingly face a mismatch between how humans specify goals and how machines execute them. Engineers often describe missions in natural language such as “check for fires near the industrial zone,” while traditional drone pipelines expect structured inputs like GPS waypoints or precomputed maps. UAV-CodeAgents paper presents a system designed to close that gap by treating mission planning as a reasoning problem rather than a purely geometric one. Instead of hardcoding paths or relying on static heuristics, the system uses a combination of large language models and vision-language models to interpret instructions and satellite imagery together, producing actionable flight plans with minimal human intervention.

This system reframes UAV mission generation as a distributed, multi-agent process. Rather than a single monolithic planner, it introduces multiple specialized agents that collaborate through structured communication. One agent plays the role of a central planner, interpreting user intent and analyzing visual inputs, while other agents represent the UAVs themselves, executing tasks and feeding observations back into the system. This separation mirrors how modern AI applications are increasingly built: a reasoning layer that plans and decomposes tasks, combined with execution units that operate in the real world and provide feedback.

The most important design pattern underlying the system is the use of the ReAct paradigm, which interleaves reasoning and action. Instead of planning everything upfront, the agents operate in a loop where they observe the environment, describe it using vision-language models, reason about what it means in the context of the task, decide what to do next, and then act. This cycle repeats continuously, allowing the system to adapt to new information. For software engineers, this is essentially a production-grade implementation of an agentic feedback loop, where inference is not a single pass but a persistent process that updates state over time.

A key technical challenge addressed in this system is grounding language in spatial data. It is not enough for a model to understand a phrase like “warehouse near the forest.” The system must map that phrase to exact pixel coordinates on a satellite image so that a UAV can navigate to the correct location. An innovative pixel-pointing mechanism helps to achieve this goal. A vision-language model is fine-tuned on annotated satellite imagery so that it can associate semantic descriptions with precise positions in an image. This allows the system to convert unstructured language into structured spatial targets, which can then be used for path planning.

The architecture also reflects a clear separation between high-level cognition and low-level execution. The central agent performs task decomposition and planning, breaking down natural language instructions into smaller steps such as searching, localizing objects, and verifying conditions. The UAV agents, on the other hand, are responsible for following these plans, collecting images, and performing lightweight reasoning during execution. This division enables both scalability and robustness. New UAVs can be added dynamically, and different agents can run models of varying complexity depending on resource constraints.

Another important aspect is the system’s emphasis on iterative refinement. UAV agents continuously collect observations during flight, such as images or inferred labels, and send them back to the central planner. The planner uses this feedback to update its understanding of the environment and adjust the mission accordingly. For example, if a suspected fire is not clearly visible, the system may redirect a drone to capture additional evidence from a better vantage point. This dynamic adjustment is critical for operating in real-world environments where conditions are uncertain and incomplete.

This system is evaluated on fire detection scenarios using satellite imagery. Instead of giving precise instructions, they use vague prompts like “there are fires in our area,” forcing the system to infer intent and identify relevant locations. The evaluation shows that the system can interpret ambiguous input, localize potential fire sites, and generate UAV trajectories that prioritize high-risk areas. This highlights an important capability for AI applications: reasoning under uncertainty and translating vague human intent into concrete actions.

The experiments also reveal practical insights about model behavior. One notable finding is that lower sampling temperature improves performance in this context. With a temperature of 0.5, the system produces more consistent plans, completes tasks faster, and achieves higher success rates compared to a higher temperature setting. This aligns with a broader principle in AI engineering: when reliability and determinism matter more than creativity, controlling randomness during decoding becomes essential. In this case, reducing variability helps ensure that coordinated multi-agent behavior remains stable.

Another technical contribution is the fine-tuning of a vision-language model on a custom dataset of satellite images. This improves the model’s ability to perform spatial grounding across different categories such as roads, buildings, and farmland. The results suggest that the model can handle both dense and sparse visual features, which is important for real-world deployments where environments vary widely. For engineers, this emphasizes the value of domain-specific data when building multimodal systems, especially when precise localization is required.

The system is also designed with scalability in mind. It supports adding or removing UAV agents on the fly, running heterogeneous models across agents, and transitioning from simulation to real-world deployment. A lightweight simulation environment allows developers to test navigation and perception logic without needing a full physical setup. This reflects a practical approach to building AI systems: start with simulation to iterate quickly, then gradually move toward real-world integration.

This system demonstrates how combining large language models, vision-language models, and multi-agent coordination can turn high-level instructions into executable plans in complex environments. Software engineers would appreciate this architectural pattern. The system shows how to build AI applications that integrate perception, reasoning, and action in a continuous loop, grounded in real-world data. It highlights the importance of modular design, iterative feedback, and domain-specific grounding, all of which are increasingly relevant as AI systems move from isolated inference tasks to end-to-end autonomous workflows.

References:

1. Sautenkov, O. (2025): UAV-CodeAgents: Scalable UAV Mission Planning: https://arxiv.org/pdf/2505.07236 

 This is a summary of the book titled “A Minute to Think: Reclaim Creativity, Conquer Busyness, and Do Your Best Work” written by Juliet Funt and published by Harper Business in 2021.

Modern work culture often treats constant activity as a virtue, yet sustained busyness can undermine judgment, creativity, and well-being. The central insight here is that people do their best work not by filling every moment, but by deliberately creating intervals of white space: short or long pauses used to think, recover, reflect, or create. These pauses are not procrastination, aimless idleness, or distraction. They are purposeful moments that allow the mind to reset and reengage with greater clarity. Even a brief pause before a conversation, between meetings, or prior to answering a request can improve attention and decision-making.

The argument begins with a challenge to the assumption that productivity is measured by visible effort alone. Many people now feel pressure to stay busy at all times, crowding every spare minute with messages, media, errands, and low-value tasks. This habit leaves too little room to digest information, weigh alternatives, solve problems, or rest. Several forces reinforce the pattern: the belief that nothing is ever enough, the tendency to imitate other people’s frantic pace, tolerance for wasteful work, and a culture of urgency that makes nearly everything feel immediate. Over time, these pressures produce overload rather than excellence.

The case for white space rests in part on how the brain works. Higher-order thinking tires under continuous demand, and cognitive fatigue lowers focus, accuracy, engagement, and creativity. Breaks help the mind recover and strengthen the connections needed for memory, insight, and sustained concentration. Not all pauses are equally restorative. Activities that continue to tax attention, such as checking more messages or switching to another demanding task, extend the strain rather than relieve it. More useful pauses involve quiet reflection, movement, conversation, or simple mental rest. Contrary to the common belief that pressure sharpens innovation, creativity tends to suffer when time pressure becomes extreme.

From that foundation comes a practical method for reclaiming attention. One approach is to identify the habits that masquerade as strengths but become destructive in excess: drive becomes overdrive, commitment to excellence becomes perfectionism, the desire to stay informed becomes information overload, and healthy activity becomes frenzy. A useful countermeasure is a small buffer between one action and the next: a pause after finishing a task, before responding to criticism, between meetings, or before checking email out of habit. Those small intervals create enough distance to question whether a task is necessary, whether good enough is sufficient, what information is truly needed, and what deserves attention now. Applied consistently, this way of thinking changes communication as well. It encourages fewer, clearer emails, more deliberate use of live versus text-based conversations, and meetings that are more selective, more intentional, and separated by enough time to absorb what happened. The same principle extends beyond work. A less crowded schedule at home makes room for attention, joy, and relationships, and children benefit when their time is not overmanaged. The broader conclusion is that better performance does not come from squeezing more into the day, but from protecting enough empty space for thought, recovery, and meaningful action.

#Codingexercise: Codingexercise-06-09-2026.docx

 

Modern AI applications often rely on large language models to generate answers, but these models are only as reliable as the information they can access. Retrieval‑augmented generation, or RAG, is a widely used way to improve reliability by pulling in relevant documents at runtime and conditioning the model on those documents before it produces an answer. In practice, however, the effectiveness of this approach is tightly coupled to how well the retrieval step works. If the system retrieves irrelevant or incomplete documents, even a strong model can produce weak or incorrect outputs.

This limitation becomes especially visible when dealing with multi-step or “multi-hop” questions. These are questions where the answer depends on combining facts from multiple sources rather than finding a single sentence in a single document. A simple RAG system treats the input question as one query, embeds it, and retrieves the top matching documents. That works well when all relevant information happens to live together, but it breaks down when the facts are scattered. In those cases, the retriever might return broad summaries or partially relevant material instead of the precise pieces of evidence required to construct the answer.

A paper on Question decomposition for RAG [1] treats complex questions not as a single retrieval problem, but as a collection of smaller, focused retrieval problems. Instead of querying the system once, the approach uses a language model to decompose the original question into several simpler sub-questions. Each sub-question targets a specific piece of the information needed. For example, instead of asking which company had the highest profit among a set of companies, the system asks separate questions about each company’s profit, which makes it much easier to retrieve exact, relevant data points.

This decomposition step significantly increases the chances that the system will find all the necessary evidence, because different documents often cover different aspects of a problem. However, it also introduces a new challenge: retrieving documents for multiple sub-questions produces a much larger pool of candidate passages, many of which are only loosely related or even irrelevant to the original query. The system therefore needs a way to filter and prioritize these results so that only the most useful pieces of evidence are passed to the language model.

To solve this, the approach adds a reranking stage after retrieval. The reranker is a more precise but more computationally expensive model that scores each candidate document based on how relevant it is to the original, undecomposed question. Unlike the initial retrieval step, which relies on vector similarity, the reranker jointly processes the query and the document, allowing it to capture finer-grained relationships between them. The system then selects the top-ranked documents and discards the rest.

The overall pipeline can be thought of as a three-step process. First, the system expands the query into a set of sub-queries using a language model. Second, it retrieves documents independently for each sub-query, merging all results into a single candidate pool. Third, it applies reranking to filter that pool and extract the most relevant passages. These final passages are then concatenated with the original query and passed into the language model for answer generation.

One of the key advantages of this approach is that it does not require training new models or building specialized indexes. It relies entirely on off-the-shelf components: a general-purpose LLM for decomposition, a standard dense retriever for initial search, and a pretrained cross-encoder for reranking. This makes it easy to plug into existing RAG systems with minimal engineering effort.

Empirical results show that this combination of decomposition and reranking provides meaningful improvements. On multi-hop benchmarks, the system retrieves more relevant evidence and produces more accurate answers compared to standard RAG. The gains come from a clear division of responsibilities: decomposition improves coverage by ensuring that different aspects of the problem are retrieved, while reranking restores precision by filtering noise from the expanded result set.

There are, however, trade-offs that matter for real-world systems. The largest cost comes from generating sub-questions with a language model, which adds noticeable latency. Reranking also increases computational load because it evaluates each query–document pair individually. While techniques such as caching can amortize some of this overhead, the approach is still slower than a naive single-query pipeline.

Another important limitation is that decomposition is not always beneficial. When a query is already specific and well-formed, breaking it into sub-questions can actually introduce noise and reduce performance. The quality of the decomposition also depends heavily on the language model and the prompt used to guide it. In addition, the system operates in a single pass, meaning it does not iteratively refine queries based on retrieved evidence, which could limit its ability to handle extremely complex reasoning chains.

For engineers building AI applications, the takeaway is straightforward. If your system struggles with questions that require combining information from multiple sources, simply improving embeddings or increasing the number of retrieved documents may not be enough. Instead, treating retrieval as a structured process—where you explicitly break down the problem and then carefully filter the results—can yield significant improvements without changing your underlying models. The combination of query decomposition and reranking offers a practical, modular way to do this while staying compatible with existing RAG architectures.

References:

1.      Question decomposition for RAG: [2507.00355v1 | PDF]: https://arxiv.org/pdf/2507.00355

 This is a summary of the book titled “A Minute to Think: Reclaim Creativity, Conquer Busyness, and Do Your Best Work” written by Juliet Funt and published by Harper Business in 2021.

Modern work culture often treats constant activity as a virtue, yet sustained busyness can undermine judgment, creativity, and well-being. The central insight here is that people do their best work not by filling every moment, but by deliberately creating intervals of white space: short or long pauses used to think, recover, reflect, or create. These pauses are not procrastination, aimless idleness, or distraction. They are purposeful moments that allow the mind to reset and reengage with greater clarity. Even a brief pause before a conversation, between meetings, or prior to answering a request can improve attention and decision-making.

The argument begins with a challenge to the assumption that productivity is measured by visible effort alone. Many people now feel pressure to stay busy at all times, crowding every spare minute with messages, media, errands, and low-value tasks. This habit leaves too little room to digest information, weigh alternatives, solve problems, or rest. Several forces reinforce the pattern: the belief that nothing is ever enough, the tendency to imitate other people’s frantic pace, tolerance for wasteful work, and a culture of urgency that makes nearly everything feel immediate. Over time, these pressures produce overload rather than excellence.

The case for white space rests in part on how the brain works. Higher-order thinking tires under continuous demand, and cognitive fatigue lowers focus, accuracy, engagement, and creativity. Breaks help the mind recover and strengthen the connections needed for memory, insight, and sustained concentration. Not all pauses are equally restorative. Activities that continue to tax attention, such as checking more messages or switching to another demanding task, extend the strain rather than relieve it. More useful pauses involve quiet reflection, movement, conversation, or simple mental rest. Contrary to the common belief that pressure sharpens innovation, creativity tends to suffer when time pressure becomes extreme.

From that foundation comes a practical method for reclaiming attention. One approach is to identify the habits that masquerade as strengths but become destructive in excess: drive becomes overdrive, commitment to excellence becomes perfectionism, the desire to stay informed becomes information overload, and healthy activity becomes frenzy. A useful countermeasure is a small buffer between one action and the next: a pause after finishing a task, before responding to criticism, between meetings, or before checking email out of habit. Those small intervals create enough distance to question whether a task is necessary, whether good enough is sufficient, what information is truly needed, and what deserves attention now. Applied consistently, this way of thinking changes communication as well. It encourages fewer, clearer emails, more deliberate use of live versus text-based conversations, and meetings that are more selective, more intentional, and separated by enough time to absorb what happened. The same principle extends beyond work. A less crowded schedule at home makes room for attention, joy, and relationships, and children benefit when their time is not overmanaged. The broader conclusion is that better performance does not come from squeezing more into the day, but from protecting enough empty space for thought, recovery, and meaningful action.

 Token Efficient Agentic Retrieval Augmented Generation Framework aka TeaRAG 

 

TeaRAG makes agentic RAG practical for real engineering workloads by attacking the two sources of waste that dominate today’s systems: bloated retrieval inputs and unnecessarily long reasoning traces. For software engineers building RAG-based applications, the framework treats token efficiency as a first‑class design constraint and reorganizes the entire agentic loop around that goal. 

 

Described in a paper published in ACM ISBN in 2025, the authors start from a simple observation: most of the tokens consumed during inference are not the final answer but the intermediate scaffolding. They assert that “the retrieved content constitutes the majority of the overall output,” and that agentic systems “generally adopt multi-step reasoning, even when addressing single-hop questions.” These two lines capture the core inefficiency. Chunk retrieval drags in far more text than is needed, and reinforcement‑learning‑based agents tend to overthink because their rewards only evaluate the final answer. 

 

TeaRAG restructures the agentic loop so that each retrieval step brings in only the highest‑density information available, and each reasoning step is rewarded only when it contributes meaningful progress. The retrieval side is handled through a hybrid mechanism that combines chunk-level semantic search with graph-level triplet retrieval. Instead of treating these as separate sources, TeaRAG merges them into a Knowledge Association Graph built from semantic similarity and co‑occurrence. Core relevant knowledge can form a dense graph structure connected by co-occurrence edges and this becomes the signal used to filter noise. Personalized PageRank is then applied to the graph so that the agent receives only the most relevant chunks and triplets, dramatically reducing the number of tokens per retrieval without sacrificing coverage. 

 

On the reasoning side, TeaRAG introduces a training method called Iterative Process‑aware Direct Preference Optimization. The key idea is that the model should not be rewarded solely for producing the right answer; it should be rewarded for producing the right answer efficiently. Their reward function evaluates the knowledge sufficiency by a knowledge matching mechanism, while penalizing excessive reasoning steps which means the model is specifically  trained to avoid redundant subqueries, avoid unnecessary retrieval calls, and avoid long chains of thought that do not add new evidence. The process reward looks at three things: whether the subqueries match the entities that matter, whether the retrieved context actually contains the golden evidence, and whether the summaries capture the essential facts. By normalizing these scores by the number of steps, the model learns to maximize information gained per step. 

 

For engineers, the practical implication is that TeaRAG behaves like a disciplined agent rather than a wandering one. It identifies key entities, formulates a focused subquery, retrieves a compact set of high‑density evidence, summarizes it, and decides whether another step is needed. Because the retrieval is filtered through the Knowledge Association Graph, the agent rarely gets distracted by irrelevant but semantically similar chunks. Because the reasoning is trained with process‑aware rewards, the agent rarely loops or overthinks. The result is a system that uses far fewer tokens while improving accuracy across both single‑hop and multi‑hop tasks. 

 

The framework is also notable for its scalability. The knowledge graph is built offline from a full Wikipedia snapshot, producing tens of millions of entities and over a hundred million triplets. The fact that the system can operate on a graph of this size without collapsing into noise is largely due to the co‑occurrence‑based filtering. Co‑occurrence between a chunk and a triplet is a strong relevance signal, and this becomes the backbone of the graph structure that PPR ranks over. 

 

TeaRAG is not a drop‑in replacement for standard RAG in an engineering project, but it is a blueprint for how to build agentic systems that do not explode in cost. It shows how to combine semantic retrieval and graph retrieval without doubling the noise, how to use graph structure to compress context, and how to train an agent to reason efficiently rather than exhaustively. The result is a system that reduces output tokens by more than half while improving exact‑match accuracy, which is a rare combination in RAG research. 

 

Pair this work with our service levels, resource quotas and observability framework, and we have full transparency and pay-per-use end-user experience. 

References: 

1. Zhang et al. (7 Nov 2025) TeaRAG: https://arxiv.org/pdf/2511.05385  

2. Our framework: https://github.com/ravibeta/qos-ai-queries  

 

7 failure points of RAG

 

A retrieval‑augmented generation system fails in ways that are far more structural than most software engineers initially expect. Each failure point emerges from the interaction between retrieval, ranking, consolidation, and generation, and each one reflects a mismatch between what the system thinks it has retrieved and what the user actually needs. These failures are not edge cases; they are the normal operating conditions of a RAG pipeline and understanding them is essential for anyone building production‑grade AI applications.

 

The first and most fundamental failure occurs when the system is asked a question that cannot be answered from the indexed documents. The ideal behavior would be a graceful admission of ignorance, but large language models are generative by nature and will often produce an answer that appears plausible even when the underlying content is absent. A fail case occurs immediately when asking a question that cannot be answered from the available documents the system could be fooled into giving a response. This is not a retrieval error but a boundary‑condition failure in the contract between retrieval and generation.

 

The second failure arises when the correct document exists but does not rank highly enough to be included in the top‑k results. Because RAG systems rarely pass all retrieved documents downstream, ranking errors directly translate into answer errors. The answer to the question is in the document but did not rank highly enough to be returned to the user. This is a classic information‑retrieval problem amplified by the fact that LLMs cannot compensate for missing evidence.

 

A third failure occurs even when retrieval succeeds: the correct chunk may be retrieved but excluded from the final context window due to consolidation limits. Token budgets, rate limits, and prompt‑chaining strategies force engineers to choose which chunks survive into the final prompt. There are case studies that suggest documents with the answer were retrieved but did not make it into the context for generating an answer. This is a pipeline‑level bottleneck where system design, not model capability, determines correctness.

 

The fourth failure is extraction failure. Even when the correct information is present in the context, the model may fail to extract it because of noise, contradictions, or ambiguous phrasing. Case studies also show that the answer is present in the context, but the large language model failed to extract out the correct answer. This is a reminder that LLMs are not deterministic parsers; they are pattern‑matching engines sensitive to prompt structure and context quality.

 

The fifth failure is formatting failure. When a question requires a specific output structure—tables, lists, and enumerations, the model may ignore the instruction despite having the correct content. A question involved extracting information in a certain format and the large language model ignored the instruction. This is especially problematic in applications where structured output is required for downstream automation.

 

The sixth failure concerns specificity. Answers may be too general or too narrow relative to the user’s intent. This happens when users ask vague questions or when system designers expect a particular level of detail that the model does not infer. The answer is returned but is not specific enough or is too specific to address the user’s need. This is a semantic alignment problem between user intent, retrieval granularity, and generation behavior.

 

The seventh failure is incompleteness. The model may provide a partially correct answer while omitting information that was present in the context. Such are the cases where answers miss some of the information even though that information was in the context and available for extraction. This is especially common when users ask multi‑document or multi‑facet questions, which LLMs often compress into a single dominant theme.

 

These seven failure points show that RAG systems do not fail at a single stage—they fail at the seams between stages. Missing content reflects the limits of the corpus. Missed top‑ranked documents reflect retrieval and ranking weaknesses. Context‑window exclusion reflects consolidation constraints. Extraction, formatting, specificity, and completeness failures reflect the generative model’s limitations when operating under imperfect retrieval conditions.

 

RAG robustness is not something you design once as a software engineer; it is something you continuously calibrate. The document emphasizes that RAG systems receive unknown input at runtime requiring constant monitoring and that validation is only truly possible during operation. Building a reliable RAG system therefore requires instrumentation, observability, semantic caching, metadata‑aware retrieval, and iterative tuning of chunking, embeddings, ranking, and prompting. These failure points are not warnings—they are the operating reality of retrieval‑augmented systems, and engineering around them is the core of building dependable AI applications.

 

AI Scalability

The modern enterprise has learned—often painfully—that scaling AI is not primarily a question of GPUs, model architectures, or clever fine‑tuning tricks. The real constraint is the substrate beneath all of that: the data infrastructure that feeds, shapes, and governs every stage of the AI lifecycle. AI fails not because models are weak, but because data foundations are brittle. Industry recognizes that data preparation takes 60–80% of a practitioner’s workload and this imbalance quietly destroys velocity, reproducibility, and trust across teams.

 

The idea of the “AI Factory” reframes AI development as an industrial process rather than a craft activity. Instead of treating AI as a sequence of bespoke experiments, the AI Factory model treats it as a production pipeline whose output is intelligence—measured not in FLOPs or GPU hours, but in token throughput and the value each token generates. This shift mirrors the evolution of software engineering itself: from artisanal coding to automated CI/CD pipelines, from ad‑hoc deployments to reproducible builds. The same transformation is overdue in AI.

 

There are four pillars—compute, storage, training, and deployment—that form the assembly line of an AI Factory. Compute provides the raw power; storage holds the raw materials; training transforms data into intelligence; deployment delivers that intelligence into real systems. But the critical insight is that even if these components exist, they rarely operate as a coherent system. Traditional data infrastructure collapses under AI-scale demands because it was never designed for high‑volume, high‑variance, continuously evolving data that must remain reproducible across hundreds of experiments.

 

There are seven failure points that are painfully familiar to practitioners. Data preparation bottlenecks dominate engineering time. Model development slows because teams overwrite each other’s work or cannot trace which dataset produced which result. Training pipelines break when scaled. Data quality issues surface too late. Compliance audits stall because lineage is missing. Pipelines pull “latest” data instead of the correct version. And all of this cascades into risk aversion, technical debt, and organizational paralysis. For example: Which v5 final dataset did we use to train the model that just failed in production?

 

The proposed remedy is to bring the rigor of software engineering—versioning, branching, reproducibility, traceability—to data itself. Data version control becomes the analogue of Git for code: every transformation stamped with an immutable ID, every dataset traceable, every experiment reproducible. This enables parallel experimentation without contamination, instant rollback when defects appear, and complete auditability when regulators or internal stakeholders demand proof. With proper versioning, the late‑night forensic hunt through S3 becomes a five‑minute fix.

 

The economic framing is equally important. AI Factory performance is measured not by infrastructure cost but by cost per token, revenue per token, and time to monetization. Proper data infrastructure reduces all three: fewer data quality issues, faster iteration cycles, and dramatically shorter audit and deployment timelines. Foundational data practices amplify every other investment such as with 75% fewer data quality issues and 80% faster delivery of data products.

 

The implementation playbook emphasizes starting with model and data readiness, selecting a scalable and compatible stack, and embedding governance and security from the outset. The pitfalls list reads like a postmortem of every failed enterprise AI initiative: treating data infrastructure as an afterthought, skipping version control, ignoring data quality gates, creating silos, over‑provisioning compute while starving data pipelines, and assuming a data lake is a data strategy.

 

Taken together, this article is an argument for a disciplined, engineering‑first approach to AI development—one where data is treated as a first‑class, versioned, governed, reproducible asset. For software engineers, this perspective is both familiar and transformative. It suggests that the future of AI engineering will look much more like modern DevOps: automated, traceable, testable, and collaborative. And it makes clear that the organizations that master their data foundations will be the ones that turn AI from an experiment into a durable competitive advantage.