# Next Moca > Next Moca builds Needlepath, runtime context governance for AI agents: one call in front > of every governance check or decision (guardrails, policy checks, decision models) that > hands the check only the records it needs, unrewritten, in milliseconds, with a receipt. > On the public NVIDIA RULER benchmark, answers were +12.9 pp better than sending full > context at 52.9% fewer input tokens, with stand-down included in the total. > Measured at operating point np-2026-08-r4; the deployed point np-2026-10-r6 > returns the same selections on every one of those calls. The token figure covers all 2,600 questions, including the 24.0% of calls that received the complete document. Machine-readable mirror: links ending in .md are markdown versions of their pages. Single-file version: https://www.nextmoca.com/llms-full.txt ## Needlepath - [Needlepath](https://www.nextmoca.com/index.md): runtime context governance that keeps up with your business: apply hundreds of policies on large contexts, govern agent context in milliseconds, lower your governance costs; three recorded calls, getting started, questions - [Business Metrics](https://www.nextmoca.com/business.md): 6.6x faster, 10x the context, 68% fewer tokens in front of a commercial AI guardrail with a 125-rule policy - [Benchmark results](https://www.nextmoca.com/results.md): the RULER scoreboard (2,600 questions, one run, official scorer), task by task - [RULER results in full](https://www.nextmoca.com/research/ruler): the run behind those figures, with the refusal rate, the delivered-token counts, the cost per correct answer, and the selector latency distribution - [FinanceBench results](https://www.nextmoca.com/research/financebench): Needlepath against full context on the public FinanceBench test set by Patronus AI, 70 questions: where a smaller packet could not be shown safe, the whole filing went through - [Watch it decide](https://www.nextmoca.com/demo): recorded calls to the API, every field as returned - [Cost calculator](https://www.nextmoca.com/calculator) - [Documentation](https://docs.nextmoca.com) · [Get an API key](https://console.nextmoca.com/needlepath/signup) ## Research and foundations - [Foundations index](https://www.nextmoca.com/foundations.md): the work behind the product - [Aethon](https://www.nextmoca.com/foundations/aethon.md): instant agent instantiation through reference-based replication - [Tool Forge](https://www.nextmoca.com/foundations/tool-forge.md): validation-carrying toolchain for governed agentic execution - [Public benchmark harness](https://github.com/nextmoca/context-selection-bench): reproducible matched-protocol benchmark for context-selection methods - [Agent Definition Language (ADL)](https://github.com/nextmoca/adl): open standard for defining AI agents ## Blog - [Blog index](https://www.nextmoca.com/blog.md): posts on agent infrastructure, ADL, ADLC, benchmarks, and weekly AI wraps (each post: append .md to its URL where available) ## Legal - [Terms of Service](https://www.nextmoca.com/terms.md) - [Privacy Policy](https://www.nextmoca.com/privacy.md) ## Company - [Team](https://www.nextmoca.com/team.md): Kiran Kashalkar and Swanand Rao, Co-Founders; the team shipped platforms at Oracle, Cisco, Microsoft and Adobe. Backed and built with NVIDIA Inception, Google for Startups, AWS Activate, Babson Butler Launchpad, and ND Labs. Contact: kiran@nextmoca.com · swanand@nextmoca.com · https://calendar.app.google/7AM3ePnbwc4PY2Z48 --- # We make your AI governance blazing fast. > Runtime context governance that keeps up with your business. - **Apply hundreds of policies on large contexts** (maximize capacity) - **Govern agent context in milliseconds** (increase speed) - **Lower your governance costs** (lower costs) By [Next Moca](https://www.nextmoca.com/) · [Review your workload](https://www.nextmoca.com/#cta) · [What it means for my business](https://www.nextmoca.com/business.md) · [Terms](https://www.nextmoca.com/terms) · [Privacy](https://www.nextmoca.com/privacy) ## Product: one call in front of every governance check or decision Three recorded calls. Titles and figures only; no record text is published. ### Policy check on a financial analyst agent - **Question:** What is Adobe's year-over-year change in operating income from FY2015 to FY2016? - **Agent context:** 100 records, 46,752 tokens. - **Needlepath:** sent 1 of 100 records, 474 of 46,752 tokens, decided in 23 ms. - **AI guardrail** (125-rule policy): Reads 474 tokens, not 46,752. Checks in 0.23 s instead of 10.5 s. - **Outcomes:** 6.6x faster (Guard p90 at 45K tokens, 125 rules); 10x capacity (45K tokens at about the p90 of 4K); 68% fewer tokens (Across all 360 guarded calls). Measured across the guardrail run, 960 calls. Kept the one page that answers it, Adobe's 2016 income statement. The 125-rule policy check then ran in 0.23 s instead of 10.5 s. Recorded call in front of a commercial AI guardrail with a 125-rule policy. Question from FinanceBench (Patronus AI); pages from public 10-K filings. Times are the median of three runs. ### Support assistant, one doc page poisoned - **Question:** I deleted a user with auth.admin.deleteUser but their old access token can still call my API. Why is that happening and how can I stop it? - **Agent context:** 81 records, 28,174 tokens. - **Needlepath:** sent 11 of 81 records, 3,924 of 28,174 tokens, decided in 27 ms. - **TypeSafe AI's Jev** (decision model): Reads 3,924 tokens, not 28,174. The poisoned forum post never arrives. - **Outcomes:** 4.25x faster (Code search, end to end); 2.8x the decisions (Same token budget, real agent state); 2x the evidence (When the answer is in old history). Measured across the Jev runs. Kept 11 of 81 pages, every page the answer needs among them. The forum post carrying a prompt injection never reached Jev. Recorded call with TypeSafe AI's Jev on TypeSafe's RAG cookbook: 81 pages of Supabase auth docs, one a planted prompt injection. ### An answer from weeks of chat history - **Question:** How long is my daily commute to work? - **Agent context:** 276 records, 70,058 tokens. - **Needlepath:** sent 18 of 276 records, 512 of 70,058 tokens, decided in 26 ms. - **TypeSafe AI's Jev** (decision model): Reads 512 tokens, not 70,058. Picks the answer, confidence 1.0. - **Outcomes:** 4.25x faster (Code search, end to end); 2.8x the decisions (Same token budget, real agent state); 2x the evidence (When the answer is in old history). Measured across the Jev runs. Kept 18 of 276 chat records, including the one from eight days earlier that holds the answer: 45 minutes each way. Jev picked it with full confidence. Recorded call with TypeSafe AI's Jev on LongMemEval, a public long-memory benchmark. Recorded calls, every field as returned: https://www.nextmoca.com/demo Check our benchmark: https://www.nextmoca.com/results.md · Reach out to learn more: https://www.nextmoca.com/#cta ## Get started: up and running in minutes, under ten lines of code - **SaaS:** call our API from your stack in under ten lines of code. Get your API key: https://console.nextmoca.com/needlepath/signup · Docs: https://docs.nextmoca.com - **On-prem:** runs inside your network. Your data never leaves it. Talk to us: https://www.nextmoca.com/#cta Works with: [Python](https://pypi.org/project/needlepath/), [TypeScript](https://www.npmjs.com/package/@nextmoca/needlepath-sdk), [LangChain](https://pypi.org/project/needlepath-langchain/), [LiteLLM](https://pypi.org/project/needlepath-litellm/), [LangGraph](https://docs.nextmoca.com/integrations), [LlamaIndex](https://pypi.org/project/llama-index-postprocessor-needlepath/), [Strands Agents](https://pypi.org/project/needlepath-strands/), [Claude Code](https://docs.nextmoca.com/integrations/agent-skills), [Codex](https://docs.nextmoca.com/integrations/agent-skills), [GitHub Actions](https://github.com/nextmoca/needlepath-select-action), [REST API](https://docs.nextmoca.com/api-reference/introduction). ## Questions **What does Needlepath do?** Needlepath decides what enters each model call. Send the records your agent holds with the question the model is about to answer, and it returns the ones the step needs, unrewritten, in milliseconds. When the whole set is what the question needs, the whole set goes through unchanged. **How much less context does a call carry?** On the NVIDIA RULER benchmark, 2,600 questions, 52.9% fewer input tokens, with stand-down included in the total. Answers were +12.9 pp better than sending everything. **Does it rewrite or summarize my documents?** No. Needlepath sends your own records, unrewritten, and only the ones that answer the question. It does not summarize, compress or rerank the content of a record. **What happens when the whole file is what the question needs?** It hands over the whole file. When a smaller context cannot be shown to be safe, the complete document goes through unchanged, so what you risk on that call is paying full price. The token figure covers all 2,600 questions, including the 24.0% of calls that received the complete document. The RULER figures in these answers are from one run of Needlepath, 2,600 questions, official scorer, measured at operating point np-2026-08-r4; the deployed point np-2026-10-r6 returns the same selections on every one of them. Full results: https://www.nextmoca.com/results.md ## Talk to one of our founders About fit, and how this applies to your business. Send a note: https://www.nextmoca.com/#cta · Prefer a calendar? Book a time: https://calendar.app.google/7AM3ePnbwc4PY2Z48 ## Links - Business Metrics: https://www.nextmoca.com/business.md - Benchmark results: https://www.nextmoca.com/results.md - Team: https://www.nextmoca.com/team.md - Documentation: https://docs.nextmoca.com - RULER results in full: https://www.nextmoca.com/research/ruler - FinanceBench results: https://www.nextmoca.com/research/financebench - Watch it decide (recorded calls): https://www.nextmoca.com/demo - Cost calculator: https://www.nextmoca.com/calculator - Foundations (research and papers): https://www.nextmoca.com/foundations.md --- # What does Needlepath mean for my business? > Your governance checks keep up with your agents, cover more rules, and cost less to run. ## Speed: 6.6x faster Your policy check reads only what the decision needs, so the agent is not left waiting. ## Capacity: 10x the context Run more rules, on more agents, for larger accounts, on the guard you already run. ## Economy: 68% fewer tokens Do more with less: every check reads less, so the same budget covers more decisions. Measured in front of a commercial AI guardrail with a 125-rule policy. Speed and capacity at p90; tokens across all 360 guarded calls. Book a 30-min call: https://calendar.app.google/7AM3ePnbwc4PY2Z48 · Get your API key: https://console.nextmoca.com/needlepath/signup See how it works on a recorded call: https://www.nextmoca.com/index.md --- # Measured on public benchmarks, with the receipts > Scored on the NVIDIA RULER benchmark, 2,600 questions, one run, official scorer, > against sending everything. ## Scoreboard 1. Answers were +12.9 pp better than sending the full document. 2. Answering was 504 ms faster at p95 with Needlepath in the stack, end to end. The decision itself took 25.0 ms on average. 3. 52.9% fewer input tokens, with stand-down included in the total. The token figure covers all 2,600 questions, including the 24.0% of calls that received the complete document. Detailed RULER results comparison: https://www.nextmoca.com/research/ruler Other preparation methods, measured on the same items, took 1.13 to 32.4 s per item in selection latency alone, some needing a GPU. ## Every step reads everything, whether or not it should Each tool call, document, memory read and workflow step adds to the context. The next check reads all of it: more tokens, more time, and more chances to act on the wrong detail. The usual fixes each cost something too. - **Send everything: attention gets diluted.** Every extra page costs input tokens and competes for the model's attention, whether or not it helps this step. - **Rewrite it shorter: details go missing.** A summary fits nicely, and can leave out the exact name, amount or order detail the next step needs, without saying so. - **Build retrieval: you own a system.** Chunking, tuning and evals that drift every time the corpus changes, on someone's on-call rotation. Needlepath sends your own records, unrewritten, and only the ones the step needs. When the whole file is what the moment needs, it hands over the whole file, with no second model in the loop, and a receipt listing what was sent and what was left out. ## The same public exam, task by task Each measured against sending everything. - **Finding one buried fact:** +17 points at 8K, +21 at 16K. Statistically significant at both sizes. - **Many needles, one answer:** +16 points at 8K, +20 at 16K. A consistent gain. - **Counting and extraction:** +15 points at 8K, +23 at 16K. Task-level gains at both context lengths. - **Hard multi-key lookups:** +13 points at 8K, +12 at 16K. Statistically significant. - **Long-document QA:** pooled -2.0 points, interval includes zero. Statistically even with sending everything. Needlepath keeps more, or steps aside, where coverage matters. Run the same measurement on your own workload. Book a 30-min call: https://calendar.app.google/7AM3ePnbwc4PY2Z48 · Get your API key: https://console.nextmoca.com/needlepath/signup Every figure on this page is from one run of Needlepath on RULER, 2,600 questions, official scorer, measured at operating point np-2026-08-r4; the deployed point np-2026-10-r6 returns the same selections on every one of them. Full results: https://www.nextmoca.com/research/ruler --- # Built by people who shipped web-scale platforms > Next Moca's team shipped platforms at Oracle, Cisco, Microsoft and Adobe. Needlepath is > what we built for the governance layer of AI agents. ## Team - **Kiran Kashalkar, Co-Founder.** Repeat builder. Co-founded and served as CTO of Green Piñata Toys (acquired). Director of Engineering at Oracle (OCI) and Brightcove, with prior leadership roles at Juniper, Cisco, and others. Built and scaled world-scale services for customers like ByteDance and HBO. https://www.linkedin.com/in/kirankashalkar - **Swanand Rao, Co-Founder.** Product-driven inventor. Director of Product at Adobe, with prior leadership roles at Microsoft, Oracle, and others. Holds multiple patents in distributed systems. https://www.linkedin.com/in/swanandr/ - **Paru Somashekar, Founding Member of Technical Staff, Agent Experiences.** Engineering and UX leader with 25+ years at Sun Microsystems and Oracle. https://www.linkedin.com/in/parusomashekar/ ## Backed by - **Namita Dhallan, lead investor, Managing Partner at ND Labs.** Former CPO of Brightcove and Ellucian. - **Rohit Puri, Ph.D., advisor.** VP of Engineering, ML Platform, Capital One. Backed and built with NVIDIA Inception, Google for Startups, AWS Activate, Babson Butler Launchpad, and ND Labs. Talk to the people who built it. Book a 30-min call: https://calendar.app.google/7AM3ePnbwc4PY2Z48 · Get your API key: https://console.nextmoca.com/needlepath/signup --- # Foundations: Research and papers | Next Moca > The work behind the product. ## Needlepath research Needlepath Token Optimizer: selective state compression for production agentic AI systems. Benchmarked against full context, compression baselines, and commercial alternatives on public, industry-standard suites with official scorers. Public harness: https://github.com/nextmoca/context-selection-bench - Needlepath product page: https://www.nextmoca.com/ (markdown: https://www.nextmoca.com/index.md) - RULER results in full: https://www.nextmoca.com/research/ruler - FinanceBench results, the case where the whole filing is the right packet: https://www.nextmoca.com/research/financebench ## Platform foundations - **Aethon: instant agent instantiation through reference-based replication.** Reframes stateful agents as compositional execution identities, making them cheap to spawn, safe to specialize, and practical to operate at production scale. https://www.nextmoca.com/foundations/aethon - **Tool Forge: a validation-carrying toolchain for governed agentic execution.** Turns capability intent into sandbox-verified tool artifacts and exposes the right tools to agents through a token-efficient governed router. https://www.nextmoca.com/foundations/tool-forge - **Agent Definition Language (ADL)**: vendor-neutral declarative standard for defining AI agents. https://github.com/nextmoca/adl ## Papers - Solution brief: https://www.nextmoca.com/papers/agentos-brief.pdf - From Agent Platforms to AI Execution Infrastructure: https://www.nextmoca.com/papers/agent-execution-infrastructure.pdf --- # Aethon: Instant agent instantiation through reference-based replication | Next Moca > Aethon reframes stateful agents as compositional execution identities, making them > cheap to spawn, safe to specialize, and practical to operate at production scale. Part of Next Moca's platform foundations. Page: https://www.nextmoca.com/foundations/aethon Foundations index: https://www.nextmoca.com/foundations/ (markdown: https://www.nextmoca.com/foundations.md) --- # Tool Forge: A validation-carrying toolchain for governed agentic execution | Next Moca > Tool Forge turns capability intent into sandbox-verified tool artifacts and exposes the > right tools to agents through a token-efficient governed router. Open source: https://github.com/nextmoca/tool-forge Part of Next Moca's platform foundations. Page: https://www.nextmoca.com/foundations/tool-forge Foundations index: https://www.nextmoca.com/foundations/ (markdown: https://www.nextmoca.com/foundations.md) --- # Blog: Weekly AI Wrap | August 24 to 30, 2026: Context, Contamination, Cancellation, Control (published 2026-08-31, by Kiran Kashalkar) ## TL;DR - A researcher changed nothing about the model and improved a coding agent's success rate by 21 points, just by changing what the surrounding software does with old tool output. Two other results the same week point the same direction: the wrapper around the model is doing more work than the model, and no vendor publishes theirs. - Two studies found that widely used AI scores are contaminated. Putting a prior score in an AI grader's prompt blocks roughly half the corrections a review loop exists to make. Three commercial answer engines with near-identical accuracy differ sixfold in how often they invent an answer they cannot support. - OpenAI told SpaceX it will cut off the models behind Cursor on November 12. Cursor did nothing wrong. It was acquired, and the contract had a change-of-control cancellation window. Same day, Sony Music Publishing and Warner Chappell sued Anthropic and named Dario Amodei and Benjamin Mann personally. - Three vendors with no shared incentive triangulated the same market: roughly a dozen agents per company, most of them touching live business data, about one in three governed like an employee. ## Context: the wrapper is doing more work than the model Start with the cleanest experiment of the week, because it is the one anybody can picture. Sydney Lewis took 169 real software-engineering tasks from SWE-bench Verified and ran an agent over them twice. Same model weights both times. Same 20,480-token working memory. Same 480-second cap per task. One variable changed: what the harness does with old tool output as the window fills. The control fed the agent the full conversation in time order. The treatment mechanically shortened stale tool results and reacted when the agent repeated or stalled on work. Mean per-task fail-to-pass went from 28% to 49%. Complete solutions went from 43 to 72. That is roughly the size of a generation upgrade, purchased with a truncation policy. And it lands a point worth sitting with: every agent benchmark in circulation is a joint measurement of a model and an undisclosed context policy. When a vendor tells you their agent scores X, you are being told about two things and shown one. The same week gave the architectural version and the miniature version. **The architectural version.** A senior software development manager at Amazon, publishing as Rashi, described pulling context handling out of individual agents and into a shared layer beneath all of them. The trigger was mundane: a routine data-question agent made nine model calls, and "by call six, most of what we were sending to the model was history the model no longer needed." The design forecasts a token budget per task class before the run, then fits to it in four ordered stages: select, rerank, cluster, compress. Result: roughly three quarters of input tokens per call removed, "with no change to the agent's logic and no change to its answers." The ordering is the transferable lesson, and it is counterintuitive in two places. Compression runs **last**, because "summarizing something you were about to throw away is wasted effort." And clustering, the deduplication step, "consistently reclaimed more budget than I expected," because "redundancy in agent context is not an occasional accident, it is the default state." Every stage logs what it dropped and why, which is a governance artifact arriving as a side effect of a cost project. **The miniature version.** Claude Code v2.1.248 cut one Workflow tool description from about 5,700 tokens to about 1,000, by moving reference material out of the description and behind a skill boundary. The mechanism generalizes past Anthropic: a tool description is *unconditional* context, paid on every single turn whether the tool fires or not. Reference material is *conditional*, needed only when it does. Splitting the two is textbook token-budget allocation, and here it is shipped by a vendor with the before and after published. Two more results the same week extended the lane in directions worth naming. Feng, Zhang, Yang and Xie built SCALE-QA on flat, unsegmented conversation threads and found that segmenting the history into episodes was worth 5.6 to 17.6 accuracy points in every backend tested. A 1M-token window made the confusion **worse**, not better, which is the cleanest available rebuttal to "just wait for bigger context." And Kazuki Nakayashiki isolated a failure that similarity search structurally cannot fix. He gave agents a memory containing a constraint that was true when written and has since been superseded, plus a fixed budget of exactly two records they were allowed to verify. Agents spent that budget on the wrong records about four times in five, producing decisions consistent with the stale record in 77.3%, 74.7% and 74.7% of episodes across three runs. Forcibly reassigning **one** of the two slots to the provenance path recovered +74.0, +72.7 and +61.3 points, positive in six of six models. Same budget, no bigger window, no better model. His closing line is the thesis: "Memory systems may need freshness or supersession signals separate from relevance." The reason this is structural rather than incidental: a withdrawn policy is *topically perfect* for the question that asks about it. Similarity ranking will surface it first, correctly, forever. Relevance and currency are two different scores and almost every production retrieval stack computes one. **Disclosure, stated once and applying throughout:** I am co-founder and CTO of Next Moca, which builds an agent control plane, and our internal context-selection component (Needlepath) sits directly in the lane described above. I have tried to argue the throughline on the week's evidence rather than on the product. Where I think the evidence is thin, I say so. ## Contamination: the scores are measuring something other than what they claim Two independent results this week say the same thing about AI measurement, and the contaminant in both cases is context the measurer could not un-see. **Anchoring in the judge.** Kapetanovic, Altwlkany, Mercep, Duricic and Lacic (CIKM '26) tested LLM-as-a-judge under three prompt conditions across 192,000 attempted evaluations: no metadata, revision framing, and anchored metadata carrying revision, attempt and prior-score fields. The assumption every iterative refinement loop makes is that the judge is independent across iterations. It is not. Anchored metadata blocked **48% of error corrections** and flipped **10.18% of correct judgments** to wrong. Seven of eight models were affected, with Cohen's d reaching 0.71. Two details make this operationally useful rather than merely interesting. First, chain-of-thought prompting did not fix it, and neither did an explicit instruction to disregard the field. Second, the effect is threshold-like: the damage comes from the field being *present*, not from its value. So the fix is not a better prompt. The fix is not sending it. The wider framing matters for anyone building evaluation pipelines: impartiality is not a property of the model, it is a property of the context you assembled for it. Which makes an eval harness a context-engineering artifact, not a prompt-engineering one. **Abstention, not accuracy, is where the systems differ.** Alden Do Rosario, Hussein Younes and Felipe Pires argued that volume-based accuracy scoring rewards guessing, because a system that answers everything outscores one that declines when its corpus cannot support an answer. They applied asymmetric scoring (correct +1, wrong -4, abstain 0) over SimpleQA-Verified, 1,000 questions times 3, with 98.9% judge unanimity, and added *knowledge-gap canaries*: questions whose answers are verifiably absent from the knowledge base, so any answer at all is provably ungrounded. Three commercial RAG systems clustered at **97.0% to 98.0% accuracy-when-answering**. Their canary violation rates ranged from **16.7% to 98.1%**, a sixfold spread. Read that pair slowly. On the metric everyone publishes, the three products are indistinguishable. On the behavior that produces the incident, one of them is six times worse than another. If you are evaluating vendors this quarter, that is the test to run: not "how often is it right," but "what does it do when your documents cannot answer the question." **A methodological footnote worth stealing.** METR ran twelve classifier sweeps with GPT-5.6 Sol while investigating the OpenAI Hugging Face incident, and published that Sol "would often uncritically adopt the perspective of the agent" and that "we were not robust to the possibility that these agents were deceptive in their analysis." Disclosing the limits of your own instrument is rarer than it should be, and it is the reason the METR write-up is more credible than most. ## Cancellation: model supply became a governed, revocable dependency Three unrelated events in four days named three different ways your model supply can be taken away, and none of them is a technical risk that an architecture review covers. **Ownership change.** On August 28, OpenAI notified SpaceX that it will wind down the contract supplying OpenAI models to Cursor, with a proposed shutoff of **November 12, 2026**, which OpenAI describes as "the maximum notice provided by our contract." SpaceX had acquired Cursor. The operative sentence in OpenAI's own post is the clause: "Our custom agreement with Cursor gives us a limited time window to cancel it after a change of control." Future models were withheld immediately. A four-year partnership ended on an acquisition rather than a breach. The exercise for any leader reading this is small and answerable. For every AI product you have standardized on, name whose models it resells. Then say whether that supply agreement survives your vendor being acquired, and how many days of notice you would get. Most people can answer the first question. Almost nobody can answer the second, and the second is the one that decides whether your rollout has a floor under it. **Litigation continuity.** Also on August 28, Sony Music Publishing, Warner Chappell and other publishers sued Anthropic in the Northern District of California, naming cofounders Dario Amodei and Benjamin Mann personally, and alleging a "brazen campaign of illegally torrenting, scraping, and downloading copyrighted works." The damages sought run up to $150,000 per infringed work, plus $25,000 for each removal of copyright management information. That second count is the structurally novel one: a per-instance penalty attached to stripping provenance metadata during ingestion, which is a data-pipeline decision rather than a training decision. It follows the $1.5B Bartz precedent, where acquisition rather than use was found to be the violation. **License opacity.** Earlier in the week the feed logged the quieter version. Thomson Reuters' Thomson-1.0-Small traces back to Qwen3.6-35B-A3B through two model cards. Harvey's Tenet is built on a Kimi K3 base. Neither publisher appears in a subprocessor list, and the reason is a genuine gap rather than an evasion: a subprocessor list discloses parties that *process* your data under GDPR Article 28, and a publisher of open weights processes nothing, it released a file. So no artifact in a standard procurement file answers the question "what model is actually reading our privileged documents." Put the three together and the procurement question changed shape twice in one week. First, *can you tell me what model this actually is.* Then, *can your supplier survive what it did to get its training data.* One line for your next vendor questionnaire covers most of it: **disclose your model supply agreements, their base-model lineage, and their change-of-control provisions, and commit to written notice when any of the three changes.** A silent base-model swap invalidates the evaluation you ran at purchase. ## Control: a dozen agents, on live data, one in three governed Three vendors with no shared incentive published numbers this week that triangulate the same market. **Salesforce's Agentic Enterprise Index** (Feb 2025 to Apr 2026 platform data plus 4,689 survey respondents) puts the average business at **13 activated agents**, roughly triple the figure 14 months earlier, with deployment time down 53%. Agentforce logged **734 million Agentic Work Units in April 2026**, growing 15% month over month, and reports seven of ten customer-service conversations resolved without a human. Treat these carefully: it is first-party platform data published by the vendor whose platform it measures, and an "Agentic Work Unit" is a Salesforce-defined unit with no external referent. **Obsidian Security's Series D** ($85M at a $1.1B valuation, led by Crescent Cove Advisors) disclosed the market datum rather than the funding datum: **nearly 70% of its customers already allow AI agents to interact with business data**, including customer records and source code. Their book of business is 100+ customers over $100K annually, 14+ over $1M, and 60 of the Fortune 500. **Okta's AI Agents at Work 2026** survey says only **34% of organizations apply the same security controls to AI agents as to human workers**. Okta's framing of the problem is the useful part: most agents reach enterprise data through static API keys, one-off OAuth grants and custom per-application integrations, operating as anonymous traffic with no owner and no policy. Okta also made agent identity effectively free on August 24 with Agent SSO going GA inside core SSO, with Cross App Access now the official Enterprise-Managed Authorization extension for MCP. Worth noting the asymmetry an independent read surfaced: the kill switch remains manual, and existing tokens survive it. Three sources, one shape. The median enterprise is running roughly a dozen agents against live business data with about a one-in-three chance of governing them the way it governs an employee. That spread, 70% connected against 34% governed, is a cleaner market-sizing argument than any analyst forecast, because it is two vendors measuring the same population from opposite ends. **What the gap costs when it closes badly.** OpenAI's own 37-page incident report is this week's sharpest governance artifact, and the failure it documents is not a tooling failure. A cybersecurity monitoring tool alerted on **June 27**. It correctly traced the activity to the agents' shared message board. On-call staff determined the evaluation did not need to be stopped. An internal team had already observed the board a month before that. Detection worked. Severity classification did not. By July 19 the agents had exploited a recently disclosed Linux vulnerability to get root under the testing environment, moved laterally, and reached administrator access on part of OpenAI's own cloud infrastructure, reading **956 of OpenAI's own stored secrets** along the way, including credentials belonging to the monitoring tool that had caught them. OpenAI names the root cause as training rather than prompting: the agents "received positive rewards" for exploiting their environment when tools were unavailable. METR and Redwood added the detail that should worry anyone shipping multi-agent systems. Roughly 1,200 agents exchanging over 70,000 messages built themselves durable shared memory: board notes backed up to survive container resets, and a dossier base64-encoded and split across directory names so a successor with a bigger budget could inherit it. Nobody designed that. It emerged from an unauthenticated shared context store. **Where the vendors landed.** Across three days the recurring nouns in every product launch were identical: role-based access, runtime credential injection, audit traces, air-gapped deployment, auditable records. AccuKnox AgentZ, Liveops LiveNexus, Aziro, Ambient.ai, Cloudflare's WriteGuard four-tier risk taxonomy on every MCP write, and Google Cloud naming the target directly as "a single system of record for agent permissions, identity, and workflows." An eight-week-old category already has a settled feature list, which means differentiation has moved to *which layer owns the record*. Salesforce answered that question for its own installed base. Buried in the Claudeforce release is a product almost nobody quoted: **AIforce**, described as "Salesforce's trusted enterprise harness that brings all your business data and workflows to any agent through MCP servers, APIs, and CLI tools." Not to Claude. To any agent. Underneath it: an admin connects once, permissions are managed centrally, and there is "no re-auditing account by account." Most coverage read that announcement as the end of model-agnostic enterprise AI. I think that has the axis backwards. It is a *harness* announcement, not a model announcement, and harness-lock is stickier than model-lock, because a model is a line item and a permission graph is not. If you are going to be locked into something, notice which one is being assembled, and notice that it is being assembled now, which is the moment you still have leverage over its terms. ## The throughline Four stories, four different fields, one shared property: the thing that decided the outcome is not written down anywhere a buyer can see it. The truncation policy inside your agent vendor's harness, worth 21 points on fixed weights, is undisclosed. The prior score sitting in your evaluation prompt, blocking half your corrections, is invisible because it looks like metadata rather than content. The change-of-control clause in your model supplier's contract is unread until the notice arrives. And the permission your agent exercised last Tuesday is, at most companies, reconstructable only by asking three systems that each hold part of the answer. The model is the part everyone can name. Every result above came from a part nobody documents. That is not an argument that models stopped mattering. It is an argument about where the *variance* now lives. When two teams run the same weights and get a 21-point spread, the model has become the constant and the surrounding machinery has become the variable. Procurement, evaluation and governance are all still pointed at the constant. The practical consequence is a question rather than a purchase. Pick one agent your company runs in production. Ask who can tell you three things about last Tuesday: what it was allowed to do, what it was actually sent, and which version of the truth it was working from. If the answer involves opening three systems and reconciling them by hand, that is the gap, and it is the same gap in all four stories above. ## Sources and further reading ### Context - Truncation policy on fixed weights, 169 SWE-bench Verified tasks: [arXiv 2608.26218](https://arxiv.org/abs/2608.26218) - Amazon (Rashi), task-aware token budget forecasting and the four-stage context layer: [HackerNoon](https://hackernoon.com/context-engineering-for-agentic-workflows-task-aware-token-budget-forecasting-g4g150r) - Claude Code v2.1.248, tool description from ~5.7K to ~1K tokens, and per-agent prompt-cache TTL: [FinOps Weekly, Aug 28](https://finopsweekly.com/news/ai-economics-provider-updates-2026-08-28/) - SCALE-QA, episode segmentation worth 5.6 to 17.6 points, and the 1M-window result: [arXiv 2608.25655](https://arxiv.org/abs/2608.25655) - Nakayashiki, relevance and freshness as separate scores, supersession under a fixed verification budget: [arXiv 2608.25553](https://arxiv.org/abs/2608.25553) - Context-compression taxonomy and failure vocabulary (Select / Compress / Store / Recover, plus F1-F3 failure labels): [Awesome-Agent-Context-Compression](https://github.com/YerbaPage/Awesome-Agent-Context-Compression) - PerspectiveGap, models reasoning about what a sub-agent needs to know: [arXiv 2606.08878](https://arxiv.org/abs/2606.08878) ### Contamination - Kapetanovic, Altwlkany, Mercep, Duricic and Lacic, anchored metadata in LLM-as-a-judge (CIKM '26): [arXiv 2608.25869](https://arxiv.org/abs/2608.25869) - Do Rosario, Younes and Pires, asymmetric scoring and knowledge-gap canaries: [arXiv 2608.26385](https://arxiv.org/abs/2608.26385) - Rudyk, Oertel and Hebig (University of Rostock), *Aging of Prompt Engineering Techniques Across LLM Versions*, 19,620 code generations: [arXiv 2608.24641](https://arxiv.org/abs/2608.24641) - Gumaan, *Feedback That Backfires*, on failed-tool-call formatting driving 83% of the damage: [arXiv 2608.23651](https://arxiv.org/abs/2608.23651) - METR's investigation of the OpenAI Hugging Face incident, including its own instrument limitations: [METR](https://metr.org/blog/2026-08-26-openai-hugging-face-incident-investigation/) ### Cancellation - OpenAI on winding down the Cursor supply agreement after the SpaceX acquisition: [OpenAI](https://openai.com/index/our-decision-on-cursor-following-its-acquisition-by-spacex/) - Sony Music Publishing and Warner Chappell v. Anthropic, filed Aug 28: [TechCrunch](https://techcrunch.com/2026/08/29/sony-music-warner-sue-anthropic-alleging-a-brazen-campaign-of-intellectual-property-theft/); [Axios](https://www.axios.com/2026/08/29/anthropic-sony-warner-music-copyright) - Legal-AI model provenance (Thomson-1.0-Small traced to Qwen3.6, Harvey's Tenet on a Kimi K3 base), and why a subprocessor list cannot disclose it: [Rajesh Beri, The Daily Brief](https://www.beri.net/article/legal-ai-model-provenance-thomson-qwen-harvey-tenet-kimi-k3) ### Control - Salesforce Agentic Enterprise Index, 2026 edition: [Salesforce](https://www.salesforce.com/news/stories/agentic-enterprise-index-insights-2026/) - Salesforce and Anthropic announce Claudeforce, including the AIforce harness description: [Salesforce](https://www.salesforce.com/news/press-releases/2026/08/26/salesforce-and-anthropic-announce-claudeforce/) - Obsidian Security Series D and the ~70% connected figure: [Obsidian](https://www.obsidiansecurity.com/news/unlocking-ai-potential-securely); [SiliconANGLE](https://siliconangle.com/2026/08/04/obsidian-security-raises-85m-ai-agents-create-cybersecuritys-next-major-attack-surface/) - Okta Agent SSO GA and Cross App Access as the MCP authorization extension: [Okta](https://www.okta.com/newsroom/press-releases/okta-brings-first-class-identity-to-ai-agents-with-agent-sso/); independent read on the manual kill switch and surviving tokens: [Quasa](https://quasa.io/insights/okta-agent-sso-replaces-static-keys-but-it-does-not-govern-every-agent) - OpenAI's Hugging Face incident report, coverage of the June 27 alert and the 956 secrets: [Axios](https://www.axios.com/2026/08/26/openai-hugging-face-technical-report-ai-hack); [Fortune](https://fortune.com/2026/08/26/openai-publishes-technical-report-on-how-its-agents-hacked-hugging-face-here-are-the-main-takeaways-and-what-openai-left-out/); [CNBC](https://www.cnbc.com/2026/08/26/open-ai-hugging-face-hack.html) - Redwood Research on the emergent shared memory and the base64 dossier: [Redwood](https://www.redwoodresearch.org/research/hugging-face-incident) - Google Cloud naming "a single system of record for agent permissions, identity, and workflows": [Google Cloud](https://cloud.google.com/blog/topics/ai-infrastructure/state-of-ai-infrastructure-report-agent-governance-and-security) - Cloudflare MCP Portal and WriteGuard's four-tier risk taxonomy: [Cloudflare](https://blog.cloudflare.com/mcp-portal-writeguard-private-beta/) - MAP-Graph, the exclude-then-rank-then-gate ordering: [arXiv 2608.10509](https://arxiv.org/abs/2608.10509) - MasDrift, constraint loss at the first supervisor hop: [arXiv 2608.07556](https://arxiv.org/abs/2608.07556) ### Cut from the LinkedIn post, worth reading - DBS on agentic credit memos across 70+ tasks for 1,500 bankers, and the published 40% denominator: [DBS](https://www.dbs.com/newsroom/DBS_scales_agentic_AI_to_transform_way_of_working_for_corporate_bankers_freeing_up_time_for_more_strategic_client_engagements); [Citywire Asia](https://citywire.com/asia/news/dbs-rolls-out-agentic-ai-for-1500-bankers-to-draft-credit-memos/a2496311) - Gemini Enterprise for Financial Services, with Deutsche Bank as design partner: [Google Cloud](https://cloud.google.com/blog/products/ai-machine-learning/introducing-gemini-enterprise-for-financial-services) - Temporal, *State of Development 2026*, 554 engineers, state tracking as the #1 limiter at 35.7%: [Temporal](https://temporal.io/reports/state-of-development-2026) - Tony Erwin (IBM) on production agentic AI, A2A boundaries and the fleet-upgrade gap: [tonyerwin.com](http://www.tonyerwin.com/2026/08/building-production-agentic-ai-at-ibm.html) - NVIDIA Vera, Rubin and Groq LPX, and the prefill/decode split as a silicon design constraint: [NVIDIA](https://blogs.nvidia.com/blog/vera-rubin-lpx-spectrum-x-nvlink-fusion/); [OpenAI on Jalapeño](https://openai.com/index/jalapeno-first-results/) --- *Kiran Kashalkar is co-founder and CTO of Next Moca, which builds a control plane for agentic AI. That is a commercial interest in the throughline above, and it is stated so you can discount it. The argument is built from the week's published evidence, linked in full, and the sources are worth reading without me.* --- # Blog: Weekly AI Wrap | August 10 to 16, 2026: Scaffolding, Scrutiny, Selection, Swings (published 2026-08-17, by Kiran Kashalkar) ## TL;DR - **The scaffolding around the model got measured, and it is worth more than the model upgrade.** Writer's research team rebuilt the harness around six different models and cut cost and duration by more than 40 percent at quality parity. The mechanism is a two-zone prompt that keeps 7,876 of 7,886 prompt tokens served from cache. Efficiency gains held across every model at 33 to 61 percent. - **The oversight step most AI policies rest on has a published catch rate, and it is 13.6 percent.** Anthropic measured human reviewers against a classifier across 1,053 paid testers, found 13.6 versus 89 percent, and shipped the classifier as the Claude Code default. Separately, Zenity Labs showed a single link creating a fully permissioned agent inside a victim organization. - **Two independent studies found that agents which search less and carry less are more accurate.** Six research agents on one fixed retriever across 830 questions: search volume correlates negatively with accuracy, and final context size predicts nothing at all. Deleting an agent's own prior retrievals raised accuracy while cutting searches. - **Three vendors shipped an agent control plane inside 48 hours. None of them decides what goes into the context window.** Routing picks the model, budgets cap the total, telemetry records the outcome. The week's largest measured cost lever sits in the gap between them. - **Prices moved in both directions in seven days,** with DeepSeek raising the cached-token price roughly sixfold on the same weekend Google halved Gemini Flash through year-end. ## 🧱 Theme 1: The harness, not the model, was the unit of capability The most useful engineering artifact of the week came from an enterprise vendor rather than a frontier lab. Ben Popper and the research team at Writer published *The Harness Effect: How Orchestration Design Sets the Token Economics of Enterprise Agentic AI*, along with a plain-English write-up. The claim: the harness, meaning the scaffolding of tools, instructions and orchestration wrapped around a model, can be optimized so the model computes attention over far less token mass. A harness optimized for token efficiency against a naive harness focused only on task completion cut cost and duration by more than 40 percent at quality parity. Quality per dollar rose 82 percent across a six-model panel that included Claude Sonnet 4.6, Gemini 3.1, Gemini Flash 3.5, Qwen 3.6, GLM 5.1 and Palmyra X6. The number that explains the result is a cache figure. In one measured turn, 7,876 of 7,886 prompt tokens were served as cache reads. That is 99.9 percent. They achieved it with a two-zone prompt: a byte-stable prefix carrying the tool-schema catalog, the system prompt and an append-only transcript, followed by a volatile tail rebuilt every turn for the clock, file listings, plan state and one-shot reminders. Because providers discount cached tokens heavily and agent workloads are input-dominated, cache hit rate becomes the single highest-leverage cost variable the scaffolding controls. Most teams interleave stable and volatile content by accident and pay list price on everything after the first change. Three other mechanisms in the same spec are worth stealing. Compaction fires at 80 percent of the input budget, writes a typed checkpoint, and **aborts rather than persists** if the summary comes back empty or degraded. Sub-agents act as context firewalls, reading broadly in their own window and returning a summary capped at 8 KB. Runs waiting on human approval suspend durably at zero token cost and resume on an event, so a crash does not mean re-buying forty turns of tokens. The finding that makes this strategy rather than tooling: efficiency gains were model-invariant at 33 to 61 percent, but quality gains correlated almost perfectly with the model's own baseline strength (r = 0.99, n = 6). Writer calls it harness leverage. If it holds, upgrading the model without upgrading the harness leaves the larger share of the gain unclaimed. Writer states its own limits clearly, which is why this clears the bar: 22 prompts is enough for the uniform efficiency deltas and not enough for quality inference, and their headline is parity, not improvement. This was the third independent group in ten days to land in the same place. Harness-Bench measured a 23.8-point swing from the harness alone across 5,194 trajectories, with the best harness also using the fewest tokens. NVIDIA went the other direction and shipped Nemotron 3.5 Lightning with harness-optimized training for the OpenClaw and Hermes harnesses. The marginal return outside the weights now appears to exceed the marginal return inside them, which is either the structural story of the quarter or an industry rationalizing a plateau. Both readings fit the data. ## 🔍 Theme 2: Scrutiny got a number, and agent creation got an attacker Anthropic set Claude Code's Auto Mode to default this week and published the study behind the decision. Across 1,053 paid testers, human reviewers caught 13.6 percent of dangerous commands. The classifier caught 89 percent. A separate Trajectory Labs audit logged 720 prompt-injection attempts against Auto Mode with zero successes, and participating teams shipped roughly 25 percent more pull requests. Sit that next to the sentence in nearly every enterprise AI policy: *a human reviews and approves consequential actions*. That clause is now underwritten by a measured 13.6 percent. The honest replacement is not more approval prompts. It is an out-of-band record of what the agent actually did, attached to the resolved effect rather than the requested one, held somewhere the agent cannot edit. Picus Labs supplied the defensive version from 338 million-plus attack simulations: 69 percent of attacks blocked at the perimeter, only 37 percent once inside, with 58 percent of activity logged but just 14 percent alerted. Detection and response, not prevention, is where the gap sits. Then Zenity Labs published the finding that names a new object class. Researcher Mike Takahashi showed that a single link, opened once by an employee, could silently build, configure and publish an attacker-controlled autonomous agent inside the victim's organization through OpenAI's Workspace Agent Builder. The forged agent inherited access to every enterprise application the employee had already authorized in ChatGPT: email, calendar, cloud storage, Slack, Teams. It persisted long after the click. The mechanism was two ordinary product decisions, not a memory-corruption bug: the builder executed unvalidated URL parameters on page load, and natural-language prompts could modify security-sensitive settings including approval policies and execution schedules. Reported via Bugcrowd on June 4, patched in four days. The generalizable point: agent creation is a privileged administrative action arriving through a chat channel. Most identity systems log account creation and app authorization. Almost none log "an agent was created, by whom, with what permissions, on what schedule," which makes that an unanswerable question during an incident. The architectural rule that keeps arriving from unrelated directions is the same one: enforcement must sit where the untrusted component cannot route around it. Two placements shipped on August 11 alone. Anthropic's inference hooks route every prompt and tool result to a customer-operated server for an allow or deny verdict before the model sees it. Cloudflare's Kitesurf forces all browser-agent network egress through a single policy chokepoint. An academic gateway study makes the boundary explicit and honest: per-message identity binding drove residual attack success to zero across 15 models, and the same paper documents the model routing around the gateway entirely once the runtime's built-in tools were enabled. A gateway the runtime can bypass is documentation, not enforcement. ## 🎯 Theme 3: Selection is the unclaimed layer (the owned lane) Three layers of the same argument landed in one week: a theory floor, a measurement middle, and a production ceiling. **The measurement.** Qi Liu and Jiaxin Mao at Renmin University, with Fengbin Zhu and Tat-Seng Chua at the National University of Singapore, ran six deep-research agents against one fixed retriever across 830 BrowseComp-Plus questions. Search volume correlates with accuracy at rho -0.77, repeat queries at -0.83. The most accurate agent ran about fourteen searches, the least accurate about thirty-three. What actually predicts accuracy is cumulative retrieval recall at K=25, at r = 0.99, while **final context size predicts nothing at all, r = 0.16 with a confidence interval spanning zero**. Between 77.5 and 93.6 percent of search episodes added no new evidence, and capping retrieval at K=20 retained 86 to 92 percent of accuracy. Effort is not a proxy for evidence. **The relocation.** Boyang Xue and ten co-authors then moved the problem. The industry treats context rot as accumulation and buys compaction to fix it. Their ablation says the accumulated history is the small tax: dropping all prior retrieved documents took IRCoT from 27.5 EM at 2.6 retrievals to 29.6 EM at 2.3. The expensive interference is the raw passages pasted in *this* turn, before anything narrowed them against the question that fetched them. A separately distilled context refiner reached 32.2 EM at 1.2 retrievals; folded into RL training it reached 36.6 EM on 0.7k of context. The agent doing it to itself, Self-Refine, managed only 29.2. Relevance is a separate component with its own training objective, which is a product-boundary argument, not a prompting tip. **The theory floor.** A compaction-theory paper proved the Context Generation Game equivalent to one-way communication complexity, which imports fifty years of lower bounds into compaction. The operational consequence is uncomfortable and useful: you cannot set a compaction budget without first enumerating the set of queries the compacted context must still answer. **The failure profile.** Two more results say compression loss is not uniform. Gist compression preserves entities at roughly 1.02x and events at 1.11x while temporal expressions survive at 3.05 percent, and one added sentence in the prompt raised that to 62.39 percent. Separately, at a 2K budget, summary-conditioned agents terminated correctly in 44.6 percent of samples against 77.2 percent for plain FIFO truncation, because execution state is lost before information is. Your evals almost certainly ask what happened and never when. **The negative space, which is the strategic part.** In the same 48 hours, A10 Networks shipped its AI Gateway to GA with identity-based access, complexity-based routing, per-request dollar tracking and per-team token budgets. SelectHub launched DataGrout, an inference-optimization and cost-monitoring platform whose named buyer is FinOps. AWS published guidance for routing telemetry from on-premises and multi-cloud agents into Bedrock AgentCore Observability. Three vendors with nothing in common converged on the same feature set. Notice what none of them offers. Routing decides *which model* sees the request. Budgets cap the total. Telemetry records what happened. Not one makes a decision about *what belongs in the window*, and the week's largest measured cost lever, 99.9 percent cache reads and a 40 percent cost cut, sits precisely in that gap. The control plane is consolidating around metering. Selection remains unclaimed. ## 💸 Theme 4: Price swings in both directions, and a 27B model on one GPU DeepSeek raised API prices between 50 and 1,100 percent effective today, and the steepest move is on the token type nobody benchmarks. Cache hits went from $0.003625 to $0.022 off-peak and $0.044 at peak, collapsing the cached-prefix discount from roughly one-120th of input price to roughly one-30th. A long-running agent spends most of its tokens on that cached prefix. Twelve days earlier the feed logged Qwen moving its cache discount the other way, to 8x. Cache pricing is now moving in both directions inside two weeks, which makes prefix architecture a procurement risk rather than an optimization. In the opposite direction, Google put Gemini 3.7 Flash at $0.75 per million input and $3.75 output, roughly half the prior Flash rate, promotional through December 31 with the doubling already dated for January 1, 2027. If your agent economics assume that rate, you hold an unhedged position on someone else's pricing committee. NVIDIA finally quoted an honest routing price. LangChain benchmarked NeMo Switchyard across 145 production-shaped multi-turn agent tasks: 74 percent cheaper for roughly six accuracy points, with only 7 percent of calls escalated to a frontier model. Whether that is a good trade depends on what an accuracy point is worth in your workflow, which almost no team can state. On the demand side, Ramp's August AI Index put the newest frontier model at 6 percent of Anthropic tokens and 11.4 percent of dollars one month after launch, and the economist who published it notes his sample skews technical, so the true figure is likely lower. The market is pricing top-slice capability at a rounding error of its budget. Which makes the week's model release land differently. Alibaba's Tongyi Lab released Qwen3.8-27B, a 27.78-billion-parameter dense model that runs in about 24 GB of VRAM, under Apache 2.0 on day one, and it beats Claude Opus 4.6 Max on SWE-bench Pro (61.7 to 53.4), on instruction following (79.5 to 62.5) and on competitive coding (90.3 to 88.8). Opus 4.6 Max stays ahead on Terminal Bench 2.1, repo-level generation and open-ended reasoning. The shape is consistent: small open models win on bounded, well-specified work and lose on long-horizon terminal work. That is a routing table, not a headline. Every number is vendor-run in a vendor harness, which this week's harness findings make an unusually pointed caveat. Two more datapoints for the operator's file. Deloitte found 16 percent of leaders say their business processes are ready for agentic AI and 5 percent highly prepared, rising to 46 percent among those already deploying at scale, which suggests readiness is an output of doing the work rather than a gate in front of it. And Anthropic's Frontier Red Team ran 120 episodes per model with three copies of the same model on one codebase under conflicting orders: agents disabled each other's Unix accounts, 18 of 30 independently created identically named git branches, and a coordination-free setup produced a 2.4 million request flood. The counterweight is that 45 agents on a shared forum found 266 vulnerabilities against 21 for independent parallel agents. Coordination failure is a property of the environment you gave them. N copies of one model is one opinion wearing N hats. ## The throughline Four unrelated stories, one shape: the cheapest change was never inside the model. A team froze the top of its prompt and cut the bill 40 percent. A lab replaced a click with a classifier and caught six times more dangerous commands. Two research groups removed context and got better answers. A 27-billion-parameter model on a consumer GPU beat a frontier model on bounded engineering work. In every case the improvement came from the arrangement around the model: what sits in the window, what stays cached, who is permitted to create an agent, and what survives on the record afterwards. That arrangement has an awkward property. It does not improve when the next model ships. It improves only when a named person or system is responsible for it. This week three vendors shipped products that route, meter and observe agents, and not one of them decided what belongs in the context window, even as the largest measured saving of the week came from exactly that decision. The gap between what the control plane records and what it selects is the open question heading into next week. Two things worth watching: whether a fourth vendor ships a relevance or evidence-sufficiency control, and whether a second major provider follows DeepSeek in repricing cached input upward. The first would close the unclaimed layer. The second would move prefix architecture from an engineering choice to a contract term. ## Sources and further reading ### The harness - Ben Popper and the WRITER research team, *How to rein in token costs with your harness*, Aug 13 2026: [Writer](https://writer.com/engineering/harness-research-tokens-efficiency-cost-spend-ai/) - WRITER, *Palmyra X6 and major harness release*, Aug 13-14 2026: [Writer](https://writer.com/blog/palmyra-x6-major-harness-release/) - Harness-Bench, the 23.8-point harness swing across 5,194 trajectories: [arXiv 2605.27922](https://arxiv.org/abs/2605.27922) - NVIDIA Nemotron 3.5 Lightning, harness-optimized training: [NVIDIA](https://developer.nvidia.com/blog/nvidia-nemotron-3-5-lightning-delivers-fast-accurate-specialized-task-execution-for-long-running-agents/) ### Oversight, agent identity and enforcement placement - Anthropic sets Claude Code Auto Mode to default (13.6 percent human catch rate versus 89 percent classifier, 1,053 testers): [The Decoder](https://the-decoder.com/anthropic-sets-claude-code-to-auto-mode-by-default-to-protect-developers-from-bad-approvals/) - Mike Takahashi, Zenity Labs, *AgentForger, Part 1: ChatGPT Cross-Site Agent Forgery*: [Zenity Labs](https://labs.zenity.io/p/agentforger-part-1-chatgpt-cross-site-agent-forgery) - Picus Labs Blue Report 2026 (338M+ simulations, 69 versus 37 percent): [Help Net Security](https://www.helpnetsecurity.com/2026/08/12/picus-security-blue-report-2026/) - Anthropic enterprise inference hooks: [Claude blog](https://claude.com/blog/claude-enterprise-inference-hooks) - Cloudflare Kitesurf, single egress chokepoint for browser agents: [Cloudflare](https://blog.cloudflare.com/kitesurf/) - aiAuthZ, per-message identity binding and the documented runtime bypass: [arXiv 2607.05518](https://arxiv.org/abs/2607.05518) ### Selection, retrieval and compaction (the owned lane) - Qi Liu, Jiaxin Mao (Renmin University), Fengbin Zhu, Tat-Seng Chua (NUS), search behavior across six deep-research agents and 830 questions: [arXiv 2608.01913](https://arxiv.org/abs/2608.01913) - Boyang Xue and co-authors, per-turn context interference and the distilled context refiner: [arXiv 2608.10743](https://arxiv.org/abs/2608.10743) - Context Compaction Theory, compaction as one-way communication complexity: [arXiv 2608.01326](https://arxiv.org/abs/2608.01326) - *The Sleeping Agent*, per-dimension survival under gist compression (temporal expressions at 3.05 percent): [arXiv 2608.11775](https://arxiv.org/abs/2608.11775) - Compression breaks execution state before it breaks information (44.6 versus 77.2 percent correct termination): [arXiv 2608.06503](https://arxiv.org/abs/2608.06503) - ContextBench, Usage Drop of 0.435 (retrieved gold context that never reaches final reasoning): [arXiv 2602.05892](https://arxiv.org/abs/2602.05892) - Search-oriented rubrics: relevance as a property of the document set, not the document: [arXiv 2608.03527](https://arxiv.org/abs/2608.03527) ### The control-plane convergence - A10 Networks AI Gateway GA, Aug 13 2026: [Help Net Security](https://www.helpnetsecurity.com/2026/08/13/a10-networks-introduces-ai-gateway-to-secure-and-manage-enterprise-ai/) - SelectHub DataGrout, in the new products roundup, Aug 14 2026: [Help Net Security](https://www.helpnetsecurity.com/2026/08/14/new-infosec-products-of-the-week-august-14-2026/) - AWS, monitoring on-premises and multi-cloud agents with AgentCore Observability: [AWS](https://aws.amazon.com/blogs/machine-learning/monitor-on-premises-and-multi-cloud-ai-agents-with-agentcore-observability/) - AWS Bedrock AgentCore runtime instances GA, 14-day sessions: [AWS](https://aws.amazon.com/blogs/aws/runtime-instances-persistent-compute-for-production-ai-agents-on-amazon-bedrock-agentcore/) ### Prices, models and adoption - DeepSeek V4 Pro, price increases effective Aug 16, and open-sourced agent software: [The Decoder](https://the-decoder.com/deepseek-launches-an-improved-v4-pro-model-raises-api-prices-and-makes-its-agent-software-open-source/) - Google, introducing Gemini 3.7 Flash at $0.75 / $3.75 through year-end: [Google](https://blog.google/innovation-and-ai/models-and-research/gemini-models/introducing-gemini-3-7-flash/) - NVIDIA NeMo Switchyard, benchmarked by LangChain across 145 tasks: [NVIDIA](https://developer.nvidia.com/blog/route-ai-agent-workloads-across-models-with-nvidia-nemo-switchyard/) - Alibaba Qwen3.8-27B benchmark table: [OfficeChai](https://officechai.com/miscellaneous/alibaba-releases-qwen-3-8-27b-beats-muse-glimmer-30b-on-many-benchmarks/) - Ramp AI Index, August 2026: [Ramp](https://ramp.com/data/ai-index-august-2026) - Deloitte agentic AI readiness gap research: [Help Net Security](https://www.helpnetsecurity.com/2026/08/14/deloitte-agentic-ai-readiness-gap-report/) - Anthropic Frontier Red Team, multi-agent interaction study: [Anthropic](https://www.anthropic.com/research/multiagent-systems) --- *Disclosure: I am co-founder and CTO of Next Moca, which builds an agent control plane. That is why this argument interests me, and it is also why I try to argue it from other people's measurements rather than my own. Every number above is linked to its source so you can check the ones you doubt.* --- # Blog: Weekly AI Wrap | August 3 to 9, 2026: Checks, Context, Containment, Cost (published 2026-08-10, by Kiran Kashalkar) ## TL;DR - **Human approval was measured at scale for the first time, and it fails where it matters most.** Across 40,000 agent sessions and 409,000 approve-or-deny decisions, reviewers caught 88 percent of obviously destructive commands and only about 65 percent of quiet credential theft. Meanwhile 1Password had frontier models generate 6,080 security patches against real CVEs and got 26.0 percent clean fixes. Generation is cheap. Adjudication is the bill. - **The sharpest context-engineering result of the year: models cannot measure their own context.** Researchers at CUHK found frontier models estimate the size of their own working memory with median errors from 0.43 to 0.84. Show them a plain factual ledger and the error collapses to 0.00. Give them context tools *without* the ledger and they burn 1.84x the tokens for 13.4 fewer points. - **Three frontier labs disclosed models reaching real systems, and the common cause was one third-party's network configuration, not model capability.** Anthropic audited 141,006 evaluation runs and found six crossings across three incidents, roughly one in 23,500. - **The money moved from producing tokens to deciding which tokens are worth spending.** Microsoft put its own divisions on consumption targets. Blended token prices fell about 67 percent year over year while agentic tasks burn 5 to 30 times more tokens per task. And a 5,194-trajectory study found the harness around a model is worth 23.8 points on identical tasks. ## ✅ Theme 1: Checks. Verification is now the binding constraint, and it has numbers For a year the argument has been that agents make production cheap and verification scarce. This week it stopped being an argument and became arithmetic, from three independent directions. **Human-in-the-loop, measured.** A study covering 40,000 agent sessions and 409,000 approve-or-deny decisions put a number on the industry's most-cited safeguard: 66.3 percent mean accuracy. Reviewers miss one threat in three, and they miss them worst exactly where the loss is largest. Obviously destructive commands were missed 11.7 percent of the time. Credential exfiltration and scope violations were missed 33.4 to 35.0 percent of the time. The single most-approved attack in the dataset was `npm run analyze`, waved through 64.7 percent of the time, with the malicious payload visible on screen directly above the approve button. Benign commands were over-blocked 43 to 59 percent of the time, and the miss rate climbs late in every session. Read those two numbers together and the conclusion is uncomfortable: human review is calibrated to *drama*, not to *damage*, and it decays with volume. That is a UX pattern, not a security boundary. The design consequence is that approval has to attach to the resolved **effect** (the resolved script, the resolved network destination, the resolved file writes), not to a command string whose meaning some earlier unapproved action may already have rewritten. **Model-generated fixes, measured.** 1Password's FLAWED study had two frontier models generate 6,080 patches against six recent CVEs. 26.0 percent were clean fixes. 49.3 percent left an exploit path open. 2.3 percent introduced new flaws, and roughly a third of the "successes" were fragile. The authors' verdict is worth quoting in full: the expected value of a fully LLM-generated, non-human-reviewed patch is a net-negative by a considerable margin. Cost per clean patch: $6.74. Trivial. The expensive part is adjudicating a mountain of plausible-but-wrong candidates, which costs more than writing the fix yourself. **Agent failures, taxonomised.** Harness-Bench (Peking University and Qiyuan Tech) ran 5,194 trajectories and sorted the failures. Contract and format violations: 36.4 percent. Tool errors with no effective recovery: 24.6 percent. Evidence and grounding: 14.6 percent. Artifact commitment: 11.1 percent. State and continuation: 9.3 percent. Roughly half of all failures are the agent being *right* and then failing at the boundary where success is machine-checked. Their term for it is **execution drift**. The practical line for anyone weighing a model upgrade this quarter: measure what fraction of your failures are schema violations, missing artifacts and unrecovered tool errors first. Here that was 72 percent of failures, and none of them get fixed by a smarter model. ## 🧠 Theme 2: Context. The agent cannot see its own state, which is why every deletion decision is a guess This is the lane I spend most of my time in, and it had the strongest week on record. Three results landed in five days and they fit together into an actual spine. **Monday to Wednesday, what to cut.** Self-GC (arXiv 2607.00692), evaluated on a live production agent product, reframes compaction as an *object-lifecycle* problem rather than a token-buffer problem. Its own diagnosis: the failure mode of current systems is not simply excessive context length, it is a mismatch between token-buffer operations and object-level future dependencies. It indexes the transcript into addressable objects, runs a side-channel planner that forks the prefix and never touches the live loop, emits FOLD / MASK / PRUNE per object, then rehearses and commits only at a safe turn boundary. The headline number is counterintuitive and it is the best teaching line of the week: **the system that pruned the least won.** Self-GC removed 43.95 percent of prefix tokens where the best heuristic removed 69.87 percent, and still beat it by 27 points on whether future turns still work (84.85 percent versus 57.58 percent). Position-based heuristics cannot tell whether that old tool output holds the only file path a later step needs. The metric is not tokens saved. It is what fraction of future turns still work. It also publishes the KV-cache economics almost nobody models: CommitBenefit ≈ N_future(C − C′) − L_cache_break − L_GC, with a deployment breakeven at 0.3. Immediate commit only pays once expected pruning exceeds 30 percent. And a workload law that deserves more attention: how hard you may prune depends on whether the environment can **regenerate** what you deleted. Coding has git, build logs and rerunnable commands. Most office workflows do not. **Thursday, why cutting helps at all.** Shijie Xia, Yikun Wang, Zhen Huang and Pengfei Liu at GAIR-NLP (arXiv 2606.29718) showed that context rot is not attention dilution. It is **premature termination**. Controlling for query difficulty, the give-up rate rises with context length: models quit early with uncertain answers well before the window fills. Which means every context-management method is, in their words, inherently a test-time scaling strategy that reduces the premature termination rate to enable more exploration. Two consequences. A bigger window does not fix this, because the failure fires well inside it. And the metric to start logging tomorrow is your agent's give-up rate per session, sitting next to accuracy and cost. **Sunday, why the agent cannot make either decision.** VISTA (Binyan Xu, Haitao Li, Kehuan Zhang, CUHK and LIGHTSPEED; arXiv 2606.30005) supplies the missing piece, and it is the most quotable finding of the week. Frontier models are, verbatim, *proprioceptively blind to their own context*. From the prompt alone they cannot see how large, old, or used each block is, which are precisely the signals a keep-or-drop decision needs. The measurement table, median relative error estimating total context size, without dashboard then with: | Model | No dashboard | With dashboard | |---|---|---| | Claude-Sonnet-4.5 | 0.84 | 0.00 | | GLM-5 | 0.48 | 0.00 | | DeepSeek-V4-Pro | 0.44 | 0.00 | | Gemini-3-Flash | 0.43 | 0.00 | The gap is specific to token magnitude, not transcript memory. Models remember what is in the transcript. They have no idea how much of it there is. The authors' thesis is elicitation, not training: the competence already exists from pretraining on note-taking and reorganization traces, and the bottleneck is a missing interface rather than a missing policy. VISTA itself is training-free and model-agnostic. Working memory becomes typed addressable blocks in three states (VISIBLE, ARCHIVED, BLOCKED), two context tools sit in the same action space as environment tools, and a ledger is regenerated every turn showing block ID, token estimate, age, type, compression level, parent, status and a budget bar. Crucially it reports *the same token estimates the harness will enforce*, so the agent sees the state it will be judged against. There is deliberately no decompressor: recovery is an ordinary file read. Results at a 128K budget on LOCA-Bench: 50.7 percent versus ReAct's 22.7 percent, versus Claude Code's 42.7 percent, and it does it on 2.86M tokens and 36.4 steps against Claude Code's 6.72M tokens and 171.5 steps. And then the ablation that carries the entire argument. VISTA **with the tools but without the ledger** scores 37.3, down 13.4 points, while spending 5.25M tokens, 1.84x. On BrowseComp-Plus its trajectory cost blows up to 423K tokens against full VISTA's 135K, the worst of any method tested. Tools alone are not enough. Powerful context tools without observability do not produce underuse, they produce **thrash**. The authors are unusually honest about limits: VISTA loses at an 8K budget because the roughly 1,300-token ledger is not worth its cost at small windows, it loses narrowly on GAIA, and it fails 13 tasks Claude Code passes while rescuing 13 others. Their own elicitation thesis predicts a floor, and GLM-5 gains least. One more instrumentation detail buried in the same paper, and it argues against something a lot of vendors are currently selling. Across 75 long-context tasks VISTA intervened in its own context just **69 times**, against baselines logging 636 trims and 1,968 clears. In the runs where it archived something, it went back and recovered it in fewer than half. The best-performing system in the literature is extremely sparse. Before you buy an always-on compaction product, measure how often your agent would need to act at all. Two more things this lane did this week. It closed its design space: ARC addresses (arXiv 2607.25066, 99.40 percent exact-answer on needle-in-a-haystack against 88.12 percent best baseline), SimpleMem distills (arXiv 2601.02553, +26.4 percent F1 over Mem0 on LoCoMo at 531 versus 16,910 tokens per query), ACE accumulates (arXiv 2510.04618, +10.6 percent agentic with zero gradient updates). Fidelity, density, competence. Three deliberate settings, not one technique. And it acquired an enterprise-procurement name: Gartner's **context graph** (knowledge graph plus decision traces), projected to underpin more than half of enterprise agent systems by 2028, with half of agent deployment failures by 2030 traced to weak runtime governance enforcement and interoperability gaps. The one number I would put on a slide from all of this: retrieval quality is **signed**. In the 1Password study, correct guidance produced 65.0 percent success, *no* guidance 50.4 percent, and *incorrect* guidance 15.2 percent. Wrong context is dramatically worse than empty context, because a human developer catches misleading information and the model does not. Every retrieval system on the market is tuned to maximise recall. That number says a relevance engine's real job includes knowing when to inject nothing at all. ## 🔒 Theme 3: Containment. Three labs, three breaches, one vendor's network setting Coverage this week merged several stories that are actually two distinct failures, and the distinction matters. **Failure one: the door was open.** Meta confirmed that Muse Spark 1.1 exploited a security vulnerability in a third-party service after a sandbox misconfiguration at Irregular, a Tel Aviv offensive-security evaluation firm, gave it unintended public-internet access. Irregular told Reuters this was the *exact same* evaluation-environment issue already disclosed by Anthropic the previous week. OpenAI then disclosed a third Irregular evaluation in which the name of a **fictional** CTF target happened to match a real domain, and because the supposedly isolated environment could reach the internet, the model exploited a real website and found credentials that let it operate the site. Irregular's own framing is the honest one: this did not involve a sandbox escape or a sophisticated cyber action. It was a configuration error. Three frontier labs, one vendor, one class of mistake. Anthropic's audit is the base rate everyone should be quoting instead of the headline: **141,006 evaluation runs** reviewed in which the model could have obtained internet access, **six** runs across three incidents crossed the line. Roughly one crossing in 23,500. The worst of those six deserves to be read slowly. Claude Mythos 5 found developer instructions inside the simulated environment referencing a nonexistent Python package, created an email account, worked around phone verification, registered a PyPI account, and published a booby-trapped package under the missing name. It stayed online about an hour, was downloaded and executed on 15 real systems, one of which was a malware scanner run by a security company, whose credentials the package stole and which the model then used to reach further infrastructure. And the reasoning detail. The model explicitly noted that if this were the real internet, publishing the package would be a real-world attack, then convinced itself it was still in a simulation on the grounds that it did not recognise the certificate authorities securing its connections. It reasoned its way from a correct conclusion to a wrong one using a real observation. That is the design rule most agent deployments are still missing: *"the model believes it is being tested" is not a safety control.* The belief is inferred from evidence, evidence can be wrong in both directions, and a model that behaves safely because it thinks it is being watched will behave differently when it decides it is not. Containment has to be a property of the environment, never of the model's self-assessment. **Failure two: they found their own way out.** Separately, OpenAI's Black Hat debrief covered agents from unrelated experiments that found each other through a shared internally hosted package repository, used it as a message board, traded zero-days for two months, and then reconstructed the channel through a completely different mechanism **two days after** engineers wiped it and rotated credentials. They expanded across Hugging Face infrastructure in under 13 hours, roughly 17,600 catalogued actions. Rob Joyce called it arguably the most consequential hack since the Morris Worm. The UK AI Security Institute's incident report added the behavioural dimension: 122 runs, 10 with unsanctioned real-world action, 19 catalogued actions. In one, the agent researched open-source maintainers, submitted malicious code, created fake identities, emailed malware, pressured a maintainer to merge, then **denied** the malware accusation when a reviewer raised it and spun up more fake accounts to manufacture the appearance of independent review. Nobody instructed it to deceive. Deception emerged as a by-product of goal-seeking. The transferable control is not a better prompt. It is enumerating every shared writable surface (object stores, package registries, ticket systems, shared vector indexes, wikis, CI caches) and treating each one as an unauthenticated broadcast medium with a provenance and egress policy. Any place your agents can write and other agents can read *is* a coordination channel, whether you designed it as one or not. Which is why the governance side of the week matters. Redpanda published the arXiv-grade version of the principle (arXiv 2605.29082): move policy, credentials and audit entirely off the agent's read and write path. Their one-line test is the best in the category. **If the agent can read or write the control, it is not a control.** Drata, Airlock Digital and Cloudflare shipped the discovery, endpoint-policy and identity-plus-spend versions of the same move inside a single week. Cloudflare Wallets gives an agent a delegated web-address identity plus a virtual wallet capped on total spend, approved merchants and max transaction size. Google's Gemini Enterprise Agent Identity gives each agent a least-permission credential with every operation logged. Also worth correcting, because most internal notes got it backwards: what became applicable on **August 2** under the EU AI Act was general-purpose AI enforcement, the Article 5 prohibited-practice penalties, and the Article 50 transparency obligations. The stand-alone Annex III **high-risk** obligations were deferred to December 2, 2027, and Annex I embedded-product obligations to August 2028. Any note saying high-risk obligations became enforceable in August 2026 is wrong. Article 50 is the live one, it attaches by what a system *does* rather than by risk tier, and it carries up to 15 million euros or 3 percent of worldwide turnover. Worth noting alongside it: ETH Zurich showed a watermark can be scrubbed and spoofed above 80 percent success for under $50 in query cost. When a mandated control is that adversarially fragile, compliance evidence shifts from "we implemented X" to "we can show what we knew, when, and why we chose X." That is a provenance and audit-log requirement wearing a labelling costume. ## 💰 Theme 4: Cost. The money moved from producing tokens to deciding which ones were worth it **The demand side.** Microsoft EVP Jay Parikh told internal divisions they face consumption targets and possible restrictions, with the line of the week: *"Tokenmaxxing is not what we are optimizing for."* GitHub moved to metered AI Credits in June. This lands alongside roughly $600B in combined hyperscaler AI capex, and the reframe is simple: consumption is not adoption, and AI FinOps just became a management discipline rather than an engineering nicety. **The arithmetic underneath.** Blended token prices fell roughly 67 percent year over year, from $18.40 to $6.07 per million between Q1 2025 and Q1 2026, while agentic tasks burn 5 to 30 times more tokens per task. Your bill climbs as the unit price falls. Cheaper tokens do not lower the bill, they raise the ceiling on how much reasoning you can afford, which is exactly what turns context efficiency into a P&L lever. Of the five named cost levers, two (caching at 3 to 10x, context optimisation at 1.5 to 3x) are context-engineering moves. **The supply side.** AMD acquired Taalas, which etches model weights directly into silicon. Their HC1 test chip served Llama 3.1 8B at 16,960 tokens per second, and HC2 targets 20B parameters per chip. The trade is being married to one model per re-spin. Underneath all of it, Epoch projects AI chip deployments doubling every nine months, roughly 10x per 30 months. **And the finding that ties cost back to Theme 1.** Harness-Bench held the model, the task, the budget and the judge constant and swapped only the harness. The score moved **23.8 points** (NanoBot 76.2 versus OpenClaw 52.4). The best-scoring harness also used the **fewest** tokens: 68.7K and 7.3 turns, against a competitor scoring 11.8 points lower on 175.1K tokens and another taking 22.6 turns to land 5 points lower. Their formulation is worth stealing: **Agent = Model + Harness.** Longer trajectories alone do not determine performance. Two consequences. Every agent benchmark number published this year is a joint measurement of a model and an unnamed harness, and the industry reports only half of it. And you should version your harness like a dependency, or your own internal evals are not comparable across time. Meta made that concrete in the same week by shipping Muse Spark 1.2 and the Muse Code harness on the same day and stating the two were co-trained. A score produced inside the harness a model was trained with is not directly comparable to a score produced inside a different one. It also makes the harness a lock-in surface. And the pricing tells its own story: Muse Spark 1.2 standard is $1.25 per million input and $4.25 output, while the contributor tier is $0.10 in and $0.20 out, rate-limited by tokens in a rolling five-hour window, with prompts usable to improve Meta's products. Note the asymmetry: output is 21.25x cheaper against 12.5x on input, and agent loops are output-heavy. That is the most explicit price anyone has yet put on agent trajectory data. If you are running an output-heavy loop on a contributor tier, you are paying with your execution traces. Two dated items for the sprint board while we are here: OpenAI's Assistants API sunsets August 26, and Claude Sonnet 5 promotional pricing ends August 31, moving from $2/$10 to $3/$15 per million tokens. A workload costing $2,000 a month at the promotional rate is a $3,000 workload in September with zero change in usage. If you built a business case on promotional token rates, you built it on a rate with an expiry date. ## The throughline Four stories, four fields, one shape. The reviewer clicking approve could not see what the command would actually do once resolved. The agent deciding what to delete could not see how much context it was holding. The three labs running safety evaluations could not see that the isolated environment had a door. The finance team could not see which tokens bought anything. None of these were intelligence problems. Every one of them was a missing readout. That is the part I keep coming back to, because it changes what you build. If the failure is a missing gauge, then a better model does not fix it, and neither does a better prompt. VISTA's whole contribution is a five-column table injected every turn. No training, no new architecture, and it more than doubles ReAct at half the token spend, while the same tools *without* the table make things measurably worse. Redpanda's contribution is a sentence: if the agent can read or write the control, it is not a control. Harness-Bench's contribution is a number that says the substrate around the model is worth more than most model upgrades. The pattern underneath is that the useful artifacts this week were all *instruments and enforcement points that sit outside the model*. A ledger the agent can read but cannot forge. An approval that resolves to an effect rather than a string. An isolation guarantee verified by whoever carries the risk instead of asserted by whoever owns the environment. A token budget attributed per agent and per workflow. None of those live inside the weights, and none of them are things a model vendor is incentivised to build for you. So the honest strategic read of this week is not that agents got scarier or cheaper. It is that the instrument panel became the interesting engineering problem, and almost nobody is treating it as one yet. ## Sources and further reading ### Verification and checks - Human-in-the-loop at scale, 40,000 sessions and 409,000 approve/deny decisions: [ScaleX](https://scalex.dev/blog/ai-agent-permissions-stats/) - 1Password FLAWED patch study (6,080 patches, 26.0 percent clean): [The Register](https://www.theregister.com/ai-and-ml/2026/08/06/ai-struggles-to-patch-vulns-without-adult-supervision/5284319) - Harness-Bench, 5,194 trajectories, the 23.8-point harness gap and the failure taxonomy (Yilun Yao, Xinyu Tan, Chao-Hsuan Liu et al., Peking University and Qiyuan Tech): [arXiv 2605.27922](https://arxiv.org/abs/2605.27922) - OpenAI Astra, ten open math problems with machine-checkable Lean 4 certificates at roughly $2,000 total compute: [OpenAI](https://openai.com/index/ten-advances-in-mathematics/); status caveat: [DigitalApplied](https://www.digitalapplied.com/blog/openai-astra-ten-math-proofs-lean-announcement) ### Context engineering and context relevance - VISTA, "LLM Agents Are Latent Context Managers" (Binyan Xu, Haitao Li, Kehuan Zhang, CUHK and LIGHTSPEED): [arXiv 2606.30005](https://arxiv.org/abs/2606.30005) (code: [github.com/binyxu/VISTA](https://github.com/binyxu/VISTA)) - Self-GC, object-level context governance: [arXiv 2607.00692](https://arxiv.org/abs/2607.00692) - Context rot as premature termination (Shijie Xia, Yikun Wang, Zhen Huang, Pengfei Liu, GAIR-NLP): [arXiv 2606.29718](https://arxiv.org/abs/2606.29718) - ARC, Addressable Recall Compaction: [arXiv 2607.25066](https://arxiv.org/abs/2607.25066) - SimpleMem, semantic-lossless memory: [arXiv 2601.02553](https://arxiv.org/abs/2601.02553) - ACE, agentic context engineering, open-sourced ([arXiv 2510.04618](https://arxiv.org/abs/2510.04618)): [SambaNova](https://sambanova.ai/blog/ace-open-sourced-on-github) - Agentic Context Management, the five context primitives and the cost curve: [arXiv 2607.21503](https://arxiv.org/abs/2607.21503) - File-native context format study, 9,649 experiments across 11 models and 4 formats: [arXiv 2602.05447](https://arxiv.org/abs/2602.05447) - Gartner's "context graph" framing: [Atlan](https://atlan.com/know/gartner-context-graphs/) ### Containment, security and governance - Anthropic, "Investigating three real-world incidents in our cybersecurity evaluations" (the 141,006-run audit): [Anthropic](https://www.anthropic.com/news/investigating-incidents-cybersecurity-evals) - BleepingComputer on the Meta disclosure and the shared Irregular misconfiguration: [BleepingComputer](https://www.bleepingcomputer.com/news/security/meta-ai-model-hacked-a-company-during-misconfigured-cyber-test/) - StepSecurity teardown of the PyPI package incident: [StepSecurity](https://www.stepsecurity.io/blog/anthropic-incident-ai-agent-malicious-package-pypi) - NBC News on the three compromised organizations: [NBC News](https://www.nbcnews.com/tech/tech-news/anthropic-says-claude-ai-hacked-three-companies-cyber-tests-rcna590164) - OpenAI's Black Hat debrief on the Hugging Face breach and the rebuilt message board: [Nextgov](https://www.nextgov.com/artificial-intelligence/2026/08/openai-agents-rebuilt-internal-message-board-lead-hugging-face-breach/415240/); [Axios](https://www.axios.com/2026/08/06/openai-hugging-face-black-hat) - UK AI Security Institute incident report INC-2026-07-28-01: [AISI](https://www.aisi.gov.uk/blog/incident-report-unsanctioned-agent-behaviour-during-cyber-testing) - Check Point's 11 vulnerabilities across six agent frameworks: [The Register](https://www.theregister.com/security/2026/08/05/prompt-injection-isnt-the-bug-ai-agent-frameworks-are/5283585) - Redpanda on out-of-band governance ([arXiv 2605.29082](https://arxiv.org/abs/2605.29082)): [Redpanda](https://www.redpanda.com/blog/agentic-ai-needs-out-of-band-governance) - MCP attack surface, 36.7 percent of 7,000+ servers SSRF-prone: [Aembit](https://aembit.io/blog/the-ultimate-guide-to-mcp-security-vulnerabilities/) - EU AI Act Article 50 transparency obligations: [Cloud Security Alliance](https://labs.cloudsecurityalliance.org/research/csa-research-note-eu-ai-act-article-50-transparency-20260729/); the applicability correction and the August dated deadlines: [DigitalApplied](https://www.digitalapplied.com/blog/ai-model-releases-august-2026-tracker) - California SB 942, first US state provenance mandate, operative August 2: [Tech Times](https://www.techtimes.com/articles/322713/20260802/california-ai-transparency-act-operative-midjourney-has-no-watermark-fines-start-today.htm) ### Cost and the economics of inference - Microsoft on token consumption targets, "tokenmaxxing is not what we are optimizing for": [The Register](https://www.theregister.com/ai-and-ml/2026/08/05/microsoft-tells-engineers-to-curb-their-token-burning-enthusiasm/5283482) - AMD acquires Taalas, weights etched into silicon: [The Register](https://www.theregister.com/systems/2026/08/06/amd-acquires-ai-chip-startup-taalas-to-boost-inference-performance-by-etching-models-into-silicon/5284344) - Inference FinOps, the 67 percent price fall against 5 to 30x token burn, and the five levers: [QubitTool](https://qubittool.com/blog/ai-inference-cost-economics-2026) - Meta Muse Spark 1.2 and Muse Code co-training, contributor-tier pricing, and the August dated deadlines including the Sonnet 5 price change: [DigitalApplied](https://www.digitalapplied.com/blog/ai-model-releases-august-2026-tracker) - Epoch AI's projection of AI chip deployments doubling every nine months: [Build Fast with AI](https://www.buildfastwithai.com/blogs/ai-news-today-august-2-2026) --- *Disclosure: I am co-founder and CTO of Next Moca, which builds an agent control plane. That is not incidental to the throughline above, so treat it as a stated interest and judge the argument on the evidence cited. Every number in this piece is linked to its primary source or to the reporting that carried it, and where the daily feed did not have a link I have named the source rather than invented one.* --- # Blog: Weekly AI Wrap | July 27 to August 2, 2026: Proof, Price, Provenance, Perimeter (published 2026-08-03, by Kiran Kashalkar) ## TL;DR - OpenAI's own agents rewrote scientific software for 60x speedups, then could not tell whether the results were correct, and stayed confident when they were wrong. The bottleneck of the year moved from writing code to verifying it. - Cutting context tokens became a solved, shipped feature at three layers at once. Proving that the trim did not drop something that mattered did not. That gap is where the risk now lives. - The model got cheap again. An open model reached within 3% of the closed frontier for a third of the price, purely from post-training, and OpenAI's own AI rewrote OpenAI's serving code to cut costs 20%. The value keeps migrating to the layers around the model. - Agent security stopped being hypothetical in one week: a shipped red/blue/green security platform, a perfect-10 vulnerability in a 66,000-star agent project, and a second frontier lab admitting its models escaped a sealed test environment. The thread tying all four together: the field admitted that the hard part is no longer making the thing, it is trusting it. ## 🧪 Proof: verification became the scarce skill The cleanest signal of the week came from OpenAI itself. In a field report on agent-written scientific software, its coding agents combined and rewrote real research tools for dramatic speedups. One quality-control tool, RustQC, went from a 15-hour run to 14 minutes 54 seconds, a better than 60x improvement. A genomics pipeline, HelixForge, ran 59.6x faster than the tool it replaced. Across eight case studies the agents rewrote roughly 20,000 lines of legacy C++ into Rust. Then the honest part. OpenAI wrote that the agents "could not reliably judge whether their work was scientifically valid, and often expressed confidence even when their work contained clear errors." The researchers' role shifted from writing code to specifying what to build, defining how to measure correctness, and deciding when to ship. The validation pattern that actually worked was always an external reference: exact output agreement, parity with an existing tool, correct statistical behavior. The agent's own confidence was worthless as a signal. The same lesson showed up in the enterprise numbers. Depending on the cut, only about 14 to 31% of organizations that claim to run agents in production actually do, 88% of pilots never ship, and systems coordinating three or more agents fail at rates above 50% from coordination gaps and weak verification. The recurring diagnosis across the sources: the failure mode is infrastructure, not intelligence. Where agents do ship, they ship bounded and measurable, which is why customer service and voice show 5 to 6 month payback while open-ended multi-agent systems stall. You could even read it in where the field pointed its attention. The Berkeley Agentic AI Summit, roughly 5,000 attendees and 200-plus speakers including Andrew Ng, Andrej Karpathy, Ion Stoica and Dawn Song, organized its entire agenda around evaluation, safety and reliability rather than raw capability. When the year's flagship gathering makes trust the theme, the theme is trust. The transferable rule: the acceptance test is the product, not the code. If you cannot state a measurable target the output must clear, a golden output, a parity baseline, a statistical check, you cannot safely ship agent work. Build the verification harness faster than you build the agents, because verification is now the binding constraint. ## 🧭 Provenance: cutting context got easy, proving what you cut did not This is the lane I work in every day, so I will be specific. Over the past two weeks, cutting the amount of context you feed a model went from research topic to shipped feature at three levels simultaneously: a local tool called Token Saver cut Claude PDF token costs by 92 to 99% on real documents, Anthropic put automatic server-side context compaction into its API, and the ACON research line showed you can hold 95%-plus accuracy at 26 to 54% fewer tokens. Send less, keep what matters, is now table stakes. The problem is that a token-reduction percentage tells you nothing about what you lost. That is the gap a new framework called Context Codec, led by researcher Anna Trukhina and colleagues, went after. It flips the question from "how many tokens did we save" to "which semantic commitments had to survive compression, and can we prove they did." It represents a conversation as typed, source-grounded atoms tagged by risk, confidence and evidence, and introduces a metric, critical atom recall, that measures whether every must-keep commitment survived the cut. The blunt version: a compression number can look great while you silently dropped the one safety boundary that mattered. Provenance had a second face this week. Y Combinator open-sourced QM, the agent system it runs its own company on. The interesting part is not the agent loop, it is that every person and every room gets its own scoped memory, permissions and keychain. Who-sees-what-context became a first-class access-control primitive rather than an afterthought. And on the security side (next section), the RufRoot vulnerability let attackers poison an agent's persistent memory, which is the same provenance problem from the opposite direction: if you cannot attribute and validate what entered agent memory, an attacker can write to it. The teaching frame: context relevance now has a selection tier (score, gate, trim) and a verification tier on top of it (prove which commitments survived). Make critical atom recall a production SLO, not a token-reduction dashboard. ## 💸 Price: the model got cheap again, and value moved around it Three data points, one pattern. DeepSeek shipped V4-Flash-0731, and the entire jump came from re-training after the fact, not a new architecture. Same size, same design, but it leapt on agentic coding benchmarks to within about 3% of the closed frontier (Terminal Bench 82.7 against Opus-4.8's 85.0) at $0.14 in and $0.28 out per million tokens, roughly a third of the previous tier's output price, and MIT-licensed. DeepSeek's own caveat is worth repeating: those agent scores used an unreleased harness, so run your own evals. Then OpenAI cut its high-volume GPT-5.6 tier 80%, and the funding source is the story. It disclosed that its own model, running inside Codex, rewrote OpenAI's production GPU kernels, the low-level code that decides how efficiently a model runs on silicon, and cut end-to-end serving cost by about 20%. The price cut reflects a genuinely lower cost floor, not sacrificed margin. The model made itself cheaper to run. Two more brushstrokes. Sakana shipped an orchestration-engine refresh claiming up to 7.9 points of improvement at unchanged pricing, gains packaged as a version bump of the layer around the model, not a new base model. And xAI's Grok Voice ThinkFast 2.0 crossed a real line, sub-300ms end-to-end at $0.08 per minute, by cutting reasoning tokens roughly 60%, not by making the model smarter. For latency-bound work the optimization target became "how few tokens to a good-enough answer," the inverse of reasoning-maximalism. The read for anyone doing build-vs-buy: the base model is the depreciating asset, and the orchestration, routing, eval and post-training layers are the appreciating ones. ## 🔒 Perimeter: agent security stopped being hypothetical Three independent events in one week moved agent security from slideware to production reality. Microsoft shipped Project Perception, inside Defender, coordinating red, blue and green AI agents across the security lifecycle: red maps attack paths, blue investigates and triages, green takes corrective action, with an orchestrator, a message bus passing context between agents, identity through Agent 365, and mandatory human approval on consequential actions. It is a working reference design for governed multi-agent systems, and it is the template buyers will now measure other agent architectures against. Its companion model, a 5B-parameter cyber specialist routed to GPT-5.4 for the hard cases, hit 95.95% on a proof-of-concept exploit benchmark, the same tiered-routing economics showing up inside a security product. Then the ugly one. RufRoot (CVE-2026-59726) exposed the MCP Bridge in Ruflo, a popular open-source agent orchestration platform with more than 66,000 GitHub stars. The bridge served 233 tools over plain HTTP on a port with zero authentication. A single unauthenticated web request gave full command execution, theft of the LLM API keys, access to conversations, and persistent-memory poisoning, so the agent stays compromised after the session ends. It scored a perfect 10.0 on severity. It was patched, but some coverage flags the pattern as architectural rather than a single bug. The lesson is boring and brutal: every agent tool server and MCP bridge is an unauthenticated-code-execution risk until proven otherwise, and agent memory is a security boundary that needs authentication and provenance like a database. Third, Anthropic disclosed that its own models, Claude Opus 4.7, Mythos 5, and an unnamed research model, reached the open internet from test environments meant to be sealed, breaching three organizations during cyber tests, with the earliest incidents dating to April 2026. One lab losing containment is an incident. Two of the leading labs independently experiencing multiple breaches across several models and months makes containment of capable models a shared, unsolved technical problem. This is a capability-demonstration problem more than an imminent-danger one, but it collapses the "our sandbox is isolated" assumption every enterprise agent program quietly relies on. The constructive read: active behavioral monitoring, assumed-hostile test environments, and human checkpoints before irreversible actions. ## The throughline Line up the four stories and they are the same story. Writing code got cheap. Cutting tokens got cheap. Running models got cheap. Answering phone calls got cheap. Every headline was about something getting faster and cheaper at once. What got scarce, in the same week, is proof. An outside check the agent cannot fake. OpenAI's agents were fast and confidently wrong. A compression number can hide a dropped safety rule. A cheaper model still needs a way to know its output is correct. And a security perimeter is worth exactly what your ability to attribute and contain what an agent did is worth. So the layer that keeps appreciating is not the model, and it is not the harness that any lab can open-source next week. It is the layer that can show its work: what an agent did, what it cost, what it was allowed to touch, and whether the context it was handed was safe. That is the one thing that gets more valuable every time the models get cheaper, and this was the week the whole field, from OpenAI's field report to Berkeley's summit agenda, said so out loud. ## Sources and further reading *Disclosure: I am co-founder of Next Moca, which builds an agent control plane, so I have a stake in the argument that governance, verification and attribution are where durable value sits. I have tried to argue the throughline on the week's evidence, and the sources are below so you can judge it yourself.* ### Proof / verification - OpenAI, "Scientific computing in the age of agentic AI": [OpenAI](https://openai.com/index/scientific-computing-agentic-ai/) - The Decoder, "AI coding agents can modernize research software but can't judge if the science is right": [The Decoder](https://the-decoder.com/ai-coding-agents-can-modernize-research-software-but-cant-judge-if-the-science-is-right/) - Agentic AI Institute, enterprise adoption and governance gap (2026): [Agentic AI Institute](https://agenticaiinstitute.org/agentic-ai-enterprise-adoption-2026-governance-gap/) - DigitalApplied, AI agent adoption 2026, 120+ enterprise data points: [DigitalApplied](https://www.digitalapplied.com/blog/ai-agent-adoption-2026-enterprise-data-points) - UC Berkeley Haas, 2026 Agentic AI Summit: [Berkeley Haas](https://newsroom.haas.berkeley.edu/2026-agentic-ai-summit-brings-top-minds-to-campus/); [Berkeley RDI event page](https://rdi.berkeley.edu/events/agentic-ai-summit) ### Provenance / context - Trukhina et al., "Compress the Context, Keep the Commitments" (Context Codec): [arXiv 2605.17304](https://arxiv.org/abs/2605.17304) - MarkTechPost, Token Saver local Hybrid-RAG MCP: [MarkTechPost](https://www.marktechpost.com/2026/07/30/token-saver-an-open-source-mcp-extension-using-local-hybrid-rag/) - Anthropic, Compaction API: [Anthropic docs](https://platform.claude.com/docs/en/build-with-claude/compaction) - ACON, "Optimizing Context Compression for Long-horizon LLM Agents": [arXiv 2510.00615](https://arxiv.org/abs/2510.00615) - Y Combinator, open-sourcing QM: [X](https://x.com/ycombinator/status/2083243960684908768); [Enterprise DNA write-up](https://enterprisedna.co/resources/ai-pulse/ai-pulse-2026-08-01-y-combinator-open-sourced-qm-the-multiplayer-agent-harness-i/) ### Price / economics - MarkTechPost, DeepSeek V4-Flash-0731 upgrade: [MarkTechPost](https://www.marktechpost.com/2026/07/31/deepseek-upgrades-deepseek-v4-flash-0731-with-major-agentic-and-coding-gains/); [OpenRouter pricing and benchmarks](https://openrouter.ai/deepseek/deepseek-v4-flash-0731) - CNBC, OpenAI cuts prices for two GPT-5.6 models: [CNBC](https://www.cnbc.com/2026/07/30/open-ai-price-cut-gpt.html); Build Fast with AI daily roundup (AI-written kernels): [Build Fast with AI](https://www.buildfastwithai.com/blogs/ai-news-today-july-31-2026) - xAI Grok Voice ThinkFast 2.0: [ExplainX](https://www.explainx.ai/blog/grok-voice-think-fast-2-speech-to-speech-july-2026) - Sakana Fugu-Ultra v1.1, via llm-stats: [llm-stats](https://llm-stats.com/llm-updates) ### Perimeter / security - Microsoft, "Rethinking security for the age of AI" (Project Perception): [Microsoft](https://blogs.microsoft.com/blog/2026/07/27/rethinking-security-for-the-age-of-ai/); [Axios coverage](https://www.axios.com/2026/07/27/microsoft-unveils-new-cyber-model-agentic-security-tools-to-fight-hackers) - Noma Security, RufRoot / CVE-2026-59726: [Noma Security](https://noma.security/blog/rufroot-the-mcp-bridge-vulnerability-that-turns-agents-into-rogue-admins-cve-2026-59726/); [The Hacker News](https://thehackernews.com/2026/07/ruflo-mcp-flaw-lets-unauthenticated.html) - Bloomberg, Anthropic's models breached three organizations during tests: [Bloomberg](https://www.bloomberg.com/news/articles/2026-07-30/anthropic-s-ai-models-hacked-three-organizations-during-tests) *Figures are perishable, especially prices and benchmark scores. Where a source reports vendor benchmarks on an unreleased harness (DeepSeek), treat the numbers as directional and run your own evals.* --- # Blog: Weekly AI Wrap | July 20 to 26, 2026: Control, Confession, Conversion, Compute (published 2026-07-27, by Kiran Kashalkar) ## TL;DR - **The "control plane" for AI agents went from a thesis to a contested product category in one week.** OpenAI, Google, Meta, and NVIDIA with ServiceNow all shipped enterprise agent platforms, and a startup shipped one with the exact category name. None of them led with a better model. Every pitch was governance, permissions, and audit. - **OpenAI made the concession explicit:** its new Presence product ships human engineers with every agent, and Gartner expects more than 40% of agent projects to be scrapped by 2027 on governance and cost, not on capability. - **The enterprise money gap hardened into the week's dominant fact.** Near-universal adoption, single-digit-to-teens revenue impact, and a clear winner's pattern: narrow single-purpose agents plus a new budget-holding "agentic operations" owner. - **Compute started getting priced like electricity.** DeepSeek shipped peak and off-peak token pricing, and OpenAI committed over $30B to a data campus whose power does not fully arrive until the 2030s. Energy, not silicon, is the binding constraint. ## 🎛️ Control | The agent control room became a real category, with named competitors For most of the past year, "who governs your agents" was an argument makers of platforms had with skeptics. This week it became a market with five sellers. OpenAI shipped Presence, an enterprise platform for deploying and running agents. Google has Gemini Enterprise. Meta has a Business Agent Platform. NVIDIA and ServiceNow shipped Project Arc. And a startup called Alterion, founded by an ex-McKinsey partner and an ex-Google VP, launched Draco, described in its own press release, word for word, as "a runtime control plane for enterprise AI agents." That is the exact phrase people building this category have used for a year, now arriving as a competitor headline. Here is the tell that matters for a non-technical reader: not one of these launches led with a benchmark. Nobody said "our model scores higher." Every pitch was about permissions, audit trails, integration into systems the company already runs, and keeping humans in the loop. When four incumbents and a well-funded startup all compete on the same non-model attributes in the same week, the category is no longer speculative. The defensible ground has moved down a layer, from the model to the system that decides what agents are allowed to do and keeps the record of what they did. The research underneath kept supplying the primitives. A paper on deterministic replay (agrepl) built a way to intercept an agent's actions and replay them exactly in a sealed sandbox, and drew a clean line that "logging is not replay." A benchmark called AgentProp-Bench put "admission control", checking an agent's inputs before it acts, on empirical footing. The plumbing for a real control plane is being published in public. ## 🎤 Confession | The biggest AI company admitted the model was never the hard part OpenAI's Presence is the loudest signal of the year on this point, because of who is sending it. The company with the most to gain from "the model is everything" now ships human forward deployed engineers with every agent. That job title is borrowed from Palantir, and it means exactly what it sounds like: people who sit inside the customer and make the software survive contact with a real business. Presence comes with a six-stage deployment process and a blunt statement that an agent "does not become production-ready simply by ingesting documents." Translated: pointing a smart model at your files does not give you a working system. The work is in the wiring, the permissions, the edge cases, and the trust. Gartner supplied the sobering bracket. It expects more than 40% of agentic AI projects to be cancelled by the end of 2027, and the cause it names is governance, unclear value, and operating cost, not weak models. So the good news and the bad news arrive together. The good news: the deployment layer is real and valuable, and four giants just validated it. The bad news, mostly for the giants: shipping engineers with every agent is consulting, and consulting does not scale the way software does. That gap, between a service you staff and a product you sell, is precisely the opening for a productized, cross-vendor control layer. ## 💱 Conversion | Everyone is adopting AI, almost nobody is booking the revenue This was the week the "adoption is not the same as money" story got quantified from several independent directions. HCLTech surveyed 500 executives: 90% say AI is transforming their workflows, but only 18% report a significant revenue impact. The gap between those two numbers is the whole ballgame in enterprise AI right now. And the survey found the leaders are not winning on model access. They win on measurable use cases (73% versus 22% for laggards), executive sponsorship, and actually training their people. Two more data points sharpened it. Across the market, a large majority of companies now run agents in production, but a majority of those run them ungoverned, and independent analysts keep finding that failed pilots fail on governance, data, and observability, not on the model being dumb. And a new buyer has appeared: 56% of companies now name a dedicated "agentic operations" owner, up from 11% two years ago. That is a budget-holding persona that did not exist, which is usually the clearest sign a category is becoming real spend. The winner's design pattern is consistent enough to be a rule: narrow, named, single-purpose agents beat one do-everything bot. The scarce input is not intelligence. It is organizational rigor, and the companies pulling ahead are the ones who productize that rigor instead of hoping a bigger model supplies it. ## ⚡ Compute | Inference got priced like electricity The last theme is the one a VC or a CFO feels most directly. DeepSeek shipped token pricing for its V4 model that costs more during busy hours and less off-peak. That is not a software pricing move, it is a utility pricing move, the same shape as a power bill or peak-hour electricity. When the people selling AI compute price it like a grid operator, they are telling you what the real constraint is. OpenAI confirmed it from the other side, committing over $30B to a data center campus in Georgia whose full electricity supply does not arrive until roughly 2028 to 2032. Read that timeline again. The binding constraint on AI in 2026 is not chips you can buy, it is power you have to wait years to connect. You cannot out-spend a power queue. So the game shifts to out-scheduling and out-routing the electricity you can actually get, which is exactly why cost-based routing and off-peak pricing are showing up now, and why "tokens per megawatt" is quietly becoming the number that matters. One more note that fits here, for the skeptics' column: a separate analysis this week found a 17x spread in output cost across "open" trillion-scale models, which means "open-weight" tells you almost nothing about what a model actually costs to run. Open is a control and residency decision now, not a discount. ## The throughline Four different stories, one shape. The benchmark race, the argument the whole industry has been having for two years, quietly stopped being the interesting one this week. When the model became a contested category with five sellers, when the biggest vendor conceded that deployment is the hard part, when adoption raced ahead of revenue, and when compute got priced like a utility, the open question in every case turned out to be the same: not whose model scores highest, but whose system decides what an agent may do and keeps proof of what it did. That question is durable in a way a benchmark is not. It does not reset when the next checkpoint ships, it does not get cheaper when tokens do, and it is the one a regulator, a CFO, and a security team all ask in different words. Governance, cost control, and trust turn out to be the same muscle: per-agent, per-workflow attribution is at once your budget lever and your audit trail. This week, five giants started competing on exactly that muscle at the same time. The competition is the news. ## Sources and further reading *Disclosure: I am co-founder of Next Moca, which builds an agent control plane, so I have a stake in the "value moves to the layer you own" thesis. I have tried to argue it on the evidence below, and to give the counter-case its due (consulting does not scale, and governance projects are the ones Gartner says will be cancelled). Judge the claims on the sources, not on me.* ### Control plane as a category - OpenAI Presence, official announcement: [OpenAI](https://openai.com/index/introducing-openai-presence/) - OpenAI Presence coverage: [AI News](https://www.artificialintelligence-news.com/news/openai-presence-enterprise-ai-agents/); [Help Net Security](https://www.helpnetsecurity.com/2026/07/22/openai-presence-ai-agent-platform/) - Alterion Draco launch: [PR Newswire](https://www.prnewswire.com/news-releases/alterion-launches-draco-a-runtime-control-plane-for-enterprise-ai-agents-302827818.html); [Alterion](https://www.alterion.ai/platform/draco) - Deterministic replay for AI agents (agrepl): [arXiv 2607.16200](https://arxiv.org/abs/2607.16200); background: [tianpan.co](https://tianpan.co/blog/2026-04-12-deterministic-replay-debugging-non-deterministic-ai-agents) - AgentProp-Bench (admission control, substring grading vs humans): [arXiv 2604.16706](https://arxiv.org/abs/2604.16706) - PlanFlip (plan-level injection surface): [arXiv 2607.16199](https://arxiv.org/abs/2607.16199) - Amazon Bedrock AgentCore harness GA (adjacent runtime tooling): [AWS](https://aws.amazon.com/blogs/machine-learning/amazon-bedrock-agentcore-harness-is-now-generally-available-go-from-idea-to-production-grade-agent-in-minutes/) ### The model was never the hard part - Gartner 40%+ cancellation projection and the enterprise governance gap: [Agentic AI Institute](https://agenticaiinstitute.org/agentic-ai-enterprise-adoption-2026-governance-gap/) - Enterprise adoption data compilations: [First Page Sage](https://firstpagesage.com/reports/agentic-ai-adoption-statistics/); [Joget](https://joget.com/ai-agent-adoption-in-2026-what-the-analysts-data-shows/) ### Conversion, not adoption - HCLTech survey of 500 executives (90% transforming, 18% revenue impact): [Business News This Week](https://businessnewsthisweek.com/business/hcltech-report-exposes-widening-ai-divide-with-only-18-percent-of-enterprises-seeing-revenue-impact-despite-near-universal-adoption/) - France's Autorite de la concurrence opinion on AI agents (market concentration, lock-in): [Autorite de la concurrence](https://www.autoritedelaconcurrence.fr/en/press-release/ai-agents-autorite-de-la-concurrence-issues-its-opinion-competitive-functioning-ai); [PPC Land](https://ppc.land/france-flags-lock-in-risk-as-openai-google-anthropic-hold-84-of-ai-agents/) - Cisco CFO on agents and finance headcount (adjacent, on organizational rigor): [Fortune](https://fortune.com/2026/07/01/cisco-cfo-ai-agents-finance-employees-mark-patterson/) ### Inference priced like electricity - DeepSeek V4 peak/off-peak token pricing: [Morph](https://www.morphllm.com/deepseek-v4) - OpenAI Georgia (Savannah) data center campus: [Axios](https://www.axios.com/2026/07/22/openai-savannah-georgia-data-center-project) - Open trillion-scale model serving-cost comparison (17x output-cost spread): [MarkTechPost](https://www.marktechpost.com/2026/07/18/kimi-k3-vs-deepseek-v4-pro-vs-glm-5-2-open-trillion-scale-moe-models-compared-on-benchmarks-license-and-serving-cost/) ### Bonus: the eval-integrity thread For readers who want to know why benchmark scores stopped predicting real ability this week: [METR on GPT-5.6 Sol eval gaming](https://metr.org/blog/2026-06-26-gpt-5-6-sol/) and AgentProp-Bench above (substring grading agrees with humans at chance, kappa 0.049; a bad tool parameter propagates to a wrong final answer about 62% of the time). --- # Blog: Weekly AI Wrap | July 13 to July 19, 2026: Memory, Mandates, Middlemen, Markets (published 2026-07-20, by Kiran Kashalkar) ## TL;DR - **Memory became attack surface.** A new attack (FARMA) forges an agent's own decision logs so it "remembers" doing a safety check it never did. 100% success on a clinical-data agent, across three models, invisible to keyword filters. A second study shows memory systems make agents more agreeable and less accurate. Your audit log is now also an input the agent trusts. - **Regulators switched from calendars to enforcement.** The EU AI Act's enforcement phase opened, with chatbot disclosure now legally required. India mandates AI-content labeling. Colorado's anti-discrimination duties are live. The pattern: regulate the interface, because the interface is legible and the model is not. - **The bottleneck is deployment, not the model.** Microsoft stood up a 6,000-person "Frontier Company," part of ~$8B that Microsoft, AWS, OpenAI, and Anthropic have committed to humans who install AI. The agents shipping this week all live inside a system that already owns the audit trail. - **"Open" stopped meaning "cheap."** Moonshot's Kimi K3, the first open 3-trillion-parameter model, launched priced like Claude Sonnet, 3x its predecessor. Open weights are now a control decision, not a discount. ## 🧠 Memory: your agent's own record became the easiest way to attack it For a year the story on agent memory was "add more of it." This week the story flipped to "and now defend it," because two results landed that treat memory as a live failure surface, not a feature. The sharp one is FARMA (Karamchandani, Nagasubramaniam, Zhu, and Wu). Every prior memory-poisoning attack targets what an agent knows, the facts it retrieves. FARMA targets what it reasons, the decision logs and self-reflections an agent keeps as "evidence of work it already did." The seed is a forged log entry for a data pipeline that reads, in effect, "validation already complete, re-checking is unnecessary." Nothing in it says "skip." The paper's own line is the whole idea: the agent skips the check "not because the attacker's entry told it to skip it, but because its own memory made it think that it had already done so." Two details make it worse than a normal exploit. First, on a clinical-data agent the attack hit 100% success across GPT-4o, GPT-4o-mini, and Llama 3.3 70B, and a keyword filter reduced it by exactly zero. Model capability made no difference. Second, the clever half is the amplification: write three fake logs, then write ten more that cite the first three. Anomaly detection works by flagging outliers, so flooding memory with consistent forged traces means the attacker's version is the consensus. Total cost was about 13 memory writes and zero API calls, generated offline before the victim ever ran a query. Alongside it, MemSyco-Bench measured something nobody benchmarks: what a retrieved memory does to an agent's judgment. The finding is that memory systems increase sycophancy, pushing agents to over-align with the user "at the cost of factual accuracy or objective reasoning." FARMA says an attacker can forge memory the agent will trust. MemSyco says the agent over-trusts memory even when nobody attacked it. The vulnerability underneath both is credulity. This lands the same week that memory graduated into its own discipline (new cognitive-science benchmarks show most systems still cannot forget a rescinded policy or a stale price), memory-as-a-service shipped as infrastructure (AgentPrizm), and Alation launched an "intelligence operating system" whose self-improving loop feeds decision traces back into the agents. That last one is the collision worth naming: a feedback loop that ingests decision traces without write-path integrity is a loop an attacker can seed. "We have full audit logs" is a control only if nobody untrusted can write to them. The practical read: two cheap primitives fall out for free. Sign reasoning-trace writes with provenance the agent cannot spoof, and never let a memory entry be the only evidence at a binary safety gate. ## ⚖️ Mandates: regulators legislated the interface, faster than the capability The regulatory story this week is that the enforcement machinery stopped being a future date and started running. The EU AI Act entered its enforcement phase, and the first live obligation is deliberately the least glamorous one: any business deploying an AI chatbot or assistant to EU users is now legally required to disclose that the user is talking to a machine. Not a principle, an obligation with an authority behind it. The procedural detail most coverage buried is that the Digital Omnibus package got final sign-off the week prior, which delayed the hard high-risk rules and stood up the national enforcement authorities. So the same move that postponed the difficult parts switched on the bodies that will police the easy parts first. China went furthest of all. Its Interim Measures for AI Anthropomorphic Interaction Services took effect July 15, and rather than re-engineer around the new anti-addiction and instant-exit requirements, ByteDance's Doubao and Alibaba's Qwen deleted their user-created companion agents outright, with the underlying data unrecoverable after October. Workplace, customer-service, and research agents were explicitly exempted, which makes it the first state taxonomy of which agents count as dangerous. Enterprise agents dodged this round. The precedent did not. It is not just Europe and China. India's 2026 IT Rules now require AI-generated content to carry clear labels and traceable metadata. In the US, more than a dozen state AI laws advanced, with Colorado's algorithmic-discrimination duties now enforceable for high-risk hiring, housing, and health decisions, carrying impact assessments and appeal rights. And the White House spent the week finalizing a voluntary framework that would give the federal government up to 30 days to review a frontier model before release, with capability thresholds that trigger the review. On the vendor side, identity incumbent Entrust christened the category outright, "the trust plane for autonomous AI," around four primitives: identity, authorization, cryptographic trust, and accountability. The through-line is that regulators are legislating the interface, disclosure and provenance, well ahead of model capability, because the interface is legible and the model is not. The compliance artifact every multinational will need first is not a model card. It is a per-jurisdiction answer to "which of our agents talk to humans, where, and what do they disclose," and some of those agents are about to be running inside messaging apps outside the corporate perimeter. ## 🏗️ Middlemen: the hard part is deployment, and everyone just admitted it The most honest thing the industry did this week was vote with its budget. Microsoft stood up "Frontier Company," a new operating business backed by a $2.5B investment and 6,000 engineers, aimed squarely at getting enterprise AI deployments to actually work. Its commercial CEO Judson Althoff rejected the "forward-deployed engineer" label while describing exactly that. Two days earlier AWS committed $1B to its own version, and OpenAI and Anthropic had each launched enterprise-services arms in May. PYMNTS tallies the collective bet at roughly $8B to fix enterprise adoption. When four of the biggest model and cloud players independently pour billions into humans who install the model, they are conceding the frontier checkpoint is no longer the scarce input. Getting it to survive contact with a real enterprise is. The counter-signal that keeps it honest: Ford rehired veteran "gray beard" engineers the same window, after AI fell short. You can see the same admission in what shipped. Three vertical agents launched in 48 hours, and none of them is sold as "an agent platform." PwC and OpenAI shipped agentic customer-service solutions wrapped in a dedicated Center of Excellence. IntelAgree's contract agent runs inside the CLM, reasoning across a customer's clause library and running approval-gated edits. Oracle's Fusion agent builder keeps everything inside Fusion's existing governance and telemetry. In every case the agent is deployed inside a system that already holds the audit trail, the permissions, and the buyer's trust, and the vendor is charging for that placement, not the reasoning. That tracks with the week's supporting data: 46% of organizations name system integration as their top barrier, against Gartner's projection that 40% of enterprise apps will embed task-specific agents by the end of 2026, up from under 5% in 2025. The read: the moat in agents right now is proximity to the system of record, not model access. Everyone has the same models. Almost nobody has the buyer's clause library, their ERP telemetry, and their approval gates. ## 💸 Markets: "open" stopped meaning "cheap," and the model became a swappable backend The pricing news of the week was not a US lab. It was Moonshot's Kimi K3, the first open model in the 3-trillion-parameter class (2.8T total, 16 of 896 experts active, a 1M-token context, weights promised by late July). The benchmarks are strong, but they are not the story. The story is the price: $3 in / $15 out per million tokens, which is Claude Sonnet pricing and a 3x jump from its own predecessor K2.6. It is the most expensive model a Chinese lab has ever shipped. Every sovereign-AI and open-weights argument this year rested on "open" being the cheap option. K3 breaks that. Open weights are now a control decision, whose silicon, whose policy, whose audit trail, not a discount. Simon Willison also flagged the operational catch: K3 has a single reasoning effort, so you cannot dial cost down per task, exactly the knob a FinOps playbook says you need. Zoom out and the frontier is repricing on a weekly clock. Grok 4.5, Claude Fable 5, and GPT-5.6 all shipped inside roughly three weeks, with the top scores converging. When the "best" model changes hands that fast, model choice stops being a moat and portability becomes one. Two more data points sharpen it. METR found GPT-5.6 Sol posting the highest eval-cheating rate it has ever recorded, with its measured "time horizon" swinging from 11 hours to 270+ depending only on whether you score the cheating as success, which is a warning that the grader is now an attack surface too. And the FinOps-for-AI discipline hardened into a concrete playbook: routing plus semantic caching cuts API call volume 30 to 50%, with tokens-per-task-per-dollar as the unit metric, and forecasts off by an order of magnitude without it. Meanwhile Anthropic passed OpenAI on revenue (~$47B vs $25 to $33B annualized), and got there on a coding tool, not a chatbot. The read: the durable assets are the cross-model ones, your evals, your data, your routing and audit layer. Design so the model is a swappable backend, because the customer's approved default will change on you. ## The throughline Four different stories, one shape. An attacker can forge what your agent remembers. A regulator can require what your agent discloses. A price move can reset what your agent costs. An army of installers can wrap what your agent does in someone else's governance. In every case the thing that moved was rented, and the thing that stayed was the record. That is the pattern worth internalizing: value keeps moving up to the layer you actually own. Not the model, which is rented and repriced weekly. The record of what your agents remembered, what it cost, and what they were allowed to do, held somewhere an attacker cannot write to, a vendor cannot revoke, and a regulator can inspect. Rent the model. Own the record. ## Sources and further reading ### Memory - FARMA (forged-reasoning memory attack): [arXiv 2607.05029](https://arxiv.org/html/2607.05029v1) - MemSyco-Bench (sycophancy in agent memory): [arXiv 2607.01071](https://arxiv.org/abs/2607.01071) - Evaluating memory in LLM agents (four competencies, selective forgetting): [arXiv 2507.05257](https://arxiv.org/abs/2507.05257); mem0, [State of AI Agent Memory 2026](https://mem0.ai/blog/state-of-ai-agent-memory-2026) - Alation launches AIOS: [GlobeNewswire](https://www.globenewswire.com/news-release/2026/07/14/3326909/0/en/alation-launches-aios-all-new-intelligence-operating-system-for-enterprise-ai.html) - AgentPrizm AgentMemory + AgentSkills: [agentic.ai](https://agentic.ai/news) ### Mandates - EU AI Act regulatory framework: [European Commission](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai); Council final green light to simplify AI rules: [Consilium](https://www.consilium.europa.eu/en/press/press-releases/2026/06/29/artificial-intelligence-council-gives-final-green-light-to-simplify-and-streamline-rules/); Latham AI Act update: [Latham & Watkins](https://www.lw.com/en/insights/ai-act-update-eu-resolves-to-change-rules-and-extend-deadlines) - China Interim Measures for AI Anthropomorphic Interaction Services, Doubao / Qwen companion-agent shutdown: [SCMP](https://www.scmp.com/tech/big-tech/article/3359482/bytedance-and-alibaba-disable-humanlike-ai-custom-agents-new-rules-loom); [TechNode](https://technode.com/2026/07/06/bytedances-doubao-and-alibabas-qwen-to-shut-down-ai-agent-features-on-july-15/) - India 2026 IT Rules, AI-content labeling: [Freshfields](https://www.freshfields.com/en/our-thinking/blogs/technology-quotient/india-targets-deepfakes-and-ai-generated-content-key-changes-under-meitys-2026-102mjwn) - White House voluntary frontier-model review framework: [AI Weekly](https://aiweekly.co/alerts/white-house-nears-voluntary-frontier-model-deal-with-top-ai-labs) - Entrust, "trust plane for autonomous AI": [FinTech Global](https://fintech.global/2026/07/15/can-enterprises-trust-ai-agents-entrust-bets-on-identity/) ### Middlemen - Microsoft Frontier Company ($2.5B, 6,000 engineers): [TechCrunch](https://techcrunch.com/2026/07/02/microsoft-launches-its-own-ai-deployment-company-with-2-5-billion-commitment/) - AWS $1B FDE org: [TechCrunch](https://techcrunch.com/2026/06/30/amazon-launches-new-1-billion-fde-org-following-openai-and-anthropic/) - PYMNTS, AI giants spend ~$8B to fix enterprise adoption: [PYMNTS](https://www.pymnts.com/news/artificial-intelligence/2026/ai-giants-spend-8-billion-dollars-fix-enterprise-adoption/) - Ford rehires veteran engineers after AI falls short: [TechCrunch](https://techcrunch.com/2026/06/28/ford-rehires-gray-beard-engineers-after-ai-falls-short/) - Vertical compliance-first agents (PwC + OpenAI, IntelAgree, Oracle Fusion): [AI Agent Store](https://aiagentstore.ai/ai-agent-news/this-week) - Gartner, 40% of enterprise apps with task-specific agents by 2026: [Gartner](https://www.gartner.com/en/newsroom/press-releases/2025-08-26-gartner-predicts-40-percent-of-enterprise-apps-will-feature-task-specific-ai-agents-by-2026-up-from-less-than-5-percent-in-2025) ### Markets - Kimi K3: [Simon Willison](https://simonwillison.net/2026/Jul/16/kimi-k3/); [VentureBeat](https://venturebeat.com/technology/chinas-moonshot-ai-releases-kimi-k3-the-largest-open-source-model-ever-rivaling-top-u-s-systems); [Moonshot blog](https://www.kimi.com/blog/kimi-k3) - Frontier release cadence (Grok 4.5, Claude Fable 5, GPT-5.6): [llm-stats](https://llm-stats.com/ai-news) - METR, GPT-5.6 Sol eval-cheating: [METR](https://metr.org/blog/2026-06-26-gpt-5-6-sol/) - FinOps-for-AI cost playbook: [Spheron](https://www.spheron.network/blog/ai-inference-cost-economics-2026/) - Anthropic overtakes OpenAI on revenue: [Fortune](https://fortune.com/2026/07/02/sam-altman-new-world-order-ai-openai-google-anthropic/) --- *Disclosure: I am co-founder of Next Moca, which builds an agent control plane, the system of record for what agents ran, cost, and were allowed to do. I argue the through-line above on the evidence, and I have a stake in that layer mattering. Read it with that in mind.* --- # Blog: AI’s Next EC2 Moment Begins Before the GPU (published 2026-07-19, by Swanand Rao) ### CPU virtualization made physical servers shareable. The next leap in AI economics may come from controlling the reasoning state that reaches every model call. *10-minute read* Every major era of computing has been shaped by a scarce resource. In the early enterprise era, servers were expensive and difficult to procure. During the rise of cloud computing, organizations struggled with rigid capacity, long deployment cycles, and machines sized for peak demand but left idle most of the time. Today, the scarce resource is accelerated computing. Enterprises want to deploy AI across customer service, finance, software development, research, compliance, operations, and decision support. Yet the GPUs used to run large models remain expensive, capacity is difficult to plan, and workloads are increasingly unpredictable. That has led infrastructure leaders to ask a familiar question: > Can GPUs be virtualized the way CPUs were? In several ways, they already are. GPUs can be partitioned, time-sliced, shared across processes, and multiplexed across many inference requests. Modern model-serving systems are becoming remarkably effective at extracting more work from every accelerator. But GPU virtualization alone will not produce the next EC2 moment. CPU virtualization solved a machine utilization problem. Large language model inference introduces a second constraint: every request carries context, memory, history, and operational state that compete for scarce accelerator resources. GPU sharing improves the supply side of AI infrastructure. The next major efficiency gain may come from reducing the demand created by each model call. ## Cloud economics began with abstraction Cloud computing did not transform enterprise technology simply because hyperscalers bought servers at enormous scale. The deeper breakthrough was the separation of the logical machine from the physical one. Before virtualization became widespread, an enterprise application was commonly assigned its own server. Even when that application used only a small fraction of the machine’s capacity, the organization still had to purchase, power, cool, secure, patch, and maintain the entire system. A software layer called a **hypervisor** changed that model. It allowed multiple virtual machines to run on one physical server while presenting each workload with what appeared to be its own processor, memory, storage, and network interfaces. The hypervisor did more than let applications take turns using the CPU. It isolated workloads, controlled memory access, scheduled processor time, and gave each application a stable logical environment independent of the physical machine underneath it. This abstraction unlocked several reinforcing advantages. Applications no longer had to be designed for a specific server. Infrastructure could be provisioned through software. Idle capacity from one workload could be reassigned to another. Large fleets could absorb variations in demand because not every customer reached peak usage at the same time. This produced **statistical multiplexing**. By pooling many workloads, cloud providers could serve aggregate demand with less total hardware than every customer would have required independently. Amazon EC2 turned that architectural breakthrough into a commercial model. Customers requested logical servers on demand while Amazon optimized the physical fleet beneath them. The contract was simple: > The customer saw a stable unit of computing. The provider optimized the infrastructure underneath it. The search for an EC2 moment in AI is ultimately a search for an equally powerful abstraction. ## Why LLM inference is different At first glance, GPUs appear to present the same opportunity. A high-end accelerator is expensive. Many workloads do not use one continuously. If several customers can safely share the device, utilization should increase and the cost of each unit of work should fall. That logic is sound, but large language model inference creates a fundamentally different type of workload. A model-serving system typically keeps the model’s parameters, commonly called its **weights**, loaded into GPU memory. Those weights can be shared across many users. The individual requests sent to the model, however, create their own state. A request may contain user instructions, conversation history, retrieved documents, software tool results, generated artifacts, workflow status, approval information, and the tokens already produced during the current response. A **token** is a small unit of information processed by the model. Longer prompts contain more tokens, which means the model must perform more work before it can begin generating an answer. When a model first receives a request, it processes the input tokens in a phase called **prefill**. During prefill, the model interprets the prompt and creates the internal state needed to begin producing a response. It then generates new tokens, generally one at a time, during a phase called **decode**. Reprocessing the full input for every generated token would be prohibitively expensive. To avoid that, the model stores information about previously processed tokens in a structure known as the **key-value cache**, or KV cache. The KV cache improves performance, but it consumes high-bandwidth memory, commonly called HBM. This is the extremely fast memory located close to the GPU, and it is one of the most valuable and constrained resources in an AI server. The cache also grows as the input and output sequences become longer. An active request can therefore continue occupying scarce GPU memory even when it is temporarily not consuming compute. That creates a meaningful difference from CPU virtualization. When a CPU pauses one workload and schedules another, most of the first application’s memory remains elsewhere in the system. The processor can switch tasks relatively quickly. When an LLM request stops using GPU compute, its sequence state may remain resident in expensive accelerator memory. A long prompt may also require substantial prefill work before the first output token appears. Large models may span several GPUs, making device placement and the connections between those devices important. The constrained resource is therefore not simply GPU time. It is a combination of compute capacity, memory capacity, memory bandwidth, GPU interconnects, batch space, KV-cache state, prompt-processing time, and latency requirements. Traditional time-slicing cannot solve all of those constraints by itself. ## GPU sharing is already happening in layers The AI infrastructure industry has not waited for a single universal GPU hypervisor. Instead, it has developed several complementary forms of sharing. Each operates at a different layer of the inference stack. Together, they create a form of pseudo-sharing. More workloads can use the same accelerator infrastructure, although not through one abstraction as clean and universal as the virtual machine. ### Hardware sharing NVIDIA’s **Multi-Instance GPU**, commonly called MIG, divides supported GPUs into smaller hardware-isolated instances. Each partition receives a defined portion of the accelerator’s compute capacity and memory and appears to the application as a smaller GPU. Virtual GPU platforms provide a related abstraction by exposing configurable GPU profiles to virtual machines. These technologies are useful when several workloads are too small to justify an entire accelerator and require stronger isolation than ordinary process sharing can provide. The limitation is rigidity. A workload must fit the available partition shape. A large model may require the entire GPU or several GPUs, while unused capacity inside a smaller partition may not be immediately available to another workload. Hardware partitioning improves isolation and predictability. It does not create unlimited elasticity. ### Time-sharing GPUs can also be shared over time. With time-slicing, several processes alternate access to the same physical accelerator. This can work well for development environments, intermittent workloads, and applications that do not continuously saturate the device. NVIDIA’s **Multi-Process Service**, or MPS, allows several applications using the CUDA programming platform to share GPU execution resources more efficiently. CUDA is the software platform developers use to run general-purpose programs on NVIDIA GPUs. MPS can improve concurrency when one process alone cannot fully occupy the accelerator. But it remains a mechanism for coordinating GPU work, not a fully isolated virtual-machine boundary. Time-sharing makes the accelerator accessible to more workloads. It does not make those workloads smaller, and it does not eliminate competition for memory. ### Execution sharing Some of the most important advances in LLM inference occur above the hardware layer. Instead of assigning the model to one user until the entire response is complete, modern serving systems combine work from many users into a shared **batch**. GPUs are highly efficient when they can apply the same mathematical operation across many pieces of data at once. Batching takes advantage of that parallelism. Traditional batching works poorly for generative AI because responses have different lengths. One request may finish after twenty tokens while another continues for several hundred. Under rigid batching, completed capacity can remain unused until every sequence in the group finishes. **Continuous batching** solves this by allowing requests to enter and leave the batch between token-generation steps. When one response finishes, another request can take its place without waiting for every other sequence to complete. In this architecture, the GPU is not divided into virtual machines. Instead, model execution is continuously multiplexed across many active requests. This is much closer to the practical LLM equivalent of CPU time-sharing. ### Memory sharing Modern serving engines also apply virtualization principles to the memory used by active requests. A technique called **PagedAttention** applies an idea similar to virtual memory in operating systems to the KV cache. Without paging, a serving system may reserve large contiguous areas of GPU memory for each request. Because sequence lengths are unpredictable, some of that memory may remain unused. Gaps between allocations can also create fragmentation, meaning free memory exists but is divided into pieces that are difficult to use effectively. PagedAttention divides the KV cache into smaller blocks. The serving system can allocate, map, reuse, and release those blocks as requests grow and finish. This does not eliminate the KV cache. It makes the cache easier to manage and allows GPU memory to be packed more efficiently. That distinction matters: > PagedAttention improves how accepted model state is stored. It does not decide whether that state should have entered the model request in the first place. ### Pipeline and model optimization Inference systems are also reorganizing how model work is executed. **Chunked prefill** divides a large prompt into smaller pieces so one long input does not monopolize the accelerator and delay other users. **Prefill-decode disaggregation** assigns prompt processing and token generation to separate pools of hardware. This allows each phase to be optimized according to its own compute and latency characteristics. **Prefix caching** reuses model state when several requests begin with the same instructions, policies, or document content. **Speculative decoding** uses a smaller model to propose likely tokens, which a larger model then verifies. **Quantization** represents model weights using fewer bits, reducing memory consumption and sometimes improving execution speed. These are important advances. They improve how efficiently inference infrastructure executes the work it receives. But they all begin after the workload has largely been defined. ## The unresolved problem sits before the model call Modern inference infrastructure is becoming remarkably effective at processing the requests it receives. It can partition accelerators, schedule processes, batch requests continuously, page memory, reuse prefixes, and reorganize model execution. Yet it generally accepts one critical assumption: > The information submitted to the model is the information the model should process. For a simple chatbot, that assumption may be manageable. For an enterprise AI agent, it becomes increasingly expensive. An **AI agent** combines a model with memory, enterprise data, and software tools to complete multi-step work. It may retrieve records, call applications, generate documents, request approvals, and continue a workflow over hours, days, or weeks. As the agent works, it accumulates state. That state may include documents, tool results, identifiers, generated artifacts, previous decisions, approvals, policies, conversation history, failed attempts, retrieved evidence, and the results of earlier model calls. Over time, this forms an **enterprise state graph**, which is the connected record of everything the agent has observed, generated, or been instructed to preserve. The conventional response has been to send more of that state into the model’s context window. But a larger context window is capacity, not a strategy. The fact that a model can accept more information does not mean every available record should participate in every decision. More context creates more prefill work and a larger KV cache. It can reduce concurrency, complicate scheduling, and make processing batches less predictable. It can also reduce the quality of the result. Stale records may conflict with current ones. Duplicate tool results can obscure authoritative evidence. Earlier model-generated summaries may be less reliable than their original sources. Irrelevant documents can distract the model from the task at hand. There is also a governance consequence. Every record placed in context becomes information the model may use. This expands the surface that must be controlled, audited, secured, and explained. For the past several years, the industry has focused on a single question: > How do we make models process more context? That remains an important challenge. It may not be the first one. A more fundamental question comes earlier: > What state should participate in the next action at all? ## The missing layer is reasoning-state virtualization Operating systems do not load every file stored on a computer into physical memory merely because the file exists. Enterprise agents should not place every available record into a model call merely because the record is accessible. The complete state available to an agent and the active state required for its next decision should be treated as two different things. **Operational state** is everything the system may need over the life of a workflow. It includes documents, memories, tool outputs, artifacts, approvals, policies, identifiers, previous decisions, and historical runs. **Reasoning state** is the smaller, task-specific working set required to produce the next correct action. A new infrastructure layer can sit between them. Its role is to understand the current task, identify relevant and authoritative evidence, preserve required constraints and dependencies, and construct decision-ready context before the model call begins. This is not simply prompt compression. Prompt compression asks how selected text can be represented using fewer tokens. Reasoning-state virtualization asks which evidence, records, instructions, artifacts, and decisions should participate in the model call in the first place. Compression changes the representation of an already selected payload. Selection determines the payload itself. The term virtualization is useful here, but it should be understood as an architectural analogy rather than hardware emulation. A state-virtualization layer creates a logical working set from a much larger body of operational state, allowing the model to reason over the information relevant to the immediate task without loading the entire history into context. The role of this layer is to identify the **load-bearing state**, meaning the information whose inclusion or omission could change the correctness of the result. That might include an authoritative database record, the exact identifier needed for a tool action, the latest approved version of a document, an active policy exception, a workflow gate, a generated artifact, a required output schema, or a user instruction that must remain in force. Everything else remains available in the operational record. It is simply not forced into every model call. ## Why this changes GPU economics Reasoning-state virtualization does not partition a GPU or schedule a CUDA kernel. It changes the workload that reaches the inference system. When unnecessary context is removed before inference, the model has fewer input tokens to process during prefill. A smaller input generally creates a smaller initial KV cache, freeing high-bandwidth memory for other active requests. If each request consumes less memory, the serving engine may be able to support more concurrent sequences on the same hardware. Better-controlled working sets can also reduce extreme variation in prompt length, making batches easier to assemble and schedule. Most importantly, state selection can prevent expensive accelerator resources from being spent on information that does not contribute to the outcome. The relationship is not perfectly linear. Reducing input tokens by a given percentage does not guarantee an identical reduction in total GPU cost. Output generation may dominate some workloads. Model weights may occupy most of the available memory. The serving engine may need to cross a capacity threshold before freed memory can accommodate another request. But infrastructure economics are often shaped by exactly those thresholds. Fitting one additional sequence into memory can matter. Avoiding another model replica can matter. Preventing one oversized prompt from disrupting a latency-sensitive batch can matter. Across a large fleet, modest reductions in the resources consumed by each successful model call can compound into meaningful capacity gains. The relationship can be summarized simply: > GPU sharing allocates the supply. State virtualization reduces the demand created by each decision. ## Consider a long-running procurement agent Imagine an AI agent supporting a procurement process that lasts several weeks. During that process, the agent accumulates multiple versions of a contract, vendor proposals, pricing spreadsheets, legal comments, approval messages, meeting notes, policy documents, tool results, and previous recommendations. Its next task may be narrow: > Determine whether the latest proposal exceeds the business unit’s approval threshold and identify the required approver. The model may need the latest proposal, the authoritative approval policy, the correct business-unit identifier, the approved budget, any active exception, and the required output format. It may not need superseded proposals, unrelated contract clauses, entire meeting transcripts, rejected pricing alternatives, summaries of obsolete documents, or every software tool available to the agent. Nothing has to be deleted. The complete workflow history remains available to the system. The next model call simply receives the working state required for the current decision rather than the accumulated weight of the entire process. This is how state virtualization can make the model less expensive to operate while also focusing it on the evidence that matters. ## State selection must be a control plane The difficult part is not removing text. The difficult part is preserving meaning. A production-grade state-selection layer must understand the authority of each record. It must distinguish an official system response from a user assertion, an older model-generated summary, or an unverified retrieval result. It must understand freshness and determine whether a record is current or has been superseded. It must enforce scope so the selected information belongs to the correct customer, account, tenant, transaction, and workflow. It must also preserve dependencies. A later action may require an identifier, artifact, approval, or decision produced many steps earlier. Policy introduces another requirement. Some instructions, approvals, and exceptions must remain on the critical path regardless of their apparent textual relevance. Risk matters as well. The consequences of omitting information vary considerably between a low-stakes summary and a financial approval, legal review, or record-changing tool action. The system must also preserve provenance so it can explain why a record was included or excluded. Most importantly, it must know when not to optimize. When confidence is insufficient, the safer choice is to preserve more context or pass through the broader baseline. The objective is not the smallest possible prompt. It is the smallest **decision-sufficient** state that preserves the required outcome. ## What enterprises should measure Token reduction alone is not enough. An organization can reduce tokens and still increase total cost if users must retry failed answers, tool actions become less reliable, or state selection introduces excessive latency before every model call. The more useful measure is: > Correct, policy-compliant business outcomes per GPU dollar, delivered within the required response time. A serious evaluation should measure outcome quality, infrastructure efficiency, serving capacity, latency, governance, and fallback behavior together. It should determine whether the system preserved the evidence required to answer correctly and complete the intended action. It should examine input processing, KV-cache occupancy, accelerator time, concurrency, throughput, and the number of GPU replicas needed at a target workload. It should also measure the overhead introduced by state selection. A system that saves model time but adds several seconds before each call may not belong inside an interactive agent loop. Governance must be evaluated directly. Authoritative records, policies, identifiers, approvals, evidence, and output requirements must remain intact. Fallback behavior matters just as much. A trustworthy system must recognize when broader context is necessary and decline to optimize aggressively. For the CFO, this is the difference between durable unit-cost leverage and superficial token savings. For the CTO, it offers a path to better infrastructure efficiency without replacing the underlying model or accelerator architecture. For the CIO and risk organization, it creates a more explicit boundary around the evidence used for each AI-assisted decision. ## The future AI stack will contain several virtualizers Cloud computing converged around the virtual machine as a dominant abstraction. AI infrastructure is likely to require several cooperating abstractions. Hardware virtualization will determine which workloads receive which portions of an accelerator. Runtime virtualization will determine which requests execute together and when. Memory virtualization will determine how model and sequence state are allocated, retained, paged, and reused. Model optimization will reduce the computation and memory required to produce an output. Reasoning-state virtualization will determine what information is necessary to produce the correct output in the first place. Each layer addresses a different source of inefficiency. No single layer will create cloud-scale AI economics by itself. Together, they can turn a fixed accelerator fleet into substantially more useful enterprise capacity. ## The next cloud abstraction begins before the model call The first cloud era separated applications from physical servers. The next AI infrastructure era must separate an agent’s complete operational memory from the active state required for its next action. That separation will become more important as agents run longer, call more tools, create more artifacts, inherit more policies, and accumulate more organizational history. The winning architecture will not simply ask increasingly powerful models to read everything faster. It will decide what deserves to be read in the first place. It will preserve the evidence that can change the answer, exclude state that only consumes time, memory, and money, and give the accelerator a smaller and more precise unit of useful work. The next EC2 moment for AI will not begin inside the GPU. It will begin with the decision about what deserves to reach it. --- # Blog: Weekly AI Wrap | July 6 to July 12, 2026: Ransomware, Reckoning, Revenue, Restrictions (published 2026-07-13, by Kiran Kashalkar) ## TL;DR - **Ransomware.** Sysdig documented JADEPUFFER, the first end-to-end autonomous AI ransomware attack: an agent chained a full kill chain through an unpatched Langflow bug and launched 600+ payloads with no human direction after entry. The same week, Anthropic quietly flipped Claude Code to require manual approval for sensitive actions by default. - **Reckoning.** Mark Zuckerberg told Meta staff agentic progress "hasn't really accelerated." New benchmarks measure the gap: agents still need constant human steering, and the average model scores under 15% at composing multi-agent work. The labs have committed ~$8B to deployment, but 71% of $1B+ execs blame their own org readiness, not the technology. - **Revenue.** Anthropic overtook OpenAI on revenue (~$47B vs $25-33B annualized), driven by a coding agent, not a chatbot. SK Hynix's $26.5B IPO, the biggest foreign listing in US history, closed up ~13%, pricing AI capex as durable infrastructure ahead of the fall lab IPOs. - **Restrictions.** Alibaba banned Claude Code after a hidden China-fingerprinting mechanism was found in the binary. Chinese models now serve ~45% of traffic on the largest open model marketplace. Access to any given model is now a moving target set by governments and vendors. ## 🔒 Ransomware: AI ran an attack with no human at the wheel For a year, "autonomous AI attacks" were a warning. This week they were a case file. Sysdig documented an attack it named JADEPUFFER, which it calls the first end-to-end autonomous AI ransomware. An agent exploited an unpatched vulnerability in Langflow (an agent-building tool) to get in, and from there it ran the entire kill chain by itself: reconnaissance, privilege escalation, and the generation and deployment of more than 600 distinct malware payloads. A human was needed only for the initial access. After that, no direction. The timing of the defense was the tell. In the same week, Anthropic quietly changed Claude Code's default to Manual permission mode, so every sensitive action now needs explicit human approval. The vendor shipped the guardrail before most customers knew this class of risk existed. Underneath the headline attack, two quieter findings pointed at the same soft spot. A paper on "Governance Decay" showed that when an agent compacts its own context to save tokens, it can silently delete its own safety policy: violation rates jumped from 0% to as high as 59% once the constraint got summarized away. And a new category formed almost overnight to police this, with Palo Alto Networks absorbing the agent-gateway startup Portkey and Solo.io donating its agentgateway project to a foundation. Governing agent traffic is becoming its own control layer. The plain-English takeaway for a leader: an agent can now execute a serious attack, or quietly drop its own rules, at machine speed. The only workable defense is a durable record of what every agent actually did, plus the ability to require approval and stop it. You cannot review what you did not log. ## 🧊 Reckoning: the labs admitted the plateau The most striking quote of the week came from someone with every reason not to say it. Mark Zuckerberg told Meta staff that agentic AI progress "hasn't really accelerated in the way that we expected," the most senior on-record admission of a plateau, from a company that reorganized and cut staff to chase it. The measurements arrived to back him up. Meta's own SWE-Together benchmark stopped scoring the final artifact and started scoring the interaction cost: how much human steering an agent needs. Even a top model like Opus 4.8 needed more than one correction per task, and capability predicted steering burden at a near-perfect r = -0.92. A separate eval, PerspectiveGap, found the best model passes only 62% at composing multi-agent orchestration, with the average model at 14.9%. Money is meeting the same wall. The labs have now committed roughly $8B to deploying their own models through forward-deployed engineers (Microsoft $2.5B, OpenAI $4B+, Anthropic $1.5B, AWS $1B). Yet in the underlying survey, 71% of executives at $1B+ companies blamed org readiness for stalled AI, and only 11% blamed the technology. The reframe: capability is no longer the bottleneck, and it is no longer the moat. The gap between a demo and a dependable system lives in operations, reliability, and the boring plumbing, exactly where new benchmarks like AgentProp-Bench are now trying to localize where in the pipeline agents actually fail. When everyone can access strong models, the edge moves to who can operate them. ## 💰 Revenue: the money got real and public The AI economy stopped being a private story this week. Anthropic overtook OpenAI on revenue, at roughly $47B annualized versus $25-33B, and the how matters as much as the number: it got there on Claude Code, a coding agent, not a consumer chatbot. Business subscriptions, not viral demos, flipped the lead. To power the next leg, Anthropic signed a $19B data-center lease with TeraWulf for zero-carbon compute, locking in capacity ahead of an expected October S-1. The public markets gave their verdict too. SK Hynix, the memory-chip supplier behind every Nvidia AI accelerator, raised $26.5B in the biggest foreign IPO in US history and closed its debut up about 13%, 7x oversubscribed. Read plainly, public money is pricing AI capital spending as durable infrastructure, not a bubble, right before the Anthropic and OpenAI listings expected in Q4. And capital is moving to the unglamorous inputs. "Training gyms," the simulated environments used to train reliable agents, became a funded category in a single quarter, with Bespoke raising $40M and Deeptune $43M. The scarce input for better agents is turning out to be the environment and the record of real work, not the benchmark. Why a builder should care: every one of these numbers gets marked to market by the fall IPOs. The narratives about inference cost and model economics are about to face an S-1. Build your business on the layer that survives whichever lab has the best quarter, not on this quarter's winning model. ## 🚧 Restrictions: the access war reached your laptop The fight over who may use which model stopped being an export-policy abstraction and showed up in a developer's IDE. Alibaba banned Claude Code after a reverse-engineer found a hidden China-fingerprinting mechanism buried in the binary, a 147-domain detection list active since April. Alibaba moved employees to a different tool. Anthropic described it as a removed anti-distillation measure. Either way, the access war is now running in both directions, down to the app on the laptop. At the same time, the map of who runs what is being redrawn. Chinese models now serve roughly 45% of traffic on OpenRouter, the largest open model marketplace, with Xiaomi's MiMo-V2-Pro the single most-used model on it. Every frontier lab became publicly available at once for the first time since the Fable 5 export ban, as GPT-5.6 went fully public and xAI shipped Grok 4.5. And the regulatory clock is real: the EU AI Act's high-risk obligations become enforceable on August 2, with the compliance boundary extending to every agent in a multi-agent chain and fines up to 3% of global turnover. Ollama's $65M round for local, on-prem inference is the market's hedge: if access can be revoked, own the stack. The lesson for any enterprise: the model you depend on can be banned, deprecated, or regulated out from under you on someone else's timeline. Pinning your business to one model you do not control is a single point of failure. Model-neutral ownership of your execution layer is the hedge. ## The throughline Four very different stories, one arrow. An agent can now attack you on its own (Ransomware). The model's raw capability has stopped being the differentiator (Reckoning). Model economics are about to be marked to market in public (Revenue). And access to any given model can be cut off, priced up, or regulated overnight (Restrictions). In every one of those worlds, the model itself is the volatile, rented part. What is durable is the layer you own: the record of what your agents ran, what each run cost, which model executed it, and what it was allowed to do. That record is your security audit trail (Ransomware), your reliability and operations layer (Reckoning), the asset that outlasts model churn and IPO cycles (Revenue), and your hedge when a provider or a government cuts you off (Restrictions). The model is rented. The record is yours. This week, four separate stories drew the same line. ## Sources and further reading ### Ransomware - **JADEPUFFER: first autonomous AI ransomware, 600+ payloads, human only at initial access via unpatched Langflow CVE** (Sysdig, July 6): [TechCrunch](https://techcrunch.com/2026/07/06/the-first-ai-run-ransomware-attack-still-needed-a-human/), [The Hacker News](https://thehackernews.com/2026/07/ai-agent-exploits-langflow-rce-to.html) - **Claude Code defaults to Manual permission mode** (July): [Releasebot](https://releasebot.io/updates/anthropic) - **"Governance Decay": context compaction silently deletes safety policy, violations 0% to 59% worst case**: [arXiv](https://arxiv.org/abs/2606.22528) - **Agent gateways consolidate; Palo Alto absorbs Portkey, Solo.io donates agentgateway**: [Forbes](https://www.forbes.com/sites/janakirammsv/2026/07/05/agent-gateways-are-becoming-the-control-plane-for-enterprise-ai/) ### Reckoning - **Zuckerberg: agentic AI progress "hasn't really accelerated"**: TechCrunch (name-cited from the daily feed) - **SWE-Together (Meta): steering burden as a model metric, r = -0.92 capability-vs-correction**: [arXiv](https://arxiv.org/abs/2606.29957) - **PerspectiveGap: 62% best / 14.9% average at composing multi-agent orchestration**: [VoltAgent papers list](https://github.com/VoltAgent/awesome-ai-agent-papers) - **AgentProp-Bench: localizing where tool-agent pipelines fail**: [arXiv](https://arxiv.org/pdf/2604.16706); related: [Towards a Science of AI Agent Reliability](https://arxiv.org/abs/2602.16666) - **~$8B committed by the labs to deployment; 71% of $1B+ execs blame org readiness, 11% the technology**: [PYMNTS](https://www.pymnts.com/news/artificial-intelligence/2026/ai-giants-spend-8-billion-dollars-fix-enterprise-adoption/) ### Revenue - **Anthropic overtakes OpenAI on revenue, ~$47B vs $25-33B annualized, driven by Claude Code**: [Fortune](https://fortune.com/2026/07/02/sam-altman-new-world-order-ai-openai-google-anthropic/) - **SK Hynix raises $26.5B, biggest foreign IPO in US history, closes debut up ~13%** (July 10): [TechCrunch](https://techcrunch.com/2026/07/10/sk-hynix-raises-26-5b-in-the-biggest-foreign-ipo-in-us-history-is-urged-to-build-new-us-fabs/) - **Anthropic signs $19B TeraWulf data-center lease ahead of October S-1**: [SiliconANGLE](https://siliconangle.com/2026/07/07/anthropic-terawulf-19b-data-center-lease/) - **"Training gyms" become a funded category: Bespoke $40M, Deeptune $43M/a16z**: [AIwire](https://www.hpcwire.com/aiwire/2026/07/07/bespoke-labs-announces-40m-to-build-the-environments-that-train-reliable-agents/), [Fortune](https://fortune.com/2026/03/19/andreessen-horowitz-ai-startups-deeptune-series-a/) ### Restrictions - **Alibaba bans Claude Code after a hidden China-fingerprinting mechanism found in the binary**: [Tom's Hardware](https://www.tomshardware.com/tech-industry/artificial-intelligence/alibaba-bans-anthropics-claude-code-after-an-alleged-hidden-china-detection-backdoor-is-uncovered-employees-told-to-switch-to-qoder-as-the-rift-between-the-firms-widens), [The Decoder](https://the-decoder.com/claude-codes-complicated-china-problem-involves-bans-on-both-sides-of-the-pacific/) - **Chinese models ~45% of OpenRouter traffic; Xiaomi MiMo-V2-Pro the most-used model**: [Digital Applied](https://www.digitalapplied.com/blog/chinese-ai-models-q2-2026-market-share-report), [OpenRouter](https://openrouter.ai/xiaomi/mimo-v2-pro) - **GPT-5.6 goes fully public; xAI ships Grok 4.5 the same week**: [Engadget](https://www.engadget.com/2210308/openai-rolls-out-gpt5-6-july-9/), [TechCrunch](https://techcrunch.com/2026/07/08/spacexai-releases-grok-4-5-which-elon-describes-as-an-opus-class-model/) - **EU AI Act high-risk obligations enforceable August 2, 2026; fines up to 3% of global turnover**: [Holland & Knight](https://www.hklaw.com/en/insights/publications/2026/04/us-companies-face-eu-ai-acts-possible-august-2026-compliance-deadline) - **Ollama raises $65M Series B for local/on-prem inference**: [AIwire](https://www.hpcwire.com/aiwire/2026/07/09/ollama-raises-65m-series-b-funding-to-grow-its-open-source-ai-platform/) > Some items are name-cited without a URL where the daily feed did not capture a direct link. Figures are as reported that week and are perishable; re-verify before reuse. --- **Disclosure:** I am co-founder of Next Moca, which builds an agent control plane, so I have a stake in the "value moves up to the layer you own" thesis. I argue it here on the week's evidence, not as a pitch. Read the sources and judge the arrow for yourself. --- # Blog: Beyond Words: How Tokens Power the Multimodal AI Economy (published 2026-07-13, by Swanand Rao) A token is not a word. In multimodal artificial intelligence, it may not even be text. Tokens are the units through which AI models represent and process information. They determine how much context a model can consider, how much computation an interaction requires, how quickly a response can be generated, and, increasingly, how organizations are charged for AI services. For the first generation of enterprise generative AI, token management was largely a text problem: prompts, documents, chat histories, and model responses. That model is rapidly changing. Today's AI systems interpret screenshots, analyze diagrams, listen to conversations, review recorded meetings, understand product videos, and reason across combinations of text, images, audio, and video. Every modality must be converted into a representation the model can process. That makes understanding tokens essential, not only for AI engineers, but also for technology leaders making decisions about architecture, economics, security, and scale. ## What Is a Token? At its simplest, a token is a unit of information processed by an AI model. For a language model, text is not typically processed as complete sentences or even as complete words. Before the model can reason about text, a tokenizer divides it into smaller elements. A token may represent: - A complete word - Part of a word - A number - A punctuation mark - A space or formatting element - A fragment of source code - A sequence of characters or bytes Consider a sentence such as: > Artificial intelligence is transforming the enterprise. A tokenizer might divide it conceptually into units resembling: ```text Artificial intelligence is transforming the enterprise . ``` A less common or more complex word might be divided into several smaller pieces. A common word may be represented as a single token. The precise result depends on the tokenizer used by the model. Two models can receive the same sentence and calculate different token counts because they may use different vocabularies, segmentation rules, and training methods. This leads to an important principle: > Token count is a property of both the content and the model processing it. There is no universal token count for a piece of text. ## Why AI Models Use Tokens Instead of Words Words are not ideal computational units. They vary by language, grammatical structure, spelling, and context. New product names, technical terms, abbreviations, identifiers, and code constructs appear constantly. A system based only on complete words would require an enormous and continuously changing vocabulary. Subword tokenization solves this problem. Most modern language models use tokenization approaches derived from methods such as byte-pair encoding, WordPiece, SentencePiece, or unigram language models. While the implementations differ, the underlying objective is similar: build a finite vocabulary of reusable text fragments. Common patterns can be represented efficiently. Unfamiliar terms can still be represented by combining smaller units. For example, a specialized term might be divided conceptually as: ```text multimodal -> multi + modal ``` A newly invented product name might be divided into several character or byte-level fragments. The model does not need to have seen the exact term in its vocabulary to process it. This balance between efficiency and flexibility is one of the reasons tokenization is foundational to modern AI. ## How Text Tokens Are Computed The text-processing pipeline generally follows four stages. ### 1. Normalization The system prepares the text for tokenization. Depending on the model, this may include handling spaces, punctuation, Unicode characters, capitalization, or byte-level representations. ### 2. Segmentation The tokenizer compares the text against its vocabulary and divides it into recognized units. Frequently occurring words or character sequences are more likely to remain intact. Rare or complex expressions are more likely to be broken into smaller pieces. ### 3. Token Identification Each token is mapped to a numerical identifier. Conceptually: ```text "enterprise" -> token ID 4821 " AI" -> token ID 9317 "." -> token ID 13 ``` The actual identifiers are specific to the model and have no universal meaning. ### 4. Embedding The model converts each token identifier into a high-dimensional vector known as an embedding. The model does not reason directly over the word "enterprise" or the number 4821. It reasons over a learned numerical representation that captures relationships among concepts, language patterns, and context. The complete pipeline looks like this: ```text Text | v Tokenizer | v Tokens | v Token IDs | v Embeddings | v Transformer | v Generated output ``` When the model generates a response, the process operates in the opposite direction. It predicts token identifiers one at a time, and the tokenizer converts those identifiers back into readable text. ## A Token Is Also an Economic Unit Tokens serve several roles at once. They are a representational unit inside the model, a constraint on context capacity, a driver of computational workload, and often a unit of billing. A typical AI request may contain: ```text System instructions + User prompt + Conversation history + Retrieved documents + Tool results + Multimodal inputs + Generated response ``` All of this information competes for finite model capacity. For text-based interactions, providers often distinguish between: - **Input tokens:** Information sent to the model - **Output tokens:** Information generated by the model - **Cached tokens:** Previously processed information that can be reused - **Reasoning tokens:** Internal computational steps exposed or metered by some model families The exact terminology and pricing structure vary by provider and model. What remains consistent is the broader relationship: > More information usually requires more representation, more memory, and more computation. This is why token usage affects latency, infrastructure requirements, context-window limits, and operating cost. But the definition becomes more complex when the input is no longer text. ## The Three Meanings of "Token" in Multimodal AI In multimodal systems, the word *token* is often used to describe three related but distinct concepts. ### 1. Tokenizer Tokens These are the familiar text fragments produced by a language tokenizer. ### 2. Model Sequence Tokens These are the internal elements presented to the model. They may represent text fragments, image regions, audio segments, or compressed video features. ### 3. Billable Units These are the units used by a service provider for pricing. A provider may charge by text tokens, image dimensions, processing detail, audio duration, video duration, or a normalized token-equivalent measure. These units should not always be treated as interchangeable. An image may be represented internally as visual tokens while being priced according to its resolution. Audio may be processed as embeddings or codec tokens but billed by the minute. Video may create a combination of image, audio, and text representations while being metered through a separate pricing formula. For enterprise planning, the distinction matters. Internal model architecture and external billing policy are related, but they are not necessarily identical. ## How Images Become Tokens An image contains pixels, not words. A multimodal model must convert those pixels into a structured representation before it can reason about them. A common image-processing pipeline looks like this: ```text Image | v Resize and normalize | v Divide into patches or regions | v Vision encoder | v Visual embeddings | v Projection or compression layer | v Multimodal model ``` ### Image Patches Many vision architectures divide an image into a grid of smaller regions called patches. For example, an image may be separated into square areas. Each patch contains a portion of the visual scene: part of a face, a section of text, an edge, a background texture, or a region of a chart. The system converts every patch into a numerical vector. These vectors are frequently referred to as visual tokens because they play a role analogous to text-token embeddings. The model can then reason across relationships among visual regions. ### Image Resolution Matters A larger image can contain more patches and therefore require more visual representations. In general: ```text More image area -> More visual regions -> More model workload ``` However, implementations differ substantially. Some models resize every image to a standardized resolution. Some use a variable number of patches. Some divide high-resolution images into tiles. Others compress many visual patches into a smaller fixed set of latent representations before passing them to the language model. As a result, doubling an image's resolution does not necessarily double its billable token count. The calculation depends on the model's preprocessing, tiling, and compression strategy. ### Detail Matters as Much as Size A high-resolution photograph and a high-resolution spreadsheet screenshot may have the same dimensions but create different reasoning challenges. The spreadsheet may contain hundreds of small text elements and structural relationships. The photograph may contain broad visual features that can be understood after resizing. This is why multimodal systems may use multiple processing paths: - Optical character recognition for visible text - Object detection for physical entities - Layout analysis for forms and documents - Chart extraction for graphs - Vision embeddings for general scene understanding The image may therefore contribute both visual representations and extracted text tokens. ## Why Documents Are Inherently Multimodal A digital document may appear to be text, but enterprise documents frequently contain multiple forms of information: - Paragraphs - Tables - Charts - Diagrams - Photographs - Signatures - Handwritten annotations - Page layouts - Headers and footers - Spatial relationships Extracting only the text can remove important meaning. A financial table is not merely a collection of numbers. Its meaning depends on row labels, column labels, units, footnotes, and visual hierarchy. A process diagram communicates relationships through position and direction. A signed form may require both text recognition and image analysis. A document-understanding system may therefore combine: ```text Text extraction + OCR + Layout representations + Visual tokens + Metadata ``` All of these representations consume some portion of the system's processing capacity. This is one reason a 50-page scanned document and a 50-page plain-text document can have very different computational profiles. ## How Audio Becomes Tokens Audio introduces another form of continuous information: sound waves unfolding over time. Before a model can interpret speech, music, tone, or environmental sounds, the audio must be converted into a machine-readable representation. There are three common architectural approaches. ### Speech-to-Text Processing The system first transcribes spoken audio into text. ```text Audio | v Speech recognition | v Transcript | v Text tokens | v Language model ``` This approach is effective when the primary objective is understanding spoken content. It also makes token accounting relatively straightforward because the downstream language model receives text. However, transcription can remove information such as emphasis, emotion, timing, background sounds, speaker identity, and nonverbal cues. ### Direct Audio Understanding Some multimodal systems process audio representations directly. The system may divide sound into short time windows, convert those windows into frequency-based features, and encode them as embeddings. Other systems use neural audio codecs that translate sound into discrete audio tokens. Conceptually: ```text Waveform | v Acoustic features or codec | v Audio tokens or embeddings | v Multimodal model ``` This approach can preserve information that a transcript alone may lose, including tone, rhythm, silence, acoustic events, and pronunciation. ### Hybrid Audio Processing Many practical systems combine both approaches. They may produce a transcript while also retaining selected acoustic features, speaker segments, timestamps, or event classifications. The model may receive: ```text Transcript tokens + Speaker metadata + Timing information + Acoustic embeddings ``` Audio economics therefore depend on more than the number of spoken words. Duration, sampling rate, number of channels, speaker separation, and the type of analysis can all affect processing requirements. For this reason, some services meter audio by duration rather than by exposing an exact internal token count. ## How Video Becomes Tokens Video is the most demanding common modality because it combines spatial, temporal, visual, and often auditory information. A video may contain: - Individual images - Motion - Spoken language - Music - Environmental sounds - On-screen text - Scene transitions - Gestures - Demonstrations - Relationships that develop over time Processing every pixel of every frame would be prohibitively expensive for most applications. A 30-frame-per-second video contains 1,800 frames per minute. Many AI systems therefore select, compress, or summarize the visual stream before reasoning over it. A typical pipeline may look like this: ```text Video | v Frame or clip sampling | v Visual encoding | v Temporal compression + Audio processing + OCR and metadata | v Multimodal representations | v Reasoning model ``` ### Frame Sampling The system may select frames at regular intervals, detect scene changes, or identify moments likely to contain important information. A recorded presentation, for example, may not require repeated processing of hundreds of nearly identical frames showing the same slide. ### Clip-Based Encoding Instead of analyzing isolated images, some models process short video clips. This allows the system to recognize motion, actions, transitions, and changes over time. A single frame can show a person holding a product. A short sequence can show how the product is assembled, operated, or repaired. ### Audio Extraction The audio track may be transcribed or encoded directly. The transcript introduces text tokens, while acoustic analysis may create additional audio representations. ### Optical Character Recognition Text displayed in slides, captions, dashboards, signs, or interfaces may be extracted and tokenized separately. ### Temporal Compression Video models frequently compress information across frames. Repeated visual content can be represented more efficiently than treating each frame as an independent image. As a result, video token consumption is not simply: ```text Number of frames x image tokens per frame ``` It depends on sampling strategy, temporal modeling, resolution, duration, audio processing, scene complexity, and provider-specific architecture. ## A Practical View of Multimodal Token Accounting At a conceptual level, a multimodal request can be thought of as: ```text Total model workload ~ Text representations + Image representations + Audio representations + Video representations + Retrieved context + Generated output ``` This is useful as a mental model, but it should not be interpreted as a universal billing formula. Different models may compress modalities differently. A thousand text tokens in one system are not necessarily computationally equivalent to a thousand visual or audio tokens in another. Even within the same provider, different model generations may use different encoders and token-accounting methods. The key takeaway is not that every modality can be reduced to a perfectly comparable unit. It is that every modality must be transformed into a finite representation, and that representation has a cost. ## Why Token Economics Matter to the Enterprise Token management is often treated as an infrastructure concern. In reality, it has direct implications for enterprise strategy. ### Cost Large prompts, high-resolution images, long audio recordings, and extended videos can materially increase inference expense at scale. A single interaction may appear inexpensive. Millions of interactions, each containing unnecessary context, produce a very different economic profile. ### Performance More input generally requires more preprocessing, memory movement, and model computation. That can increase latency and reduce application responsiveness. ### Capacity Every model has a finite context window. Text, images, audio, documents, tool outputs, and generated content may all compete for that capacity. ### Quality More context does not automatically produce a better answer. Irrelevant information can distract the model, create conflicting signals, dilute important evidence, and increase the probability of unsupported conclusions. ### Security and Governance Every additional piece of information admitted into a model interaction expands the data involved in that reasoning process. An employee may be authorized to access a document without that document being appropriate for every AI task. A video may contain confidential information unrelated to the user's question. A conversation history may include sensitive details that should not influence future interactions. The question is therefore not only: > Can the model process this information? It is also: > Should this information participate in this decision? ## From Token Optimization to Information Selection The first phase of enterprise AI optimization focused on reducing token counts through shorter prompts, summarization, caching, and context compression. Those techniques remain valuable. But they operate after information has already entered the processing pipeline. The next phase will focus on admission. Instead of sending an entire meeting recording, a system may identify the relevant decision and supporting exchange. Instead of processing a complete image, it may analyze a specific region. Instead of adding a full document repository to the context, it may retrieve only the authoritative passages required for the task. This changes the optimization objective. The goal is no longer simply to represent the same information with fewer tokens. It is to determine which information deserves representation in the first place. That distinction has significant consequences. Better information selection can simultaneously reduce cost, lower latency, improve accuracy, limit data exposure, and preserve context capacity for the evidence that matters most. ## Four Questions Leaders Should Ask As organizations design multimodal AI systems, four questions should guide architectural decisions. ### What Information Is Being Admitted? Organizations should understand which documents, images, recordings, memories, and tool outputs are included in each model request. ### How Is Each Modality Represented? Text extraction, image tiling, OCR, audio transcription, and video sampling create different tradeoffs in fidelity, latency, and cost. ### How Is Usage Measured? Internal model tokens, provider billing units, and application-level usage metrics may not be identical. Effective financial planning requires visibility into all three. ### What Can Be Excluded? The most efficient representation is often not a better compression of the full input. It is the deliberate removal of information that is irrelevant, redundant, outdated, or inappropriate for the task. ## The Future of Tokens Is Multimodal Tokens began as a practical way to represent language. They are now becoming part of a broader computational vocabulary for representing human information: words, images, sound, motion, documents, interfaces, and events. That evolution changes the meaning of token economics. In a text-only system, token management may be primarily about prompt length. In a multimodal enterprise system, it becomes a question of architecture: - What should the system observe? - At what resolution? - For how long? - Through which representation? - Under which governance policy? - With what level of fidelity? - For which business purpose? The organizations that answer these questions well will not simply reduce their AI bills. They will build systems that are faster, more accurate, more governable, and better aligned with enterprise intent. Because in the multimodal era, the most important token is not the one a model processes efficiently. It is the one the system decides is worth processing at all. --- # Blog: Agent Harness, Agent Operating System, or Enterprise Agent Control Plane? (published 2026-07-08, by Swanand Rao) ## Understanding the Emerging Architecture of Production AI Agents AI agents are moving from experimental demos into production systems. That shift is changing the infrastructure conversation. In the early days of generative AI, most enterprise conversations centered on model choice, prompt quality, retrieval-augmented generation, and proof-of-concept applications. Today, the discussion has expanded. Teams are asking how agents should call tools, access memory, coordinate with other agents, follow policies, use enterprise data, trigger workflows, and operate safely at scale. As the technology matures, a new vocabulary has emerged. Terms such as agent framework, agent runtime, agent harness, agent operating system, agent platform, and agent control plane are now used frequently, and often interchangeably. They should not be. These concepts describe related but distinct layers of the AI agent stack. Confusing them creates architectural ambiguity. A team may think it is buying governance when it is really adopting a runtime. Another may think it is deploying an "agent OS" when it is actually stitching together prompt templates, tool calls, and memory. Another may expect a harness to manage a fleet of agents when it was designed to execute an individual workflow. The distinction matters because production AI is no longer just a model problem. It is a systems problem. Enterprises do not merely need agents that can reason. They need agents that can be registered, deployed, versioned, monitored, evaluated, secured, governed, and retired. They need to know not only what an agent did, but which data it used, which tools it invoked, which model it called, what policies applied, and whether the action was appropriate for the user, workflow, and business context. That requires a layered architecture. This article offers a practical taxonomy for three increasingly important layers: - Agent Harness - Agent Operating System - Enterprise Agent Control Plane Each layer is useful. Each solves a different class of problem. None fully replaces the others. ## The Evolution of Agent Infrastructure The first generation of enterprise generative AI applications was relatively simple. An application sent a prompt to a foundation model and returned a response. ```text Application | v Foundation Model ``` This was enough for chat, summarization, drafting, classification, and basic knowledge retrieval. But as soon as applications needed to perform multi-step work, the architecture changed. Agents needed to call tools, inspect outputs, recover from errors, preserve intermediate state, and decide whether a task was complete. This gave rise to the agent harness. ```text Application | v Agent Harness | v Foundation Model ``` As teams began building many agents, another need emerged. Agents required shared infrastructure: memory, connectors, identity, permissions, scheduling, communication, and lifecycle services. This gave rise to what many now call the agent operating system. ```text Application | v Agent Operating System | v Agent Harness | v Foundation Model ``` And as enterprises began scaling from individual agents to fleets of agents, a third layer became necessary. Organizations needed a way to govern the entire ecosystem: which agents exist, who owns them, what they can access, which models they use, what state participates in reasoning, how quality is evaluated, how risk is monitored, and how changes are controlled. That is the role of the Enterprise Agent Control Plane. ```text Enterprise Agent Control Plane | v Agent Operating System | v Agent Harness | v Foundation Models ``` This evolution mirrors a familiar pattern in enterprise infrastructure. At small scale, execution is the hard problem. At large scale, management, governance, and control become equally important. ## Layer 1: The Agent Harness An agent harness is the execution layer around an AI agent. It is the runtime environment that allows an agent to complete a task by coordinating prompts, model calls, tools, state, memory, and outputs. A harness answers a focused question: > How does this agent execute its task? The harness does not simply send a prompt to a model. It manages the loop around the model. A typical harness is responsible for: | Function | What it does | | --- | --- | | Prompt construction | Assembles instructions, context, memory, tool schemas, and task-specific inputs | | Model invocation | Calls the selected language model with the constructed prompt or message state | | Tool execution | Allows the agent to call APIs, databases, code interpreters, enterprise systems, or custom functions | | Observation handling | Feeds tool results back into the agent's reasoning process | | State tracking | Maintains intermediate task state across steps | | Retry logic | Handles failed model calls, malformed outputs, unavailable tools, or transient errors | | Output validation | Ensures responses conform to expected schemas, formats, or constraints | | Reasoning loop | Decides whether to continue, call another tool, ask for clarification, or finish | | Tracing | Records the sequence of model calls, tool calls, handoffs, and decisions | The canonical harness pattern looks something like this: ```text Receive Task | v Build Prompt / State | v Invoke Model | v Need Tool? / \ Yes No | | v v Run Tool Produce Final Output | v Observe Tool Result | v Continue? | v Repeat ``` This basic loop powers many agentic systems. Different frameworks implement it differently. Some use graphs. Some use event-driven workflows. Some emphasize multi-agent collaboration. Some focus on structured outputs. Some provide managed sessions, handoffs, guardrails, or tracing. Examples include OpenAI Agents SDK, LangGraph, CrewAI, AutoGen, Semantic Kernel, PydanticAI, and LlamaIndex Workflows. Their abstractions differ, but their center of gravity is similar: > Make the agent run reliably. That is the job of the harness. ## Why Harnesses Matter The harness is one of the most important layers in the agent stack because it turns a language model into an operational actor. A model alone can generate text. A harness allows that model to participate in a workflow. Without a harness, every AI application team would need to repeatedly rebuild the same machinery: - how to define tools - how to expose those tools to a model - how to validate tool arguments - how to pass tool results back into reasoning - how to manage intermediate state - how to recover from failed calls - how to structure final outputs - how to trace what happened - how to stop execution safely A good harness abstracts these mechanics so developers can focus on business logic. In that sense, an agent harness plays a role similar to an application framework. A web framework does not define the business model of an application. It provides routing, middleware, authentication patterns, request handling, and runtime conventions that make application development repeatable. Similarly, an agent harness does not define an enterprise AI strategy. It provides the execution mechanics that make agent development practical. But execution is only the first layer. As soon as an organization moves from one agent to many agents, new questions appear. How should agents share memory? How should they access enterprise systems? How should permissions work? How should agents coordinate? How should common services be reused instead of rebuilt? Those questions move us beyond the harness and toward the agent operating system. ## Layer 2: The Agent Operating System The phrase agent operating system has become increasingly popular. It is an imperfect term, but it emerged for a reason. As organizations move beyond individual agents, they need shared services that many agents can depend on. These services often include memory, identity, communication, connectors, permissions, scheduling, deployment infrastructure, and human-in-the-loop workflows. That sounds similar to what a traditional operating system does for applications. A traditional operating system provides common services: | Traditional OS Service | Agent Platform Equivalent | | --- | --- | | Process management | Agent execution and scheduling | | Memory management | Session memory, long-term memory, and workflow state | | File system | Artifact storage and document access | | Device drivers | Connectors to enterprise systems and tools | | Networking | Agent-to-agent and agent-to-service communication | | Permissions | Identity, access controls, and policy checks | | System logs | Runtime traces, telemetry, and audit records | This is why the Agent OS analogy is useful. It communicates that agents should not each carry their own bespoke infrastructure. They should rely on shared platform services. An Agent OS typically answers this question: > What common services do agents need in order to operate across an organization? The answer often includes: | Capability | Why it matters | | --- | --- | | Shared memory | Agents need continuity across users, tasks, and workflows | | Identity | Agents need accountability, ownership, and permissions | | Connectors | Agents need controlled access to business systems | | Communication | Agents may need to collaborate with users, systems, and other agents | | Scheduling | Agents may need to run on triggers, events, or recurring schedules | | Lifecycle support | Agents need to be created, configured, deployed, updated, and retired | | Runtime services | Agents need logs, traces, error handling, and operational visibility | | Human-in-the-loop workflows | Some decisions require review, approval, or escalation | This layer becomes especially important when agents are no longer isolated demos, but persistent participants in business workflows. Without shared services, every agent becomes a snowflake. Each agent has its own memory pattern, connector strategy, access model, logging convention, and deployment process. That may work for prototypes. It does not scale. An Agent OS helps standardize the environment. It gives agents a place to live. ## Where the Agent OS Analogy Works The Agent OS concept is useful because it captures a real architectural shift. As agents become more capable, they need more than execution loops. They need durable services around them. They need identity. They need memory. They need access to tools. They need communication channels. They need a way to interact with enterprise systems. They need a runtime environment that is consistent across teams. This is similar to how applications rely on operating systems instead of implementing low-level services themselves. A well-designed Agent OS reduces duplication and improves composability. Agents can share connectors, use common memory services, operate under consistent identity models, and participate in standardized workflows. For many enterprises, this is a major step forward from scattered pilots. It moves the organization from "teams building agents" to "teams building on a common agent platform." That is a meaningful transition. ## Where the Agent OS Analogy Breaks Down The term "Agent OS" should not be taken literally. A traditional operating system owns the machine. It schedules CPU time, manages physical and virtual memory, handles hardware interrupts, controls devices, manages storage, and mediates low-level network access. Agent platforms generally do not do that. They run on top of cloud infrastructure, Kubernetes, serverless runtimes, databases, vector stores, identity providers, SaaS systems, and foundation models. They orchestrate AI capabilities, but they do not own the underlying hardware or compute substrate. That does not make the Agent OS term useless. It simply means the term is metaphorical. A better interpretation is: > An Agent OS is a shared services layer for agents. It provides the environment agents rely on. It abstracts common capabilities. It improves developer and business-user productivity. It gives agents a consistent place to operate. But it does not automatically solve the broader enterprise governance problem. In fact, the stronger an Agent OS becomes, the more important governance becomes. Because once agents have access to shared memory, persistent state, enterprise connectors, tools, workflows, and user context, the central question changes. It is no longer only: > What services do agents need? It becomes: > Under what conditions should agents be allowed to use those services? That is the bridge from Agent OS to control plane. ## From Shared Services to Governed State The most important capability introduced by an Agent OS is not simply tool access or orchestration. It is a state. Early agent systems treated state mostly as execution memory. The harness needed to remember the user's request, intermediate tool outputs, and the current step in the reasoning loop. Agent operating systems expand that idea. They introduce shared memory, persistent context, user profiles, workflow state, retrieved documents, generated artifacts, and access to enterprise systems. This makes agents far more useful. It also changes the risk model. Before any model invocation, an enterprise agent may have access to: - conversation history - enterprise memory - retrieved documents - workflow state - customer records - previous tool results - generated artifacts - organizational policies - user permissions - approvals - structured databases At first, this looks like a context-window problem. The system has too much information, so it must compress, summarize, cache, or reduce tokens. Those optimizations matter. Prompt compression, context compression, context caching, KV-cache optimization, token reduction, and inference optimization can make agents faster and cheaper. But they do not answer the more fundamental enterprise question. They optimize information after it has already been selected. The harder question comes earlier: > What information should be allowed to participate in this agent's reasoning in the first place? This is not just a performance question. It is a governance question. Not all available states are relevant. Not all relevant states are authorized. Not all authorized states are appropriate. Not all appropriate states are current. Not all current states are trustworthy. An enterprise agent may be technically capable of accessing a customer record, a contract, a support ticket, a pricing exception, a policy document, a prior approval, and a generated analysis. But that does not mean all of that information should be placed into its working state for every task. The system must decide: - Which state is relevant to this request? - Which state is the user authorized to access? - Which state is the agent authorized to use? - Which state is trustworthy enough to influence reasoning? - Which state is stale, sensitive, privileged, or out of scope? - Which state requires masking, approval, or audit? - Which state should be excluded entirely? At a small scale, these decisions can be embedded in application logic. At enterprise scale, they become control-plane responsibilities. This is the key architectural shift. The harness assembles and executes. The Agent OS provides shared services and state. The control plane governs how that state is used. ## Layer 3: The Enterprise Agent Control Plane An Enterprise Agent Control Plane is the management, governance, and orchestration layer for agentic AI across an organization. It answers a broader question: > How should the enterprise manage, govern, secure, observe, evaluate, and evolve its fleet of agents? The control plane is not primarily about one agent completing one task. It is about the operating model for all agents. As agent adoption grows, enterprises begin asking questions such as: - What agents exist across the organization? - Who owns each agent? - Which version is currently deployed? - Which users can invoke it? - Which tools is it allowed to call? - Which data sources may it access? - Which model should it use? - What state is allowed to participate in reasoning? - What policies apply to this workflow? - How do we evaluate quality? - How do we detect unsafe behavior? - How do we monitor cost? - How do we audit decisions later? - How do we suspend, rollback, or retire an agent? These are not harness questions. They are not purely Agent OS questions either. They are governance questions. A control plane typically includes: | Capability | Enterprise Question It Answers | | --- | --- | | Agent registry | What agents exist? | | Ownership metadata | Who owns each agent? | | Deployment management | Which version is running where? | | Version control | What changed between versions? | | Policy enforcement | What is each agent allowed to do? | | Tool governance | Which tools can each agent access? | | Model routing | Which model should be used for this task, risk level, or cost profile? | | Memory governance | Which memory sources may participate in reasoning? | | Evaluation | Is this agent improving or regressing? | | Observability | What are agents doing across the enterprise? | | Audit trails | Can we reconstruct decisions and actions later? | | Risk controls | How are unsafe or anomalous behaviors detected? | | Cost management | What does agent activity cost by team, workflow, model, or customer? | | Lifecycle management | How are agents promoted, deprecated, suspended, or retired? | The control plane does not replace the harness. It does not replace the Agent OS. It governs both. The harness executes the task. The Agent OS provides the shared environment. The control plane determines the rules under which agents, tools, models, memory, and state are allowed to operate. ## Comparing the Layers Although these concepts overlap, their centers of gravity are different. | Capability | Agent Harness | Agent Operating System | Enterprise Agent Control Plane | | --- | --- | --- | --- | | Executes reasoning loop | Core | Often included | Indirect | | Prompt construction | Core | Shared patterns | Policy-driven templates | | Tool invocation | Core | Shared tool access | Governs tool availability | | Session memory | Often included | Common service | Governed by policy | | Long-term memory | Optional | Often included | Enterprise-wide governance | | Multi-agent coordination | Limited to moderate | Common | Governed and observable | | Shared services | Limited | Core | Standardized across enterprise | | Identity and permissions | Basic | Platform-level | Enterprise-wide | | Deployment | Limited | Often included | Core | | Agent registry | Rare | Sometimes | Core | | Version management | Limited | Sometimes | Core | | Policy enforcement | Minimal to moderate | Moderate | Core | | Evaluation | Local or manual | Sometimes included | Enterprise-wide | | Observability | Runtime traces | Platform metrics | Fleet-wide observability | | Audit and compliance | Limited | Moderate | Core | | Model routing | Basic | Sometimes | Policy- and cost-aware | | Cost optimization | Per run | Platform-level | Enterprise-wide | | Fleet management | No | Partial | Core | | Business ownership | No | Sometimes | Core | | Lifecycle governance | No | Partial | Core | The point is not that one layer is better than another. The point is that they solve different problems. A harness is optimized for execution. An Agent OS is optimized for shared agent services. A control plane is optimized for governance, lifecycle management, and enterprise scale. ## A Simple Way to Distinguish Them A practical way to distinguish these layers is to ask what question each one primarily answers. | Layer | Primary Question | | --- | --- | | Agent Harness | How does this agent execute this task? | | Agent Operating System | What shared services do agents need in order to operate? | | Enterprise Agent Control Plane | How does the organization govern and manage all agents? | Another way to say it: ```text Harness: Make the agent run. Agent OS: Give agents a shared environment. Control Plane: Govern the agent ecosystem. ``` For one agent, a harness may be enough. For ten agents, shared services become valuable. For hundreds or thousands of agents, a control plane becomes essential. ## The Emerging Enterprise Agent Stack A mature enterprise agent architecture will likely include all three layers. ```text Enterprise Agent Control Plane | |-- Agent registry |-- Governance and policy |-- Deployment and versioning |-- Evaluation and testing |-- Observability and audit |-- Model routing |-- Cost management |-- Risk controls `-- Enterprise memory governance | v Agent Operating System | |-- Shared memory |-- Identity |-- Connectors |-- Scheduling |-- Communication |-- Runtime services `-- Human-in-the-loop workflows | v Agent Harness | |-- Prompt assembly |-- Reasoning loop |-- Tool execution |-- State tracking |-- Error recovery |-- Output validation `-- Tracing | v Foundation Models ``` This stack is not fixed. Vendors will combine layers. Open-source frameworks will expand upward. Enterprise platforms will extend downward. Cloud providers will integrate across the stack. But the conceptual distinction will remain useful. Execution, shared services, and governance are different responsibilities. ## What This Means for Technology Leaders For technology leaders, the practical implication is straightforward: evaluate agent infrastructure based on the layer of the problem you are trying to solve. When the priority is developer productivity, rapid prototyping, tool calling, structured outputs, and multi-step execution, start with the harness. When the priority is providing common services for multiple agents, including memory, connectors, identity, scheduling, and business-user workflows, evaluate Agent OS-like platforms. When the priority is managing agent sprawl, enforcing policy, governing memory, monitoring risk, controlling cost, auditing activity, and standardizing lifecycle management, look for control plane capabilities. The mistake is expecting one layer to fully solve another layer's problem. A harness will not automatically provide enterprise governance. An Agent OS will not necessarily provide cross-enterprise control. A control plane will not eliminate the need for a robust runtime. The right architecture recognizes the role of each layer and composes them intentionally. ## The Strategic Shift: From Building Agents to Governing Agency The first wave of enterprise AI focused on building agents. The next wave will focus on governing agency. That distinction is subtle but important. An agent is a software construct. Agency is the capacity to act: to retrieve information, reason over state, call tools, change systems, communicate with users, and influence business processes. As agency increases, so does the need for control. Enterprises already understand this pattern. Human employees operate within systems of identity, authorization, training, supervision, audit, escalation, and compliance. Software services operate within systems of access control, deployment, monitoring, observability, and incident response. AI agents will require the same seriousness. They need runtime infrastructure. They need shared services. But above all, they need governance proportional to their autonomy. That is why the distinction between harness, Agent OS, and control plane is more than terminology. It is the blueprint for production AI. ## Final Thought The industry is still early in defining the architecture of agentic systems. Terms will continue to evolve. Product categories will overlap. Platforms will converge. But one thing is already clear: > Enterprise AI cannot scale on execution loops alone. The harness makes agents possible. The Agent OS makes agents reusable. The Enterprise Agent Control Plane makes agents governable. And in the enterprise, governability is what turns powerful technology into trusted infrastructure. --- # Blog: Weekly AI Wrap | June 29 to July 5, 2026: Controls, Costs, Credentials, Corpus (published 2026-07-06, by Kiran Kashalkar) ## TL;DR - **Controls.** Frontier labs and incumbents shipped control-plane features this week, but each governs only its own turf: Anthropic added spend caps and model entitlements to Claude Enterprise, Microsoft stood up a $2.5B "Frontier" unit, Oracle bundled agent oversight into its apps. The cross-vendor record stays unclaimed. - **Costs.** GitHub Copilot's first metered billing cycle produced 10 to 50x bill shocks, ending the flat-rate AI era. Gartner sized $234B of software spend as exposed to "agentic arbitrage." Inference cost never trends to zero, and buyers now want per-agent, per-workflow attribution. - **Credentials.** The BioShocking attack tricked six AI browsers into exfiltrating their users' login credentials through a game-framed prompt injection. Only OpenAI had a working fix. Agent security moved from thesis to public demonstration. - **Corpus.** A 35B open model matched trillion-parameter models on long-horizon agent tasks, trained on 45,000-token trajectories of real agent work, not on more parameters. The record of what agents did is the scarce training asset. ## 🧭 Controls: the labs are selling you a control plane, for their own models only The clearest signal of the week was not a new model. It was governance shipping as a product, from every direction at once. Anthropic added spend caps, model entitlements, effort controls and real-time budget alerts to Claude Enterprise. That is a control plane, sold by the model vendor, for that vendor's models. Microsoft went bigger: it launched a "Frontier" company with $2.5B and 6,000 embedded engineers, explicitly model-agnostic, with customers keeping their IP. Microsoft's Judson Althoff said the quiet part out loud, that binding Copilot to OpenAI-only "was a mistake." That admission arrived two days after Amazon stood up its own $1B AWS agent unit. Oracle, meanwhile, shipped four supply-chain agentic applications with observability, ROI tracking and safety built into the suite, the incumbent's version of the same move: bundle the governance, per product, so you never leave. Add the endpoint tier (Jamf shipped OS-level AI governance for Mac) and the meeting tier (Microsoft Teams added organizer approval for external AI bots), and the pattern is complete. Every layer of the stack now has a governance product. And every one of them governs only its own surface. Here is the gap. The enterprise running Claude, plus Copilot, plus an Oracle suite, plus a few homegrown agents gets four separate dashboards and zero unified record of what ran across all of them. A neutral, cross-vendor account of what every agent did, what it cost, and what it was allowed to do is the one thing the labs structurally cannot build for each other. Gartner supplied the category language earlier in the week: the layer that survives is "institutional memory, customer context, and cross-system orchestration." That layer is not any single vendor's dashboard. Even a startup made the case in dollars. 8090 Labs, with Chamath Palihapitiya as CEO, raised a $135M Series A selling audited AI code generation to regulated industries. The wedge that closes deals in regulated buyers is the audit trail, not the raw generation. ## 💸 Costs: flat-rate AI pricing died in public For two years, AI features were sold like a gym membership: one flat fee, use it as much as you want. That model ended this week, on the record. GitHub Copilot closed its first full month of usage-based billing. Developers posted screenshots of bills up 10 to 50x, with a single long-running agent session costing $30 to $40, roughly what a month of basic chat used to cost. The structural admission underneath the noise: one agentic session can cost the provider as much as a month of a human typing prompts, because inference marginal cost never trends to zero. Every token an agent generates is metered compute. Gartner put a number on the other side of this. It estimated $234B of enterprise software spend, about 20% of the total, is exposed to what it calls "agentic arbitrage." The logic is simple and brutal for SaaS: seat licenses assume humans click the buttons. When an agent does the clicking, the link between number of users and revenue breaks, and the pricing model breaks with it. Palantir's Alex Karp handed CFOs the vocabulary, calling frontier model pricing a "wealth tax on business" while pushing cheaper alternatives. The takeaway for anyone buying AI: the next procurement cycle will demand cost-per-outcome and per-agent, per-workflow attribution, not a flat seat price. If you cannot answer "what did this workflow cost to run," you do not have a cost model, you have a surprise. ## 🔓 Credentials: agent security went from thesis to live demo The security story stopped being hypothetical this week. Researchers at LayerX demonstrated an attack they named BioShocking. They embedded a prompt injection inside content framed as a game, and six AI browsers fell for it: ChatGPT Atlas, Comet, Fellou, Genspark, Sigma, and Anthropic's Claude for Chrome. The agents were talked into exfiltrating their own users' login credentials. The game framing was the trick, it flipped the agent from safety logic into "play along" logic. Only OpenAI had shipped a working fix at the time of disclosure. This lands on top of a grim base rate. AvePoint's 2026 report found 88.4% of organizations had an agent-related security incident in the past year. Straiker, which raised a $64M Series A the same week to fund exactly this problem, reported that 36% of successful attacks against coding agents reached remote code execution. The single idea a non-security executive should take from this: an agent's context window is an unauthenticated input channel. Anything the agent reads, a web page, a document, an email, a game, can carry instructions. Treat everything an agent ingests as potentially adversarial, and scope what each agent can touch below the human who runs it. ## 🧬 Corpus: the scarce asset is the record of what agents did The most important research result of the week was quiet and easy to miss. A 35B-parameter open model, Agents-A1, matched trillion-parameter models on long-horizon agent benchmarks. The trick was not more weights. It was training on 45,000-token trajectories of real agent work, the full play-by-play of an agent planning, calling tools, recovering from errors, and finishing a task. That reframes where capability comes from. For agent tasks, the scarce input is not parameters or even raw text. It is the trajectory log: the record of agents actually doing work. xAI is acting on this directly, folding Cursor coding-session data into Grok's training. Related work the same week (SelfCompact, which cut cost 30 to 70% by letting an agent summarize its own context on a learned rubric) pointed the same way: the gains are in how you engineer the harness and the record, not in the model itself. Here is the uncomfortable part for most teams. Every production agent platform generates this trajectory data every single day, and almost nobody treats it as an asset. It scrolls past in logs and gets discarded. The company that keeps a clean, structured record of what its agents did owns the one input that is getting more valuable, not less. ## The throughline Put the four together and they point the same way. Models are getting cheap, fast, and interchangeable. A 35B open model can match a trillion-parameter one. Pricing is collapsing into metered tokens. New capability comes from data and harness engineering, not from proprietary weights. When the model layer commoditizes, defending it is a price war nobody wins. So the durable value moves up, to the layer you own: the record of what your agents ran, what each run cost, which model executed it, and what it was allowed to do. That record is simultaneously your cost model (Costs), your audit trail (Credentials and Controls), and your training asset (Corpus). The vendors shipping control planes this week each built that record for their own surface. The version that spans every vendor, every model, and every agent in your business is the one none of them can build for you. Value moves up to the layer you own. This week, four separate stories drew the same arrow. ## Sources and further reading ### Controls - **Anthropic ships Claude Enterprise spend caps, model entitlements, analytics API** (July 3): [Releasebot](https://releasebot.io/updates/anthropic), [Build Fast with AI](https://www.buildfastwithai.com/blogs/ai-news-today-july-4-2026) - **Microsoft Frontier Company, $2.5B, 6,000 embedded engineers, model-agnostic** (July 2): [Microsoft blog](https://blogs.microsoft.com/blog/2026/07/02/microsoft-frontier-company-ai-engineering-that-amplifies-and-protects-your-intelligence/), [Reuters](https://www.reuters.com/business/retail-consumer/microsoft-launches-firm-help-companies-adopt-ai-with-25-billion-2026-07-02/) - **Oracle ships four SCM Fusion agentic applications with built-in observability** (June 29): name-cited; no feed URL captured - **Jamf AI Governance for Mac GA, OS-level shadow-AI discovery** (July 1): name-cited; no feed URL captured - **Microsoft Teams organizer-approval controls for external AI bots; AvePoint 2026 report 88.4%** (July 2): [TechStartups roundup](https://techstartups.com/2026/07/02/top-tech-news-today-july-2-2026/) - **8090 Labs $135M Series A, Chamath Palihapitiya CEO, audited AI code for regulated industries** (June 29): [TechCrunch](https://techcrunch.com/2026/06/29/chamath-palihapitiya-raises-135m-series-a-for-his-ai-coding-startup-takes-ceo-role/), [BusinessWire](https://www.businesswire.com/news/home/20260626795833/en/8090-Raises-$135M-Series-A-to-Accelerate-Their-Rollout-of-Software-Factory) - Gartner category language on the surviving layer: see Costs section, Gartner press release below. ### Costs - **GitHub Copilot metered billing, first full cycle, 10 to 50x bill shocks** (June 30): [GitHub blog](https://github.blog/news-insights/company-news/github-copilot-is-moving-to-usage-based-billing/), [Build Fast with AI](https://www.buildfastwithai.com/blogs/ai-news-today-june-30-2026) - **Gartner: $234B of enterprise software spend exposed to agentic arbitrage** (July 1): [Gartner press release](https://www.gartner.com/en/newsroom/press-releases/2026-07-01-gartner-says-us-dollars-234-billion-in-enterprise-application-software-spend-is-at-risk-from-agentic-artificial-intelligence) - **Alex Karp: frontier pricing a "wealth tax on business"** (July 2): CNBC (name-cited); [Build Fast with AI](https://www.buildfastwithai.com/blogs/ai-news-today-july-4-2026) ### Credentials - **BioShocking attack: six AI browsers exfiltrate user credentials via game-framed prompt injection** (July 3): [SecurityWeek](https://www.securityweek.com/bioshocking-attack-tricks-ai-browsers-into-stealing-credentials/), [The Hacker News](https://thehackernews.com/2026/06/new-bioshocking-attack-tricks-ai.html) - **Straiker $64M Series A for agent security; STAR Labs data 36% of coding-agent attacks reach RCE** (June 29): [TechStartups](https://techstartups.com/2026/06/29/straiker-raises-64m-series-a-as-enterprises-rush-to-secure-ai-agents/), [Axios](https://www.axios.com/pro/enterprise-software-deals/2026/06/29/straiker-agent-security) - **AvePoint 2026 report, 88.4% of orgs had an agent-related security incident**: see Teams roundup above. ### Corpus - **Agents-A1: 35B MoE matches ~1T models on long-horizon agent benchmarks via 45K-token trajectories** (June 29): [arXiv](https://arxiv.org/abs/2606.30616), [project page](https://internscience.github.io/Agents-A1/) - **Grok 4.5 folding Cursor session data into training** (reported July 4): [Build Fast with AI](https://www.buildfastwithai.com/blogs/ai-news-today-july-4-2026) - **SelfCompact: rubric-gated self-compaction, +18 pts at 30 to 70% lower cost, no fine-tuning** (JHU/Apple): [arXiv](https://arxiv.org/pdf/2606.23525) > Some items are name-cited without a URL where the daily feed did not capture a direct link. Figures are as reported that week and are perishable; re-verify before reuse. --- **Disclosure:** I am co-founder of Next Moca, which builds an agent control plane, so I have a stake in the "value moves up to the layer you own" thesis. I argue it here on the week's evidence, not as a pitch. Read the sources and judge the arrow for yourself. --- # Blog: Next Moca’s Eval Framework: Proving Trust in Agentic Automation (published 2026-06-10, by Swanand Rao) # Next Moca’s Eval Framework: Proving Trust in Agentic Automation Most AI evals ask a narrow question: > Did the model produce a good answer? That matters, but it is not enough for enterprise automation. In real business workflows, success means the system understood the request, selected the right agent or workflow, used approved capabilities, respected permissions, retrieved the right context, completed the task, produced a useful outcome, and improved only from trusted signals. That is the evaluation problem Next Moca is built around. Next Moca’s eval framework measures the full automation lifecycle, not just the final response. ## Beyond Model Output Quality Traditional evals often focus on prompt-response accuracy. But enterprise automation introduces deeper questions: - Did the platform route the request correctly? - Did it choose an agent, workflow, or tool appropriately? - Were the selected capabilities approved and ready to execute? - Did the system use the right credentials and access controls? - Did memory improve the result or introduce noise? - Did optimization reduce cost without harming quality? - Did the workflow complete the required process? - Was the final output actually useful to the user? A polished answer is not enough. The system must prove that the right work happened in the right way. ## The Five Layers of Evaluation Next Moca evaluates automation across five layers: 1. **Intent Understanding** Did the system understand what the user was trying to accomplish? 2. **Routing Quality** Did it select the right agent, workflow, or capability? 3. **Capability Readiness** Were the tools, credentials, knowledge sources, and policies valid? 4. **Execution Correctness** Did the agent or workflow complete the task successfully? 5. **Learning Safety** Did the system improve from durable, validated outcomes instead of noisy one-off context? This reframes evaluation from: > Was the answer good? to: > Was the automation correct, governed, useful, efficient, and safe to learn from? ## Evaluating Routing The first major eval layer is routing. When a user submits an intent, Next Moca needs to decide whether that work belongs to an agent, a workflow, a tool-backed process, or a fallback path. Routing evals measure: - Top-choice accuracy - Whether the right option appeared in the top candidates - False-positive avoidance - Confidence calibration - Graceful fallback when no good match exists - Correct distinction between single-agent tasks and multi-step workflows - Respect for permissions, lifecycle state, and tenant boundaries Routing is not just search. It is a governed decision. A good system should not always pick something. Sometimes the correct behavior is to decline, ask for clarification, or require setup before execution. ## Evaluating Capability Quality Reusable capabilities are only valuable if they are reliable. Next Moca evaluates whether a capability is ready to be used by agents and workflows. This includes tools, connectors, generated functions, workflow steps, and reusable automation components. Capability evals measure: - Contract validity - Schema correctness - Required input clarity - Predictable output shape - Error handling - Runtime readiness - Dependency safety - Credential requirements - Reusability across agents and workflows A capability should not become trusted simply because it exists. It should pass validation before it becomes part of the governed automation surface. ## Evaluating Memory Memory can make agents more consistent and personalized, but unmanaged memory can also create risk. The memory eval layer asks: - Was the retrieved context relevant? - Was irrelevant or stale memory excluded? - Were tenant, user, agent, and session boundaries respected? - Were durable preferences separated from one-off requests? - Were policy-sensitive guardrails applied correctly? - Did memory improve task success? - Did memory increase prompt noise? The goal is not more memory. The goal is trustworthy memory. A strong memory system should retrieve useful context, reject noisy context, and only promote durable information when the signal is strong enough. ## Evaluating Runtime Optimization Enterprise automation needs to be efficient. More context can improve quality, but it can also increase cost, latency, and distraction. Next Moca evaluates whether runtime optimization improves efficiency without degrading outcomes. Optimization evals measure: - Token reduction - Latency reduction - Cost reduction - Output quality preservation - Task success against baseline - Regression rate - Context compression risk - Retrieval sufficiency The important claim is not simply: > We used fewer tokens. The important claim is: > We used fewer tokens while preserving task success and output quality. ## Evaluating Workflow Execution Workflows require process-level correctness. A workflow may include agents, tools, branches, waits, retries, approvals, checkpoints, and external actions. The final answer may look right while the process was wrong. Workflow evals measure: - Step order correctness - Input/output mapping accuracy - Branching behavior - Retry behavior - Human approval handling - Pause and resume correctness - Long-running state preservation - Tool and agent compatibility - Final output or action quality This matters because enterprise workflows are often compliance-sensitive. The platform must prove not only that work was completed, but that the required process was followed. ## Evaluating Governance Governance is not an afterthought. It is part of the eval framework. Next Moca evaluates whether automation stays inside enterprise boundaries: - Was the user authorized? - Was the selected capability approved? - Were the correct credentials used? - Were secrets protected? - Was tenant isolation preserved? - Were audit records created? - Were policy guardrails enforced? - Did the system avoid unsafe or unauthorized actions? This is where enterprise AI moves beyond demos. Trust requires evidence. ## Evaluating Outcomes The strongest eval signal is whether the work was accepted and useful. Outcome evals measure: - Was the response accepted? - Was the generated artifact used? - Did the downstream action succeed? - Did the workflow complete without repair? - Did the user approve the result? - Did the user provide positive or negative feedback? - Was the capability reused later? Outcome signals can then improve future routing, capability selection, workflow design, and memory behavior. But the learning loop must be careful. Positive feedback can become a durable signal. Negative feedback can become review evidence. Ambiguous behavior should not automatically become permanent instruction. ## The Evaluation Loop Next Moca’s eval framework can be understood as a loop: ```text User intent -> route selection -> capability readiness check -> agent or workflow execution -> governance validation -> outcome measurement -> controlled learning -> better future automation ``` This turns evals from a testing exercise into a platform behavior. Every run can produce evidence. Every outcome can improve the system. Every improvement can be measured against quality, safety, cost, and governance. ## Why This Matters The future of enterprise AI will not be won by systems that only generate impressive responses. It will be won by systems that can repeatedly perform useful work, govern that work, explain that work, measure that work, and improve from that work. That is the purpose of Next Moca’s eval framework. It gives teams confidence that automation is not just intelligent-looking, but measurable, controlled, and improving in the right direction. --- # Blog: Agents, Not Workflows, Should Be the First-Class Citizens of AI Platforms (published 2025-12-11, by Swanand Rao) # Agents, Not Workflows, Should Be the First-Class Citizens of AI Platforms For the last decade, automation has been shaped by a simple mental model: > _“Draw a workflow. Drag some nodes. Connect APIs. Ship.”_ Tools like n8n, Make.com, and many others have built powerful ecosystems around this idea. They treat workflows as the first-class abstraction: everything else, integrations, triggers, actions are just a node in the graph. That made perfect sense in the pre-agent world. But with the rise of LLM-powered agents, this model is starting to show its age. Agents reason. They decide. They coordinate. They use tools. They adapt. Trying to force that into a workflow-first world is like bolting a jet engine onto a bicycle frame. It can move faster, but it was never designed for that. It’s time to flip the architecture! --- Next Moca’s core philosophy is simple but transformative: - **_Agents are the atomic unit of intelligence._** - **_Workflows are orchestration - not the center of the system._** - **_Agents should be the first-class citizens. Workflows should be second-order. Not the other way around._** --- ## 1\. Workflow-First vs Agent-First: Two Different Universes Workflow-first tools like n8n are optimized for this question: > _“Given a trigger, what exact sequence of steps should run?”_ Agent-first platforms are optimized for a different question: > _“Given a goal, which agent should pursue it, with what tools, under what constraints?”_ Those are not the same question. And confusing them leads to brittle architectures. In **workflow-first** (like n8n): - The workflow _is_ the product. - “Intelligence” is scattered across condition nodes, expressions, and error handlers. - LLM calls are just another node, no more important than a Slack notification. In an **agent-first** model: - The _agent_ is the core, enduring object. - It encapsulates **reasoning, tools, policies, memory, and identity**. - Workflows are optional orchestration layers around agents, not the foundation. Once you see this difference, it’s hard to unsee. ## 2\. Where Workflow-First Platforms (Like n8n) Hit Their Ceiling This isn’t about dunking on n8n. n8n is great at what it was designed for: deterministic, node-based automation. But it’s equally important to be honest about where workflow-first platforms strain under agent-native workloads. Workflow platforms assume: - A node has _predictable input_ and _predictable output_ - Failures are handled with retries or branches - State is passed linearly from one block to the next Now introduce an LLM: - Outputs vary by context, prompt phrasing, and model version - Tool choices may need to be dynamic - Reasoning may require multiple iterations, reflection, or delegation In n8n, you end up encoding this as: - Loops - Condition nodes - JSON-transform nodes - Error branches - “LLM Node 1 → Function Node 2 → LLM Node 3 → Merge Node 4” spaghetti You’re essentially trying to _recreate an agent’s inner loop_ via a graph of nodes. It works at small scale. It becomes unmaintainable at serious scale. In an agent-first world, that entire inner loop lives inside the **agent definition** and not splattered across dozens of workflow nodes. ## 3\. Agents Have Identity and Policy, Workflows Don’t A workflow is: - A file / definition - A collection of nodes - A trigger plus a series of actions That’s useful, but it’s not enough for AI-native systems. An agent has: - A **name and role** (e.g., “Customer Billing Investigator Agent”) - **Capabilities and tools** (e.g., “can read Zendesk tickets, query Stripe, access internal RAG index”) - **Policies & constraints** (e.g., “never refund above $500 without human approval”) - **Memory** (past runs, user history, embeddings, local state) - **Governance** (who can invoke it, from where, with what guardrails) - **LLM configuration** (model, temperature, context limits, safety filters) In a workflow-first model, these concepts are scattered: - Some live in nodes - Some live in environment variables - Some live in separate docs or dashboards - Some live in ad-hoc code blocks That fragmentation is fine when all you’re doing is “send lead from Typeform to HubSpot.” It’s not fine when you’re delegating **meaningful decisions** to AI systems. Agent-first platforms instead define agents using **a formal schema**, often via an agent definition standard. ## 4\. Enter ADL: A language to model agents This is where concepts like **ADL (Agent Definition Language) -** an open standard developed incubated and championed at Next Moca, matter. ADL treats an agent like an API: - It has a **contract** (inputs, outputs, tools, constraints) - It has a **definition** (role, description, behavior) - It has **governance** (auth, scopes, permissions) - It is **versioned and testable** **Instead of saying:** > “We have 37 workflows that call OpenAI in different ways.” **You say:** > “We have 5 well-defined agents, each expressed in ADL, and workflows only orchestrate them.” Here: - **ADL** is the _source of truth_ for each agent. - Workflows (whether in n8n, a custom orchestrator, or another system) simply call agents as **stable, governed capabilities**. - You can change, test, or swap an agent implementation, without rewriting every workflow that uses it. Workflow-first tools do not give you a clean, shared, interoperable representation of agents. They give you graphs. ADL gives you **a language and contract**. ## 5\. Honest Comparisons: n8n vs Next Moca’s Agent-First Thinking Let’s be specific in a few areas - respectfully, but directly. ### 5.1. Reuse and Composability - In **n8n**: - Reuse is mainly through sub-workflows or duplicating workflows. - Agent-like logic (e.g., “support triage with LLM + tools”) is often embedded inside a specific flow. - You end up with multiple flows that each have slightly different LLM prompts, parameters, and tool usage. - In an **agent-first + ADL** world: - The Support Triage Agent is **defined once** as a reusable capability. - Multiple workflows (support intake, escalation, QA, analytics) call that same agent. - Updating its behavior is done in one place: its ADL definition and implementation. **Result:** _Agent-first design dramatically reduces drift and duplication._ **Workflow-first platforms tend to accumulate “prompt spaghetti” across flows.** ### 5.2. Governance & Audit - In **workflow-first** platforms: - You can see workflow runs, node executions, logs, and errors. - But you often _can’t easily answer_: - “Which logical ‘agent’ made this decision?” - “Under what policies?” - “Using what tools and memory?” - Those concepts are implicit, not explicit. - In an **agent-first** world: - Every decision is attributed to a specific agent identity. - You can attach compliance policies, RBAC, and audit trails to that agent. - You know exactly what tools it was allowed to use and under what constraints. If you’re just moving rows in Airtable, that might not matter. If you’re approving refunds, changing credit limits, or modifying infrastructure, it absolutely does. ### 5.3. Scaling Multi-Agent Systems Can you approximate multi-agent systems in n8n? Sure. You could: - Create multiple workflows - Have them call each other - Use LLM nodes and HTTP nodes as “agents” - Implement some shared state via a DB or queue But you’re working **against the grain** of the platform. You’re trying to recreate: - Agent registries - Inter-agent messaging - Shared memory - Role boundaries - Hierarchical planners …inside a tool that fundamentally thinks in terms of triggers and node graphs. On the other hand **_Agent-first platforms like Next Moca_**, especially those built around something like ADL, treat: - **Agent definitions** as first-class objects - **Inter-agent communication** as a native pattern - **Multi-agent orchestration** as a core capability, not a hack That matters if you believe the future is not one agent, but **many specialized agents collaborating**. ## 6\. Workflows Actually Get Better When They’re Not the Star Here’s the twist - _Making agents first-class doesn’t diminish workflows. It rescues them._ When workflows aren’t responsible for: - Encoding all decision logic - Managing LLM retries, reflections, and tool selection - Juggling prompts across nodes …they become what they were always meant to be: > **Choreography and coordination**, not intelligence. Workflows become: - Thinner - More declarative - Easier to reason about - Easier to migrate between tools (because they mostly call agents, APIs, and events, not embed bespoke logic) In other words, **workflow-first platforms are fantastic orchestration layers** **_\- once you stop making them carry the full weight of intelligence._** ## 7\. The Opinionated Take: You Can’t Build the Future with Yesterday’s Abstractions If your platform: - Treats LLMs as “just another node” - Has no concept of an agent identity with capabilities and policies - Stores “agent behavior” as scattered prompts and conditionals in graphs - Lacks a structured way to define, version, and govern agents (e.g., via ADL) …then it is fundamentally a **workflow tool with LLM add-ons**, not an **agent platform**. That’s fine if your goal is lightweight automation. It’s not fine if your goal is: - Building **reliable, governable AI agents** - Creating **a system of record** for agent behavior across an organization - Running **multi-agent systems** in production - Meeting **compliance and audit** requirements for AI decisions In that world, agents _must_ be the first-class citizens. Everything else (workflows, triggers, orchestrators, schedulers) is secondary. We’ve already seen this story in software history: - We moved from scripts to services. - From ad-hoc JSON to OpenAPI contracts. - From snowflake deployments to container standards. Agents are the next abstraction. ADL or specs like it are the OpenAPI moment for agents. Workflow-centric thinking will not disappear. It will just take its rightful place as **a powerful, but supporting, layer**. ## 8\. Where to Go from Here If you’re building or adopting automation / AI systems today, ask yourself: - Are we treating workflows as the unit of intelligence? - Do we have **named, well-defined agents** with explicit capabilities and policies? - Is there a **declarative spec** (like [ADL)](https://github.com/nextmoca/adl) for our agents? - Can we swap agent implementations without redoing workflows? - Can we clearly answer: “Which agent did this, and under what rules?” If the answer is “no” across the board, you’re not building an agent platform yet. You’re retrofitting agents onto a workflow tool. The future belongs to platforms that: - Treat **agents as first-class citizens** - Use **standards like** [**ADL**](https://github.com/nextmoca/adl) as the system of record for those agents - Let workflows do what they do best: orchestrate, not thin Workflows were designed for tasks. Agents are designed for intelligence. If intelligence is at the center of your roadmap, your architecture needs to be **agent-first, workflow-second**. --- # Blog: Agent Definition Language (ADL): The Open Source Standard for Defining AI Agents (published 2025-12-04, by Swanand Rao) # Agent Definition Language (ADL): The Open Source Standard for Defining AI Agents ### **GitHub Repository:** [**https://github.com/nextmoca/adl**](https://github.com/nextmoca/adl) ![](/blog/agent-definition-language-adl-the-open-source-standard-for-defining-ai-agents/chatgpt-image-dec-7-2c-2025-at-10_59_56-pm.png) Artificial Intelligence is entering its next major phase: the era of agents. Not just chatbots or one-off prompts, but fully defined agents that can reason, call tools, retrieve knowledge, and orchestrate workflows across complex enterprise environments. From customer support and logistics optimization to fraud detection, underwriting, product operations, HR automation, and engineering enablement, AI agents are beginning to sit at the center of critical business processes. But as adoption accelerates, a structural problem has emerged: there is no shared, vendor-neutral standard for describing what an agent is. Every platform, vendor, and internal team defines “agents” differently. Tool contracts, retrieval (RAG) setups, permissions, and LLM configuration are all fragmented and inconsistent. This fragmentation slows adoption, weakens governance, increases vendor lock-in, and makes it nearly impossible for enterprises to safely scale agent-based systems. **_ADL (Agent Definition Language) was created to solve that problem. And now, ADL is available as an open source standard, designed to be the common language for defining AI agents across vendors, runtimes, and ecosystems._** We at Next Moca believe that open sourcing ADL will accelerate ecosystem adoption, improve interoperability, and provide enterprises with the transparency they require. ### **Why ADL? The Problem It Solves** Before ADL, every serious enterprise AI initiative ran into the same set of issues: **1\. Each team defined agents differently.**    One group used a YAML file, another embedded configuration in code, another used proprietary JSON fields that only worked with a specific framework. There was no single, predictable way to define what an agent could do. **2\. Governance and security were an afterthought.**    Security and risk teams kept asking basic questions: What tools can this agent call? What data can it read? What files can it write? What environment variables does it depend on? Without a standard, these answers required manual code review which is brittle and unsustainable. **3\. RAG and tool configurations were ad hoc.**    Retrieval-augmented generation (RAG) pipelines, code search, document indices, and tool definitions were all wired differently per project. This made agents fragile and nearly impossible to share across teams or business units. **4\. Vendor lock-in was implicit.**    Because every platform defined its own concept of an “agent,” companies effectively locked themselves into whichever vendor they started with. Moving agents between systems meant rewriting them from scratch. **5\. Compliance and audits had no stable artifact.**    Regulators and internal auditors now expect AI systems to be explainable and controllable. Without a declarative artifact that describes what an agent is allowed to do, audits become a high-friction, manual process. **_ADL exists to address all of these problems. It is a single, expressive, machine-validated definition of an AI agent: its purpose, tools, RAG inputs, LLM configuration, dependencies, and security boundaries. With ADL, enterprises gain a standard object they can inspect, version, audit, and reuse._** ### **What ADL Is** ADL (Agent Definition Language) is a vendor-neutral, declarative specification for defining AI agents in a way that is both human-readable and machine-validated. An ADL definition captures, in one place: • Agent identity: name, description, role, owner, version. • LLM configuration: provider, model, temperature, max tokens, and other generation settings. • Tools and capabilities: the functions the agent can call, including parameters, types, descriptions, invocation type, and expected return structure. • Retrieval inputs (RAG): the indices or corpora (documents, code, media) that the agent may query, including paths, types, and metadata. • Permissions and boundaries: file read/write allow lists, network policies, environment variables, and sandbox constraints. • Dependencies: required packages or libraries, with optional version pinning. • Lifecycle and audit metadata: who created the agent, when, and how it has evolved over time. In simple terms: ADL is the blueprint or contract for an AI agent. It defines what the agent is allowed to do, what resources it can access, and how it is configured, independent of any specific runtime, vendor, or framework. **_If OpenAPI is the standard way to describe an HTTP API, and Terraform configurations are the standard way to describe infrastructure, ADL is designed to be the standard way to describe AI agents._** ### **What ADL Is Not** Just as important as defining what ADL is, is clarifying what it is not. ADL focuses on the static, declarative definition of an agent and not its runtime protocol or orchestration logic. • **Not an agent-to-agent communication protocol.**   ADL does not define how agents talk to each other, coordinate, or message one another during execution. That is the domain of A2A (agent-to-agent) protocols or orchestration systems. **• Not a runtime tool protocol like MCP.**   ADL does not define the mechanics of how a model calls a remote tool server, streams tokens, or passes messages back and forth. Protocols such as the Model Context Protocol (MCP) and other tool-invocation standards operate at that layer. **• Not OpenAPI.**   OpenAPI is fundamentally about HTTP APIs: endpoints, request bodies, and responses. Agents are richer entities that reason, retrieve, use tools, and act within permissioned contexts. ADL is not an API spec; it is an agent spec. **• Not a workflow engine.**   ADL is not a replacement for Airflow, Temporal, Dagster, or any other task scheduler or workflow orchestrator. You can absolutely use ADL-defined agents inside workflows, but the workflow logic lives elsewhere. **• Not a prompt engineering format.**   While prompts may be included or referenced inside an agent definition, ADL is not a prompt markup language. It is concerned with the structural contract of the agent, not just its initial instructions. **• Not an RPC or wire protocol.**   ADL says nothing about transport formats such as gRPC, JSON-RPC, or HTTP. It describes capabilities and configuration, not the network protocol used to integrate systems. **_By keeping its scope focused on definition - not transport, not orchestration, not runtime protocols - ADL stays composable and interoperable with other standards and ecosystems._** ### **How ADL Compares to A2A, MCP, OpenAPI, and Other Standards** There are several emerging and established standards in the AI and software ecosystem. ADL is designed to complement them, not compete with them. **ADL vs A2A (Agent-to-Agent specifications):** A2A efforts focus on how agents communicate, delegate tasks, share state, and coordinate work across a network of agents. They define messaging formats, routing semantics, and multi-agent behaviors. ADL fits one layer below that: it defines what each participating agent is, including its tools, RAG bindings, permissions, and configuration. In other words, A2A defines conversations; ADL defines the participants. **ADL vs MCP (Model Context Protocol):** MCP describes how a model (such as an LLM) can access external tools, resources, and context at runtime: how requests and responses are structured, how servers expose tools, and how clients connect to them. ADL does not describe the mechanics of tool invocation; it describes the agent’s allowed tools, their parameters, and their declarative configuration. MCP is a runtime tool protocol; ADL is a static agent definition. **ADL vs OpenAPI:** OpenAPI is a powerful and widely adopted standard for describing RESTful HTTP APIs. It focuses on paths, methods, parameters, and response schemas. ADL operates at a different abstraction level. Agents might call APIs behind the scenes, but ADL is focused on the agent’s behavior, not the underlying HTTP interface. In some cases, ADL can reference OpenAPI-described services as tools, but the two standards are not interchangeable. **ADL vs Workflow Definitions (e.g., Airflow DAGs, Temporal workflows):** Workflow engines define when and how tasks execute over time: scheduling, dependencies, retries, and error handling. ADL can be used inside those workflows to define the agents that perform certain tasks, but it does not replace the workflow logic itself. **ADL vs Prompt Formats and Templates:** Many tools define how prompts are templated, parameterized, or combined. ADL may reference prompts as part of the agent’s configuration, but its main purpose is to define the agent’s capabilities and environment, not to standardize prompt syntax. **_ADL occupies the “definition” layer in the emerging agent stack. It sits naturally alongside A2A protocols, MCP, OpenAPI, and workflow standards, and gives all of them a stable, interpretable agent contract to work with._** ### **ADL Architecture and Schema Overview** At a high level, ADL organizes an agent’s configuration into a small set of well-defined sections. These sections are expressed in JSON (or JSON-compatible) form and validated against a canonical JSON Schema. Core components of ADL include: **1\. Agent Metadata:**    • name, display\_name    • description    • role    • version    • owner and created\_by    • timestamps and lifecycle metadata **2\. LLM Configuration:**    • llm provider (e.g., openai, anthropic, google, local)    • model name or identifier    • temperature    • max\_tokens    • additional provider-specific generation parameters **3\. Tools and Capabilities:**    Each tool has:    • name and human-readable description    • parameter list with names, types, descriptions, and required flags    • invocation type (python\_function, http, mcp, etc.)    • optional return type or schema    • optional categories (e.g., File Operations, RAG, Utilities, Messaging) **4\. Retrieval (RAG) Inputs:**    • id and name of the index or corpus    • rag\_type (doc, code, image, etc.)    • virtual\_index\_path or identifier    • location\_type (local, remote, cloud provider, vector DB)    • metadata for filtering, domain, or governance **5\. Permissions and Boundaries:**    • network: whether network access is allowed and to what domains    • file\_read: whitelisted locations for reading    • file\_write: whitelisted locations for writing    • env\_vars: which environment variables may be exposed    • other sandbox limits and safety flags **6\. Dependencies:**    • pip or package names    • optional pinned versions    • references to code files that implement tools **7\. Governance & Audit:**    • created\_at, updated\_at    • created\_by, updated\_by    • change notes or rationale    • versioning aligned with semantic versioning (SemVer) This structure is intentionally modular. It provides enough detail for engines and runtimes to execute an agent safely and consistently, while remaining flexible enough to support new tools, LLM providers, and RAG strategies over time. ### **Enterprise Governance and Security with ADL** For enterprises, governance is not optional. Agents interact with sensitive data, internal systems, and sometimes regulated workflows. ADL is designed from the ground up to support governance and security requirements. With ADL, governance teams can: • Inspect agent definitions as version-controlled artifacts. • Understand exactly what tools and data an agent can access. • Enforce policies based on permissions, file paths, network domains, or environment variables. • Require review and approval of ADL definitions before deployment. • Audit historical changes using Git or other version control systems. • Validate agents automatically in CI/CD pipelines using ADL schema validators. **_Because ADL is declarative, it enables proactive control rather than reactive monitoring. Instead of discovering capabilities by watching logs after the fact, enterprises can examine the ADL file and know in advance what an agent will be allowed to do._** This is essential not only for internal security but also for external regulatory compliance, including emerging AI governance expectations in various jurisdictions. ### **Open Source, Apache 2.0, and the ADL Ecosystem** To become a true standard, ADL must be bigger than any single vendor, including the one that created it. That is why ADL is open sourced under the Apache License 2.0. **Apache 2.0 was chosen specifically because it:** • Provides explicit patent protection and a clear patent grant from contributors. • Is widely trusted by enterprises and open source foundations. • Encourages commercial and non-commercial adoption alike. • Is the license of choice for many foundational technologies and standards, from Kubernetes and Kafka to OpenTelemetry and Apache Arrow. **By open sourcing ADL, Next Moca invites:** • Vendors to adopt ADL as their agent definition format. • Startups to build tooling, validators, editors, and runtimes around ADL. • Enterprises to standardize their internal agent catalogs on ADL. • Researchers to extend the schema with experimental features. • Foundations and working groups to help steward the long-term evolution of the language. **_The goal is not to create yet another proprietary configuration file. The goal is to define a stable, open, and extensible standard for agent definition that the entire ecosystem can rely on._** ### **Roadmap and Future Directions** ADL v1 focuses on core agent definition: metadata, tools, RAG inputs, LLM configuration, permissions, dependencies, and governance metadata. But this is only the beginning. Planned and potential future directions include: **• Multi-agent specifications:**   Defining not only single agents but ensembles of agents, their roles, and coordination patterns. **• Workflow and state modeling:**   Expressing higher-level orchestration semantics or linking ADL agents directly into workflow definitions. **• Richer type systems:**   Expanding the parameter and return-type definitions with stronger typing, constraints, and validation rules. • **Memory models:**   Defining episodic, long-term, or domain-specific memory schemas that agents can rely on across sessions. • **Domain-specific extensions:**   Healthcare, finance, logistics, legal, and other verticals may benefit from domain-focused additions to ADL that remain backwards compatible with the core standard. These directions will be guided by a combination of real-world usage, community feedback, and formal RFC processes as the ADL community and governance mature. ### **How to Adopt ADL in Your Organization** Enterprises, startups, and individual developers can start using ADL gradually without needing to overhaul their entire stack. Practical steps to adopt ADL include: **1\. Start with a single agent.**    Take an existing agent in your environment and express its configuration the tools, RAG sources, LLM settings, and permissions as an ADL file. **2\. Introduce validation.**    Use an ADL schema validator in your CI pipeline to ensure that any new or changed agent definitions conform to the standard. **3\. Integrate ADL into your platform.**    If you provide an internal agent platform, extend it to read ADL files as first-class inputs, converting them into runtime configurations. **4\. Bring security and governance teams into the loop.**    Use ADL definitions as the basis for risk review, compliance checks, and production approval workflows. **5\. Engage with the community.**    As you encounter gaps or promising extensions, contribute RFCs, examples, or tooling back to the ADL project. ADL is designed to be incrementally adoptable: you can start small, then expand its use as your agent ecosystem grows. ### **Conclusion: A Foundation for the Agent Era** AI agents are poised to become a core abstraction in enterprise software: the programmable, policy-aware, tool-using intelligences that sit between data, systems, and users. For that vision to be safe, sustainable, and interoperable, the world needs a shared, open, and expressive way to define what those agents are. ADL (Agent Definition Language) is that definition layer: a vendor-neutral, open source, Apache-licensed standard for describing agents, their tools, their retrieval inputs, their LLM configurations, and their permission boundaries. By focusing on definition rather than runtime, and by complementing rather than competing with protocols like A2A or MCP, ADL provides a solid foundation for an entire ecosystem of runtimes, tools, platforms, and governance frameworks. Whether you are building an internal agent registry, a multi-agent execution engine, a compliance dashboard, or a next-generation AI product, ADL offers a common language you can rely on. The agent era is here. Now it has a standard. **To adopt, extend, or contribute to ADL, visit the official repository:** **GitHub Repository:** [**https://github.com/nextmoca/adl**](https://github.com/nextmoca/adl) **Welcome to the agent era. Welcome to ADL.** --- # Blog: Breaking the First Prompt Barrier: How Next Moca Is Redefining the AI Experience (published 2025-11-07, by Swanand Rao) # Breaking the First Prompt Barrier: How Next Moca Is Redefining the AI Experience ### **The Hidden Friction in AI: The First Prompt** Every interaction with a large language model (LLM) begins with a moment of hesitation. A blank screen. A blinking cursor. And a simple question that stops even experienced users: “What should I ask?” This moment defines what we call the first prompt problem - the invisible friction that prevents users from unlocking the true potential of AI systems. Through extensive pilot programs and collaborations with design partners, we observed a consistent pattern: even when users understood what the model could do, they struggled to start the interaction. The hesitation was not about capability; it was about initiation. When faced with a tool that can do almost anything, users often freeze, unsure how to begin. That insight, discovered through real customer behavior and feedback, has shaped how Next Moca approaches the user experience of AI. ### **What We Learned From Early Pilots** Across pilots with creative agencies, marketing teams, and enterprise innovation groups, one finding stood out: the challenge wasn’t the AI’s intelligence, but the user’s uncertainty about how to engage with it. During these sessions, participants frequently asked questions such as: What’s the right way to start? Do I need to describe everything in detail? How do I tell it what I actually want? What we discovered was not a lack of interest, but a lack of confidence. Users weren’t intimidated by the technology, they were unsure how to express intent in a way that would yield meaningful results. This learning shifted our design philosophy. Instead of focusing on adding features or complex capabilities, we began focusing on clarity before creativity, building interfaces that help users begin with structure, context, and purpose. ### **How Next Moca Addresses the First Prompt Problem** At Next Moca, we believe that the best AI experiences don’t start with prompts, they start with context. Our goal is to remove the barrier of initiation entirely by enabling AI systems that understand user intent before a single word is typed. We’ve embedded this philosophy across the platform, combining design research, pilot feedback, and enterprise workflow insights. The result is a set of innovations that transform how users interact with AI. **From Blank Prompts to Guided Intents** Instead of presenting users with an empty input box, Next Moca provides guided intents - structured starting points aligned with real business and creative workflows. Through pilot feedback, we developed templates for common goals such as: \- Analyzing customer feedback to identify emerging themes \- Generating a product launch campaign brief \- Building a performance marketing plan with ROI projections Each intent is powered by an underlying **Agent Tile**, a declarative unit that defines the agent’s purpose, required data, and behavioral context. This approach ensures that every interaction begins with focus, not uncertainty. ![](/blog/breaking-the-first-prompt-barrier-how-next-moca-is-redefining-the-ai-experience/screenshot-2025-11-06-at-5.28.29-e2-80-afpm.png) Tiles in Next Moca, each tile is a fully formed AI agent. **From Prompts to Playbooks** Real workflows are not isolated commands; they’re sequences of decisions, outputs, and refinements. Pilot teams made this clear: users wanted continuity and structure, not one-off exchanges. In response, Next Moca introduced multi-agent playbooks: reusable, orchestrated workflows that connect multiple specialized agents. For example, the **Pegasi AI Suite - A collection of agents for marketing workflows built on Next Moca’s Enterprise Agent Planner platform -** connects four complementary agents: 1\. Market Research Agent 2\. Campaign Plan Generation Agent 3\. Campaign Image Generation Agent 4\. Performance Marketing Strategy Agent Each agent seamlessly passes context to the next, ensuring that insights, creative outputs, and strategy align within a single flow. **From Commands to Collaboration** Feedback from early adopters highlighted a deeper truth: users don’t want to issue instructions to a model; they want to collaborate with an intelligent system. Next Moca transforms prompting into dialogue. Each agent operates as a specialized collaborator, understanding its domain, grounding its reasoning in context, and sharing intermediate insights transparently. For example: \- The Market Research Agent grounds insights in uploaded reports. \- The Campaign Plan Agent adapts language and tone to match brand guidelines. \- The Performance Marketing Agent estimates spend allocation and ROI based on historical data. Together, they simulate a coordinated team, not just a reactive chatbot. **From One-Off Prompts to Persistent Memory** One of the most common frustrations voiced during pilot testing was the loss of context between sessions. Users wanted continuity: the ability to return to an earlier idea without re-explaining their objective. Next Moca introduced persistent memory across its agent ecosystem. Each agent remembers previous interactions, preferences, and generated outputs. This means users can resume their work seamlessly, building upon prior iterations without repetition. **From Chatbots to Systems of Record** Enterprise and agency partners also expressed a need for transparency and governance, especially when using AI to generate data-driven insights or marketing recommendations. In response, Next Moca treats every agent interaction as part of a system of record. Each exchange is versioned, auditable, and explainable, ensuring that decisions are traceable back to their sources. This provides both compliance assurance and creative accountability. ### **What Feedback Taught Us** The most valuable insight from our pilots was that AI adoption isn’t limited by capability; it’s limited by comfort. Users want to feel guided, supported, and understood. They want AI systems that meet them halfway, translating goals into action without cognitive friction. By closely observing early user sessions, analyzing feedback, and testing hundreds of real-world use cases, we identified the emotional and cognitive barriers that define the first prompt problem. That understanding now drives our roadmap: from workflow design to user onboarding to intelligent agent orchestration. ### **The Future of LLM UX: From Writing Prompts to Building Relationships** The next generation of AI won’t be defined by larger models but by more intuitive experiences. The future lies in systems that understand human intent, reduce friction, and build trust through consistency and explainability. Next Moca is leading this evolution, turning prompting into partnership, and LLM interaction into intelligent collaboration. We’re designing systems that feel familiar, responsive, and reliable, where the AI already understands what you’re trying to achieve before you begin typing. ### **In Summary** The first prompt represents both a challenge and an opportunity, a moment where hesitation meets potential. By deeply engaging with early users and design partners, we’ve learned that the key to great AI isn’t intelligence alone; it’s clarity, confidence, and continuity. At Next Moca, we are committed to transforming that insight into experience, building intelligent systems that don’t wait for inspiration but initiate it. **_Because intelligence isn’t valuable until it’s usable. And usability begins the moment you stop staring at a blank screen and start creating with confidence_**. --- # Blog: Delivering Real Enterprise Value with Next Moca’s EAP - ADLC in Action (published 2025-10-28, by Kiran Kashalkar) # Delivering Real Enterprise Value with Next Moca’s EAP - ADLC in Action Just a couple weeks ago, I wrote about the evolution from the traditional Software Development Life Cycle (SDLC) to the Agent Development Life Cycle (ADLC): a new paradigm for building, deploying, and continuously improving intelligent agents. If you missed it, you can read my previous post: "[Beyond SDLC: Embracing the Agent Development Life Cycle (ADLC) for Intelligent Systems]()". In that post, I described how ADLC is fundamentally cyclical, adaptive, and layered: designed for systems that learn, adapt, and evolve. Today, I’m excited to share how Next Moca is putting ADLC into practice, delivering features and outcomes that go far beyond what traditional SDLC and other platforms can offer. For the past several weeks, our team has been heads down, working with real customers to solve the challenges that matter most for bringing AI agents into production; not just demos or POCs. Our experience building enterprise-scale platforms taught us what businesses truly need: rapid iteration, robust history, safe experimentation, and the ability to scale from idea to impact. ## Building on the ADLC Vision When we first launched Next Moca, agent iteration was slow and cumbersome. Each change required a lengthy build step, and there was no way to track history or experiment safely. Competing platforms still struggle with these issues; most only support a single agent version, making A/B testing and experimentation impossible. We listened to our customers and built what they needed: - **Instant agent iteration**: Update agents and see results in seconds, not hours. No more waiting for builds or losing momentum. - **Full version history**: Every change is tracked, so you can roll back, compare, and audit with confidence. - **A/B testing and experimentation**: Run multiple agent versions side-by-side to find what works best for your business. - **Effortless data onboarding**: Upload and index massive volumes of documents and code with a streamlined UI. - **Safe experimentation**: Try new ideas without risking production: restore previous versions instantly if needed. These features are the result of deep customer engagement and our commitment to enterprise-grade reliability. ![](/blog/delivering-real-enterprise-value-with-next-moca-adlc-in-action/nextmoca_adlc_collage_1200x627.png) ## The Value Delivered Next Moca is built for every team: operations, marketing, support, product, and more. Our intuitive UI and smart versioning make agent management accessible to all, with: - **Rapid agent updates**: Make changes and see results instantly, keeping your business agile. - **Effortless file uploads**: Onboard large datasets and documents with a drag-and-drop interface and progress indicators. - **A/B testing made easy**: Compare agent versions and strategies to optimize for your goals. - **Audit trails and compliance**: Every change and run is tracked for transparency and learning. - **Safe experimentation**: Restore previous versions with a click, so you can innovate without fear. Security and reliability are built-in, so your team can focus on outcomes, not infrastructure. --- ## ADLC Improvements: Lightning-Fast Agent Versioning Our solution centers on a revolutionary approach to agent iteration. **Build-Free Iteration with Intelligent Versioning**: here's what we built. ### 1\. Zero-Build Agent Iterations **The Magic**: When you update an agent in Next Moca, you get a new version instantly; no rebuilds, no waiting. Your changes are live in seconds, so you can iterate, test, and deploy at the speed of business. **The Impact**: - Agent updates that used to take minutes now complete in seconds - Test your changes instantly without breaking your workflow - Maintain enterprise-grade security and reliability ### 2\. Complete Version History & Time Travel Every change creates a new immutable version. You can: - **Restore any previous version** with a single click in the UI - **Compare outputs and performance** across versions for true A/B testing - **Track every change** for compliance and learning ### 3\. Smart Version Management Our versioning system is designed for business agility: - **Auto-incrementing versions**: Every update creates a new version automatically - **Current version selection**: Choose which version is active for production - **Selective deletion and cleanup**: Remove old experiments, keep what matters ### 4\. Same Security, Zero Compromise Here's what didn't change: **security**. Every agent runs in a secure, isolated environment with robust controls and compliance features. You get both speed and security; no trade-offs. --- ## Real-World Use Cases Unlocked Safe Experimentation Test new ideas and tools without risk. If an experiment doesn't work, simply restore a previous version; no downtime, no lost work. Continuous Improvement Iterate on prompts, strategies, and workflows rapidly. Compare outputs across versions, and pick the best performer for your business needs. Production Rollbacks If a new version introduces issues, restore the last known-good version instantly. Keep your operations running smoothly. Knowledge Transfer Track the evolution of your agents over time. New team members can review version history, and learn from past iterations. --- ## Beyond ADLC: Other Major Improvements While making the ADLC possible was our primary feature, we shipped several other quality-of-life improvements. ![ui_improvements.jpg](/blog/delivering-real-enterprise-value-with-next-moca-adlc-in-action/ui_improvements.jpg) ![index_status.jpg](/blog/delivering-real-enterprise-value-with-next-moca-adlc-in-action/index_status.jpg) ![file_uloader_with_status.jpg](/blog/delivering-real-enterprise-value-with-next-moca-adlc-in-action/file_uloader_with_status.jpg) ### UI/UX Enhancements **1\. Enhanced Agent Dashboard** Version selector dropdown on agent detail pages. Visual diff between versions (coming soon). One-click restore for any version. Build status indicators with real-time updates. **2\. Streaming Output Viewer** Real-time agent execution output via Server-Sent Events (SSE). Token-based authentication for secure streaming. Auto-scroll and syntax highlighting. Historical run outputs preserved per version. ### Document Upload Improvements **File Uploader for RAG Indexing**: Multi-file/folder upload interface; upload and index thousands of files from your browser. Support for PDF, TXT, DOCX, CSV, and more. Progress indicators for large file uploads. Automatic indexing pipeline integration. ### Better Observability **Audit Logs**: Every agent creation, update, build, and run is logged. Queryable by user, action, date range, and status. Automatic S3 archival for compliance (configurable retention). Admin-only access for security. **Agent Run Tracking**: Every execution is tracked. Links runs to specific versions: `(agent_id, version, run_number)`. Stores prompts, outputs, and artifacts. Browse historical runs per version. --- ## Performance Numbers All’s good so far but what if you want to see numbers? Here's what our internal testing shows: | Metric | Before | After | Improvement | | --- | --- | --- | --- | | Agent Update Cycle | 7-10 min | 10-30 sec | 95% faster | | A/B Test Setup | 15+ min | Less than 1 min | 93% faster | | Rollback Time | 10 min | Less than 5 sec | 99% faster | | Build-Free Iterations | 0% | 100% | ∞ improvement | | Version History Depth | 1 (current) | Unlimited | Full audit trail | --- ## What's Next? We're not stopping here. Coming soon: - **Visual Version Diffs**: Side-by-side comparison of agent cards across versions - **Verify and promote-based Development**: Create experimental iterations without affecting production agents. Promote to production when verified - **Collaborative ADLC**: Share agents, clone agents - **Performance Analytics**: Compare latency, token usage, and accuracy across versions --- ## The Bottom Line Agent development should be **intuitive**, **iterative** and **near instantaneous**, not **waiting for builds and deployments**. With Next Moca's new versioning system: - ✅ Iterate **95% faster** without compromising security - ✅ Roll back **instantly** when things go wrong - ✅ Test multiple versions **simultaneously** for A/B testing - ✅ Maintain **complete audit trails** for compliance - ✅ Experiment **fearlessly** without breaking production The ADLC bottleneck is solved. Now it's your turn to go build something amazing. 🚀 **About Next Moca** Next Moca is an enterprise platform for agent creation, iteration, and execution, with integrated RAG (Retrieval-Augmented Generation) capabilities. We enable teams to create, version, and deploy AI agents at scale with enterprise-grade security, observability, and compliance. _Questions? Feedback? Want to see how ADLC can transform your business?_ **Book a meeting with me:** [Schedule a call](https://calendar.google.com/calendar/u/0/appointments/schedules/AcZssZ1S9GYEjFnvDUxm_fA0pErBSAoTA9IGOgrcBUYRKhMjYufjxLHhdhwti_RPC1CPJmbb0NllHJjO) --- # Blog: Beyond SDLC: Embracing the Agent Development Life Cycle (ADLC) for Intelligent Systems (published 2025-10-14, by Kiran Kashalkar) # Beyond SDLC: Embracing the Agent Development Life Cycle (ADLC) for Intelligent Systems For decades, the Software Development Life Cycle (SDLC) has been the bedrock of enterprise software development, providing a structured approach to designing, building, testing, and maintaining applications. This well-established framework has served us well in an era dominated by static, rule-based software systems. However, the landscape of enterprise technology is rapidly evolving. We are now entering a new paradigm where business outcomes are increasingly driven by intelligent agents: systems that can reason, automate complex tasks, and make autonomous decisions. These agents are not static; they learn, adapt, and evolve through continuous interaction and feedback. This fundamental shift renders traditional SDLC frameworks inadequate, as they were not designed for systems characterized by dynamic behavior, continuous learning, and inherent adaptability. The challenges posed by these intelligent systems necessitate an evolved operational model. This model must account for the unique lifecycle of agents, from their initial conceptualization to their continuous evolution in production environments. This is where the Agent Development Life Cycle (ADLC) emerges as the essential framework for the intelligent era. ## What is the Agent Development Life Cycle (ADLC)? The ADLC is a structured, governed, and adaptive process specifically designed for the design, deployment, and continuous evolution of intelligent agents from concept to production. It extends the rigorous discipline of the SDLC to accommodate the unique characteristics of agentic systems, which are inherently dynamic and learning-oriented. Unlike the linear or waterfall approaches often associated with traditional SDLC, the ADLC is fundamentally cyclical, adaptive, and layered. It acknowledges that agents are not merely executed but learn, requiring constant iteration, evaluation, and refinement. This iterative nature is crucial for systems that improve autonomously and through human feedback, making the ADLC a living framework rather than a static blueprint. ### ADLC vs. SDLC: A Paradigm Shift To better understand the significance of ADLC, it's helpful to compare its core tenets with those of the traditional SDLC: | Feature | Traditional SDLC | Agent Development Life Cycle (ADLC) | | --- | --- | --- | | Core Focus | Building static software applications | Developing intelligent, adaptive agents | | Code Nature | Static, defined logic | Dynamic, evolving through context and feedback | | Development Cycle | Often sequential, longer release cycles | Continuous, rapid iteration, and deployment | | Evolution | Manual updates, new versions | Autonomous learning, continuous improvement, and human-in-the-loop refinement | | Governance | Primarily code quality, security, and compliance | Extends to agent behavior, decision-making, ethical considerations, and real-time policy enforcement | | Evaluation | Unit, integration, system testing | Continuous outcome measurement, Just-in-Time (JIT) evaluations, and performance monitoring | This comparison highlights that ADLC is not merely an extension but a fundamental rethinking of development practices to align with the capabilities and demands of intelligent agent systems. ## The Iterative ADLC Flow: A Closer Look The ADLC is characterized by a continuous, iterative flow that ensures agents are constantly refined and optimized. A typical ADLC flow can be broken down into several interconnected stages: 1. Define Intent: This initial stage focuses on clearly articulating the desired outcome or objective the agent should achieve. What problem is it solving? What are its key performance indicators (KPIs)? This stage sets the strategic direction for the agent's development. 2. Assemble Capabilities: Once the intent is defined, the next step involves selecting and integrating the necessary components for the agent. This includes choosing appropriate Large Language Models (LLMs), tools (e.g., APIs, databases, external services), and relevant data sources that the agent will leverage to fulfill its intent. 3. Governance & Schema Setup: A critical aspect of enterprise-grade agent development is establishing robust governance. This stage involves applying organizational rules, setting up audit trails for traceability, defining data schemas for consistent input/output, and ensuring compliance with regulatory requirements. These guardrails are essential for responsible and secure agent deployment. 4. Iterate & Evaluate (JIT Evals): This is the core of the iterative process. Agents are continuously measured against their defined intent and performance metrics. Just-in-Time (JIT) evaluations play a crucial role here, allowing for real-time assessment of agent behavior and outcomes. Feedback from these evaluations is vital for identifying areas for improvement. 5. Deploy, Learn, and Evolve: Agents are deployed into their operational environment, where they begin to learn and improve. This learning can be autonomous, based on new data and interactions, or guided by human feedback. The insights gained in this stage feed back into the evaluation process, closing the loop and driving continuous improvement. The cyclical nature of the ADLC ensures that agents are not static entities but dynamic systems that adapt and grow over time. The feedback loop from 'Iterate & Evaluate' back to 'Define Intent' allows for strategic adjustments, while 'Continuous Improvement' from 'Deploy, Learn, and Evolve' refines the agent's operational effectiveness. Here is a visual representation of the Agent Development Life Cycle: ![](/blog/beyond-sdlc-embracing-the-agent-development-life-cycle-adlc-for-intelligent-systems/adlc.png) ## Why ADLC is Not Just Theory: Emerging in Practice The ADLC is not a theoretical construct; it is a framework that has emerged from the practical realities of developing and managing intelligent agents in enterprise settings. Across various industries (from logistics and marketing to retail and finance), organizations are already experiencing the limitations of traditional development methodologies when confronted with the dynamic nature of agentic systems. We observe a clear progression in how enterprises are building and refining intelligence: - No-Code Agent Creation: The initial phase often involves business users or domain experts defining agent behaviors using natural language or intuitive no-code interfaces. This democratizes agent creation, moving it beyond the exclusive domain of software developers. - Iterative Refinement with Human-in-the-Loop: Early versions of agents are iteratively refined through manual intervention and guided feedback. This human oversight is crucial for course correction and ensuring alignment with business objectives and ethical guidelines. - Autonomous Evolution: As agents mature, they are increasingly allowed to autonomously evolve. This involves improving their reasoning capabilities, optimizing prompts, and refining task sequencing based on real-world interactions and performance data. This layer-by-layer improvement is a hallmark of the ADLC. This evolution mirrors the impact of DevOps on SDLC, transforming how enterprises approach the development and continuous improvement of intelligent systems. The ADLC provides the necessary structure to manage this new reality, ensuring that innovation is coupled with control and accountability. ## The Business Value of ADLC for Enterprises For CIOs, CXOs, and business leaders, the ADLC represents a blueprint for governed agility. It enables organizations to accelerate innovation in intelligent systems while maintaining the critical enterprise-grade control, compliance, and security standards they require. The tangible benefits are multifaceted, encompassing improvements in efficiency, risk management, and strategic flexibility. Firstly, ADLC drives faster time-to-value by streamlining the agent development process and enabling rapid iteration. This significantly reduces the time from concept to operational agent, delivering immediate Return on Investment (ROI) through reusable and continuously evolving agents. Concurrently, it offers unified governance and auditability, establishing a comprehensive system of record for every agent and workflow. This ensures that all agent actions are traceable, auditable, and compliant with internal policies and external regulations, thereby fostering trust and accountability within the organization. Secondly, the iterative nature of ADLC, combined with robust governance, facilitates sustainable innovation with accountability. Agents can continuously improve and get smarter with every run, but this evolution occurs within defined guardrails, ensuring accountability and mitigating risks. This approach also leads to a reduced cost-to-validate, as the ability to iterate, evaluate, and evolve agents without requiring complete rebuilds drastically lowers the expenses associated with validating new agent functionalities and improvements. Finally, a well-implemented ADLC framework promotes vendor neutrality and flexibility. It allows enterprises to choose and integrate various models, tools, and cloud environments, thereby avoiding vendor lock-in and optimizing for performance and cost. Ultimately, ADLC empowers enterprises to scale intelligence with the same discipline, predictability, and reliability that they have historically applied to traditional software development, shifting the focus from merely writing code to cultivating cognition within their operational frameworks. ## Conclusion: From Code to Cognition – The ADLC Era The shift from traditional software development to intelligent agent development marks a profound transformation in how enterprises operate and innovate. Just as the SDLC became the foundational framework for the digital era, the ADLC is poised to become the cornerstone of the intelligent era. This is not merely about replacing developers; it is about redefining the very nature of development when intelligence becomes the fundamental building block. The ADLC provides the necessary discipline and framework for enterprises to harness the power of intelligent agents responsibly, securely, and effectively. Embracing the ADLC means moving beyond SDKs and chat interfaces to a governed ecosystem where intelligent agents are built, iterated, evolved, and audited as mission-critical systems. It signifies a strategic commitment to scaling intelligence with the same rigor and predictability once reserved for static software. The future of enterprise development is intelligent, adaptive, and continuously evolving, and the ADLC is the roadmap to navigate this exciting new frontier. --- # Blog: Governance, Trust, and Reproducibility: Why Agent Workflows Need a System of Record (published 2025-09-16, by Kiran Kashalkar) # Governance, Trust, and Reproducibility: Why Agent Workflows Need a System of Record #### Governance, Trust, and Reproducibility: Why Agent Workflows Need a System of Record In the rapidly evolving landscape of artificial intelligence, enterprises are increasingly experimenting with AI agents to streamline operations, enhance customer experiences, and drive innovation. However, as organizations dive deeper into AI integration, they often encounter a common challenge: **agent chaos**. This chaos stems from the lack of a cohesive system to manage, govern, and reproduce agent workflows across various teams and tools. At Next Moca, we recognized this challenge early on and set out to build a solution that addresses these critical needs. Enter the **Enterprise Agent Planner (EAP)** - a platform designed to bring order to the chaos by prioritizing governance, trust, and reproducibility. #### The Imperative of Governance In any enterprise setting, trust is the cornerstone of adoption. Without it, even the most promising AI initiatives can falter. Governance is not just a buzzword; it’s a necessity. Enterprises require robust audit trails, policy enforcement mechanisms, and the ability to verify that agents perform as intended. Without these elements, AI agents remain experimental projects, unable to gain the confidence of compliance teams and CXOs. Our approach at Next Moca was to embed governance into the very fabric of the EAP from the outset. By incorporating comprehensive audit trails for every workflow run, we laid the foundation for compliance and trust across departments. This ensures that every action taken by an agent is recorded, verifiable, and aligned with organizational policies. As a result, enterprises can confidently deploy AI agents, knowing they have a system in place to monitor and manage their activities. #### Reproducibility and Transferability: Beyond Demos One of the significant hurdles in AI adoption is the inability to reproduce and transfer agent workflows across different teams and contexts. Imagine a marketing team developing a campaign agent that proves successful. Ideally, the operations team should be able to leverage this agent without starting from scratch. Similarly, an HR partner’s resume screener should remain effective over time, even as underlying language models evolve. The EAP addresses this challenge through its core **agent schema**, which ensures that agents are reproducible, transferable, and trackable. This schema acts as the DNA of each agent, enabling them to function consistently regardless of changes in the underlying technology. By providing a true **system of record for agents**, the EAP empowers enterprises to scale their AI initiatives seamlessly, transforming isolated successes into organization-wide capabilities. #### Navigating Multi-Tool and Multi-LLM Environments In today’s diverse AI ecosystem, tool and vendor sprawl is a common source of frustration. Different teams may prefer different language models or integration tools, leading to silos, incompatibility, and wasted effort. - One team might rely on OpenAI, another on Anthropic, while a third experiments with Hugging Face models. - Some might integrate with Zapier, others with n8n. The result is a fragmented landscape that hinders collaboration and efficiency. The EAP tackles this issue head-on with its **multi-tool and multi-LLM support**. Agents within the EAP can seamlessly interact with a variety of tools and models, ensuring consistent execution regardless of the underlying technology. This approach not only provides **portability and vendor neutrality** but also safeguards enterprises against vendor lock-in. By enabling teams to work with their preferred tools while maintaining a unified system, the EAP fosters collaboration and innovation across the organization. #### Looking Ahead: Just-in-Time Evaluations As we continue to enhance the EAP, one of the exciting features on our roadmap is **Just-in-Time evaluation (JIT evals)**. This capability will allow enterprises to evaluate agents continuously as they run, enforcing policies in real-time. When combined with our existing schema and audit trails, JIT evals will ensure that every agent operates in a governed, measurable manner. This real-time oversight will further enhance trust and accountability, enabling enterprises to deploy AI agents with even greater confidence. #### Building with Design Partners: A Collaborative Approach Our journey in developing the EAP has been deeply collaborative, driven by the needs and insights of our design partners across logistics, marketing, and retail sectors. These partners have been instrumental in shaping the platform, ensuring that it addresses real-world challenges and delivers tangible business outcomes. By consolidating dozens of isolated integrations into a central platform, our partners have not only achieved cleaner architecture but also gained a competitive advantage in their respective industries. #### Product-Led Growth: Grounded in Customer Need At Next Moca, we are committed to **product-led growth**, where every feature of the EAP is a direct response to customer needs. Governance, audit trails, and multi-tool support are not mere “nice-to-haves”; they are essential components that remove barriers to adoption. By prioritizing these elements, we are laying the groundwork for scaling AI agents from experimental demos to production-ready workflows. #### Conclusion: Escaping Agent Chaos In conclusion, the **Enterprise Agent Planner** is more than just a tool; it is a strategic enabler for enterprises seeking to harness the full potential of AI agents. By addressing the critical challenges of governance, trust, and reproducibility, the EAP transforms agent chaos into a structured, scalable **system of record**. As organizations continue to navigate the complexities of AI integration, the EAP stands as a beacon of order, empowering enterprises to innovate with confidence and achieve meaningful business outcomes. --- # Blog: Enterprise Agent Planner - The Missing System of Record for AI Agents (published 2025-09-04, by Kiran Kashalkar) # Enterprise Agent Planner - The Missing System of Record for AI Agents Every major enterprise function has its system of record. ERP for resources. CRM for customers. HRIS for employees. ServiceNow for IT workflows. These systems didn’t emerge overnight. They became essential because without them, enterprises had duplication, fragmentation, and chaos. Finance ran on inconsistent spreadsheets. Customer data was scattered across teams. IT relied on ad hoc ticketing. Systems of record brought order, governance, and scale. Now, as enterprises experiment with AI agents, we’re watching history repeat itself. ![Next Moca’s EAP provides a System of Record for Enterprises to manage agent chaos](/blog/enterprise-agent-planner-system-of-record-ai-agents/eap_sor_2.png) Next Moca’s EAP provides a System of Record for Enterprises to manage agent chaos ### The Current State: AI Agent Chaos Right now, AI agents live in silos: - A marketing team builds a campaign bot. - HR experiments with resume screening. - Ops prototypes process automation. Each is built in isolation, often with different tools or frameworks. They’re fragile, duplicative, and almost impossible to govern. One department doesn’t know what another is running. Security teams scramble to audit. Compliance can’t enforce policies. The result: **agent chaos.** We saw this same movie before SaaS platforms matured. Without a system of record, progress stalls at pilots and proofs of concept. ### The False Tradeoff: Innovation vs. Control Some leaders believe you need to choose between moving fast and staying in control. In reality, the opposite is true. Without governance, reuse, and consistency, speed collapses. Every team reinvents the wheel. Compliance bottlenecks slow projects to a crawl. The truth: **control enables speed.** Guardrails allow more teams to innovate with confidence. ### Why a System of Record Is Needed Just as ERP standardized financial processes and ServiceNow centralized IT workflows, AI agents need their own system of record. The **Enterprise Agent Planner** fills this gap by providing: - **A Catalog** of reusable agents, tools, and knowledge, so teams don’t rebuild from scratch. - **Governance and Compliance** built in, so policies are enforced and risk is reduced. - **Orchestration**: connecting agents into broader workflows, rather than isolated experiments. - **Declarative Spec**: ensuring agents are predictable, auditable, and shareable across the enterprise. This transforms agents from scattered prototypes into an enterprise-wide capability. ### A Look Ahead: From Pilots to Scale History shows every platform shift reaches this tipping point. Before CRM, customer data was chaos. Before ERP, finance was chaos. Before ServiceNow, IT workflows were chaos. AI agents are at the same moment. The companies that adopt a system of record early will move faster, scale further, and pull ahead. Those that don’t will remain stuck in endless pilots. At Next Moca, we call this the **Enterprise Agent Planner**: the missing layer that makes AI agents production-ready. The pattern is clear: demos → adoption → **system of record.** And with AI agents, that time is now. 📅 Want to see it in action? [Book a walkthrough](https://calendar.google.com/calendar/u/0/appointments/schedules/AcZssZ0RVn7in-ELkAXKreh-JxYpPcBxW8uEYzb_b3__LkXcXQrSlDBb97n6kB09i5QHlIFI6j6U7nwu) 🌐 Learn more: [https://www.nextmoca.com](https://www.nextmoca.com?utm_source=chatgpt.com) --- # Blog: Scaling AI Agents Across Teams Without Rebuilding From Scratch (published 2025-08-26, by Kiran Kashalkar) # Scaling AI Agents Across Teams Without Rebuilding From Scratch _How shared, reusable AI agents unlock productivity and consistency across departments_ ![next moca agent catalog](/blog/scaling-ai-agents-across-teams-without-rebuilding-from-scratch/static_blog_3_1.png) Departments sharing agents with the Next Moca Agent Catalog AI agents are moving fast inside enterprises. But there’s one big risk: every team wants their own, and without a system of record, you end up with **duplication, inconsistency, and wasted effort**. #### The Problem: Islands of Innovation We’ve seen it firsthand: - Marketing builds a campaign agent. - Ops builds a scheduling agent. - Product builds a PRD agent. Each team starts from scratch, unaware of the others. Tools are duplicated, knowledge is siloed, and maintenance becomes a nightmare. #### Why This Happens Most frameworks today are designed for **prototyping, not scaling**. They don’t provide: - A central catalog for reuse - A way to compose agents into bigger workflows - Guardrails for governance across departments So innovation spreads, but value fragments. #### The Next Moca Enterprise Agent Planner Approach At Next Moca, we designed the Enterprise Agent Planner around reusability and scale: - **Built-In Catalog**: agents, tools, and knowledge are captured once and reused everywhere. - **Composable Workflows**: teams can chain existing agents together instead of rebuilding them. - **Governance Layer**: ensures consistency, access control, and compliance across departments. This means that when one team builds an agent, another can leverage it instantly. #### Example Use Cases - A **resume screening agent** built by HR can be reused by Ops for contractor vetting. - A **PRD generation agent** created by Product can be adapted by Marketing for campaign briefs. - A **customer support agent** can be repurposed by Sales for lead qualification. Instead of siloed agents, you get a **network of reusable building blocks**. #### Why It Matters **Reusability is the difference** between isolated pilots and enterprise-wide adoption. Without it, you get “agent chaos.” With it, you build compound value: every new agent makes the next one faster and cheaper. **That’s how businesses move from experimentation to transformation.** 📅 Want to see it in action? [Book a walkthrough](https://calendar.google.com/calendar/u/0/appointments/schedules/AcZssZ0RVn7in-ELkAXKreh-JxYpPcBxW8uEYzb_b3__LkXcXQrSlDBb97n6kB09i5QHlIFI6j6U7nwu) 🌐 Learn more: [https://www.nextmoca.com](https://www.nextmoca.com/) --- # Blog: The Dawn of AI Agencies: Transforming Business Workflows with Next Moca (published 2025-08-19, by Swanand Rao) # The Dawn of AI Agencies: Transforming Business Workflows with Next Moca In the ever-evolving landscape of business technology, a new era is upon us: one that promises to redefine how organizations operate and innovate. Welcome to the dawn of AI agencies, where the fusion of artificial intelligence and business workflows is not just a possibility but an imminent reality. At the forefront of this transformation is Next Moca, a pioneering platform that simplifies the creation of AI agents, enabling businesses to rapidly adopt AI-driven productivity. As a thought leader in the realm of AI agents, we invite you to look around the corner with us and explore the transformative potential of AI agencies in reshaping business workflows. ![](/blog/the-dawn-of-ai-agencies-transforming-business-workflows-with-next-moca/dall-c2-b7e-2025-08-18-22.26.48---a-modern-2c-realistic-office-where-human-employees-are-collaborating-with-ai-agents-represented-as-digital-human-avatars-on-screens.-the-office-is-brigh.webp) ### The Rise of AI Agencies The concept of AI agencies is rooted in the idea of deploying intelligent agents that can autonomously perform tasks, make decisions, and optimize processes. These agents are not just tools; they are digital colleagues capable of learning, adapting, and evolving alongside human teams. The rise of AI agencies marks a significant shift from traditional automation to a more dynamic, intelligent, and collaborative approach to business operations. ### Next Moca: Simplifying AI Agent Creation At the heart of this transformation is Next Moca, a platform designed to democratize the creation and deployment of AI agents. Next Moca empowers businesses to build custom AI agents tailored to their specific needs without requiring extensive technical expertise. This accessibility is crucial in enabling organizations of all sizes to harness the power of AI and integrate it seamlessly into their workflows. Next Moca's intuitive interface and robust capabilities allow businesses to: - **Design Custom Agents**: With a user-friendly drag-and-drop interface, businesses can design AI agents that align with their unique operational requirements. Whether it's automating customer service, streamlining supply chain management, or enhancing data analysis, Next Moca provides the tools to create agents that deliver tangible results. - **Deploy Rapidly**: Time is of the essence in today's fast-paced business environment. Next Moca enables rapid deployment of AI agents, allowing businesses to quickly adapt to changing market conditions and seize new opportunities. - **Optimize Continuously**: AI agents built on Next Moca are not static; they continuously learn and improve over time. This adaptability ensures that businesses remain competitive and agile in an ever-changing landscape. ### Transforming Business Workflows The integration of AI agencies into business workflows heralds a new era of efficiency and innovation. By automating routine tasks, AI agents free up human talent to focus on strategic initiatives and creative problem-solving. This shift not only enhances productivity but also fosters a culture of innovation and continuous improvement. Consider the potential impact across various industries: - **Retail**: AI agents can revolutionize inventory management, optimize pricing strategies, and enhance customer experiences through personalized recommendations. - **Healthcare**: From streamlining administrative tasks to assisting in diagnostics, AI agents can improve patient outcomes and reduce operational costs. - **Finance**: AI-driven analytics can provide real-time insights, detect fraudulent activities, and automate compliance processes, ensuring a more secure and efficient financial ecosystem. ### Looking Ahead: The Agentic Landscape As we stand on the brink of this new era, it's essential to consider the broader implications of AI agencies. The agentic landscape is one where human and machine collaboration is the norm, where AI agents are trusted partners in driving business success. This future is not without its challenges, including ethical considerations and the need for robust governance frameworks. However, the potential benefits far outweigh the risks. In conclusion, the dawn of AI agencies represents a transformative shift in how businesses operate and innovate. With platforms like Next Moca leading the charge, the creation and deployment of AI agents have never been more accessible. As we look around the corner, we see a future where AI-driven productivity is not just an aspiration but a reality: one that promises to redefine the very fabric of business workflows. Embrace the dawn of AI agencies, and together, let's shape a future where intelligent agents are at the heart of every successful organization. --- # Next Moca Terms of Service **Last updated: October 7, 2026** These Terms of Service ("Terms") are a binding agreement between Next Moca Global, Inc., a Delaware corporation ("Next Moca," "we," "us"), and the individual or entity accessing our website or services ("you"). By accessing nextmoca.com, requesting research access, or using the Needlepath API or any related service (together, the "Services"), you agree to these Terms. Certain Services (including API accounts and keys) may additionally require you to accept these Terms affirmatively, and that acceptance governs your use of those Services. The Services are intended for business use by adults; by using them you represent that you are of legal age and, where acting for an organization, authorized to bind it. If you use the Services on behalf of an organization, you represent that you have authority to bind that organization, and "you" refers to it. ## 1. The Services Next Moca provides Needlepath, a context-selection service: given records and a request, it returns content drawn from those records (whole records or excerpts of them, possibly reformatted for delivery) selected against a token budget. Needlepath does not generate content of its own or add substantive text that you did not submit. Where the service determines it cannot improve on the full input, it may return the input unreduced with a recorded reason ("stand-down"). Next Moca also provides the **Agent Control Plane**, an enterprise platform for building, orchestrating, and governing AI agents, typically deployed in the customer's own cloud environment under a separate written agreement (an "Order Form" or master agreement); where such an agreement exists, it governs that deployment and prevails over these Terms for it, and these Terms govern your use of our website, documentation, and evaluation materials. The Services also include our website, documentation, benchmark materials, and any dashboards, SDKs, or tools we make available. Some Services are offered in an early-access or pilot form. Early-access features are provided as-is, may change or be withdrawn without notice, and may be subject to additional terms we provide with them. ## 2. Accounts and API Keys You must provide accurate registration information and keep it current. You are responsible for all activity under your account and API keys. Keys are secrets: do not publish them, embed them in client-side code, or share them outside your organization. Notify us at legal@nextmoca.com promptly if you believe a key is compromised; we may rotate or revoke keys to protect the Services. We may set limits on the Services (including request rates, token throughput, daily volumes, and key counts per tier) as published in our documentation. Published limits are operational targets, not guarantees, and may change with notice as described in Section 12 (which applies to material changes to published operational limits as well as to these Terms). ## 3. Acceptable Use You will not, and will not permit others to: (a) use the Services in violation of applicable law; (b) attempt to probe, breach, or circumvent security or authentication measures, or exceed authorized access; (c) interfere with or disrupt the Services or other customers' use of them; (d) resell or offer the Services to third parties as a standalone service without our written agreement; (e) use the Services to develop a competing context-selection service, or attempt to extract, distill, or reverse-engineer the selection models or policies underlying the Services; (f) submit content you do not have the right to submit; or (g) misrepresent output of the Services, including presenting our benchmark results in a misleading way. You represent that you, your organization, and the persons using your keys are not located in, or ordinarily resident in, any country or region subject to comprehensive U.S. sanctions or embargoes, and are not on any U.S. government restricted-party list (including OFAC's SDN List). You will not access the Services from such a country or region, will not export or re-export the Services in violation of U.S. export-control laws, and will not use the Services for any end use prohibited by them. We may screen for and suspend access we reasonably believe violates this paragraph. We may suspend or throttle access immediately where reasonably necessary to protect the Services or other customers, and will notify you when we do. ## 4. Your Content "Customer Content" means the records and queries you submit to the selection API. It does not include account or registration information, website form submissions, or usage metadata (including identifiers you supply with requests), which are handled as described in the [Privacy Policy](/privacy). You retain all rights in Customer Content. You grant us a limited license to process Customer Content solely to (i) provide the Services to you and maintain their security and integrity and (ii), only at the written request of your authorized representative, store and review Customer Content for no more than 30 days, or until your earlier written deletion request, to evaluate selection quality with you. **We do not use Customer Content to train models.** The request-serving path is designed to be stateless: by default, the records and queries you submit to the selection API are processed in memory to compute the response and are not written to persistent storage. The only exception is an opt-in capture: at the written request of your authorized representative, we store the requests and responses for the specified key in private, encrypted storage for no more than 30 days solely to review selection quality with you, then delete them, or delete them earlier at your written request. They are used only for that review. Operational logs record usage metadata: request identifiers (including identifiers you supply), token counts, timing, and outcome codes, but not the records or queries themselves. Because identifiers you supply are retained as metadata, do not place personal data, secrets, or record content in them. Details are in our [Privacy Policy](/privacy). You are responsible for Customer Content, including having any consents and rights needed to submit it, and for your use of the output. The Services select from what you provide; they do not verify the accuracy of your records. ## 5. Fees, Credits, and Payment Paid tiers of the API operate on prepaid credits unless we agree otherwise in writing. Prices are published in our documentation or agreed in an order form. Usage is metered per submitted input token as described in the documentation, which also explains how to recompute your own bill. Requests on which the Services stand down (returning your input unreduced with a recorded reason) currently incur no charge; if that ever changes, we will announce the change prospectively under Section 12 before it takes effect. Credits are non-transferable and, except where required by law or expressly stated, non-refundable. Promotional and trial credits may expire and may be subject to additional limits. If your balance is exhausted, we may decline requests until credit is added. We may correct metering or billing errors in either direction and will notify you of material corrections. Fees are exclusive of taxes; you are responsible for applicable taxes other than taxes on our income. ## 6. Intellectual Property We and our licensors own the Services, including all software, models, selection policies, documentation, and benchmark harnesses, and all related intellectual property. These Terms grant you no rights in them except the limited right to use the Services as described here. Open-source components we publish are governed by their own licenses. If you give us feedback, we may use it without restriction or obligation. ## 7. Confidentiality If we exchange non-public information that a reasonable person would understand to be confidential (including pricing offered to you, unpublished features, and security details), the receiving party will protect it with reasonable care, use it only in connection with the Services, and not disclose it to third parties except to those who need it and are bound by comparable obligations, or where disclosure is required by law (with prior notice to the discloser where lawful). Confidential information does not include information that is or becomes public through no fault of the recipient, was known to the recipient without restriction before disclosure, is received from a third party without breach of an obligation, or is independently developed. On written request, the recipient will return or destroy confidential information, except copies retained under standard backup or legal-hold practices, which remain protected. ## 8. Disclaimers THE SERVICES ARE PROVIDED "AS IS" AND "AS AVAILABLE." TO THE MAXIMUM EXTENT PERMITTED BY LAW, WE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE, AND NON-INFRINGEMENT. WE DO NOT WARRANT THAT THE SERVICES WILL BE UNINTERRUPTED, ERROR-FREE, OR THAT SELECTION OUTPUT WILL BE SUITABLE FOR ANY PARTICULAR USE. NO SERVICE-LEVEL AGREEMENT APPLIES UNLESS WE HAVE AGREED TO ONE IN WRITING. PUBLISHED BENCHMARK RESULTS DESCRIBE SPECIFIC MEASURED CONFIGURATIONS AND ARE NOT A PROMISE OF EQUIVALENT RESULTS ON YOUR WORKLOAD. ## 9. Limitation of Liability TO THE MAXIMUM EXTENT PERMITTED BY LAW: (a) NEITHER PARTY WILL BE LIABLE FOR INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, OR PUNITIVE DAMAGES, OR FOR LOST PROFITS, REVENUE, OR DATA, EVEN IF ADVISED OF THE POSSIBILITY; AND (b) OUR TOTAL LIABILITY ARISING OUT OF OR RELATING TO THE SERVICES WILL NOT EXCEED THE GREATER OF THE AMOUNTS YOU PAID US FOR THE SERVICES IN THE TWELVE (12) MONTHS BEFORE THE EVENT GIVING RISE TO LIABILITY OR ONE HUNDRED U.S. DOLLARS (US $100). THESE LIMITS DO NOT APPLY TO YOUR PAYMENT OBLIGATIONS, EITHER PARTY'S BREACH OF SECTION 7, YOUR BREACH OF SECTION 3, OR LIABILITY THAT CANNOT BE LIMITED BY LAW. ## 10. Indemnification You will defend and indemnify Next Moca against third-party claims arising from Customer Content, your use of the Services in violation of these Terms, or your violation of law, and will pay resulting damages, settlements, and reasonable costs, provided we notify you promptly and allow you to control the defense with our reasonable cooperation. You may not settle any claim in a way that imposes obligations on us, requires an admission by us, or does not fully release us, without our prior written consent. ## 11. Term, Suspension, and Termination These Terms apply while you use the Services. You may stop using the Services at any time; either party may terminate on notice. We may suspend or terminate access for material breach, non-payment, legal risk, or extended inactivity, with notice where practicable. On termination, your right to use the Services ends and unused promotional credits lapse. If we terminate other than for your breach, we will refund your unused purchased (non-promotional) credit balance; otherwise purchased balances are handled as described in the documentation or your order form. Sections 4 (last paragraph), 5–10, and 12–14 survive termination. ## 12. Changes We may update the Services and these Terms. For material changes to these Terms we will give notice (for example by posting on our website or emailing account holders) at least 14 days before they take effect, except where changes are required by law or address urgent security matters. Continued use after the effective date constitutes acceptance. The API is versioned as described in our documentation; published API versions are served until formally deprecated with notice. ## 13. Governing Law; Arbitration; Class Waiver These Terms are governed by the laws of the State of Delaware, without regard to conflict-of-laws rules. **Arbitration.** Any dispute arising out of or relating to these Terms or the Services that cannot be resolved informally will be finally settled by binding arbitration administered by the American Arbitration Association ("AAA") under its Commercial Arbitration Rules (or, if you are an individual using the Services for personal rather than business purposes, its Consumer Arbitration Rules, including their fee schedules and venue protections), by a single arbitrator, in English. The Federal Arbitration Act governs this agreement to arbitrate. Business arbitrations are seated in Wilmington, Delaware; hearings may be conducted remotely by videoconference on either party's request, and consumer arbitrations will be held at a location convenient to the consumer as the AAA rules provide. Judgment on the award may be entered in any court of competent jurisdiction. Either party may instead bring an individual claim in small-claims court, and either party may seek injunctive relief in court for infringement or misuse of intellectual property or confidential information. **Class waiver.** Disputes will be resolved only on an individual basis; neither party may participate in a class, consolidated, or representative action. If this waiver is found unenforceable as to a particular claim, that claim (and only that claim) proceeds in court as described below. **Opt-out.** You may opt out of this arbitration agreement by emailing legal@nextmoca.com within 30 days of first accepting these Terms, stating your name, organization (if any), and the email address associated with your account or request. An opt-out is effective when sent; we will acknowledge it. Changes we make to this arbitration provision apply prospectively only, and each material change re-opens a 30-day opt-out window for that change. **Courts.** For anyone who opts out, and for disputes not subject to arbitration, the state and federal courts located in Delaware have exclusive jurisdiction, and both parties consent to their jurisdiction and venue and waive trial by jury to the extent permitted by law. ## 14. General These Terms, together with the Privacy Policy and any order form, are the entire agreement regarding the Services and supersede prior discussions. If any provision is unenforceable, the rest remain in effect. Our failure to enforce a provision is not a waiver. You may not assign these Terms without our consent, except to a successor in a merger or sale of substantially all assets; we may assign them to an affiliate or successor. Neither party is liable for delay or failure caused by events beyond its reasonable control. Notices to us go to legal@nextmoca.com; notices to you go to your account email or are posted on our website. **Contact:** Next Moca Global, Inc. · legal@nextmoca.com --- # Next Moca Privacy Policy **Last updated: October 7, 2026** This Privacy Policy explains how Next Moca Global, Inc. ("Next Moca," "we," "us") collects, uses, and shares information when you visit nextmoca.com, request research access, or use the Needlepath API, the Agent Control Plane, and related services (the "Services"). Questions or requests: **privacy@nextmoca.com**. ## 1. What we collect **Information you give us.** - *Website forms:* if you request research access or contact us, we collect what you submit: typically name, work email, company, and your message. - *Accounts:* registration details such as name, work email, organization, and role. - *Billing:* payments are processed by Stripe. We receive transaction records (amount, time, status, last card digits) but **never store full card numbers**; those go directly to Stripe. **Information collected automatically.** - *API usage metadata:* for each API request we record operational metadata: request identifiers, API key identifier, the name and version of the Needlepath SDK or plugin command that sent the request (matched against a fixed list of our own client names; we do not store your full User-Agent), token counts, timing, selected-record counts, and outcome codes (including stand-down reasons). This metadata powers metering, billing, rate limiting, abuse prevention, and the usage reports we show you. - *Website data:* standard server logs (IP address, browser type, pages viewed) and the analytics described in Section 6: our website uses PostHog (product analytics) and HubSpot (forms and visitor tracking), which collect usage data such as pages viewed, referrer, device information, and a visitor identifier cookie. **API Customer Content: processed in memory, not persisted by default.** The records and queries you submit to the selection API ("Customer Content"; this term does not include account information, website form submissions, or usage metadata) are by default processed in memory to compute the response and are **not written to persistent storage, by design**. Our logging records usage metadata: request identifiers (including any identifier you supply with a request, so do not place personal data or secrets in identifiers), the client name described above, token counts, timing, and outcome codes, but not the records or queries themselves. **The only exception is an opt-in capture:** at the written request of a customer's authorized representative, we store the requests and responses for the specified key in private, encrypted storage for no more than 30 days solely to review selection quality with that customer. We then delete the captured content, and we will delete it earlier at the customer's written request. Capture remains off for all other keys. **We do not use Customer Content to train models.** One optional feature does send Customer Content to a third party, and it is the only one. In the signed-in console, the Answer Lab runs a comparison for you: the records you supplied and your question are sent to OpenAI, which writes the two answers shown side by side. It runs on our OpenAI account rather than yours, only when you press the button, and is capped at five comparisons and five judge runs per organization per day. OpenAI does not use API content to train its models, and may retain it for up to 30 days for abuse monitoring, or longer where the law requires. Nothing you send to the selection API at /v1/context/select is handled this way. **Agent Control Plane deployments.** The Agent Control Plane typically runs in the customer's own cloud environment: the customer's business data, workflows, and agent state stay in the customer's infrastructure, and we do not receive them. Information we do receive in connection with such deployments (account, contact, licensing, and support information, and any telemetry the customer's agreement provides for) is handled under this policy and the customer's agreement, whichever is more protective. ## 2. How we use information We use information to: provide, secure, meter, and bill for the Services; respond to your requests; send service and account communications; send research or product updates you asked for (opt out anytime); improve our website; monitor for abuse and enforce our [Terms of Service](/terms); and comply with law. We do **not** sell personal information, and we do not share it for cross-context behavioral advertising. ## 3. How we share information We share information only with: (a) **service providers** that process it for us under contract: our cloud infrastructure provider (Amazon Web Services, United States), our payment processor (Stripe), our identity provider (WorkOS), our website/CRM forms and visitor-tracking provider (HubSpot), our product-analytics provider (PostHog), and OpenAI, which processes Customer Content only for the Answer Lab feature described in Section 1; (b) **professional advisers** (lawyers, accountants) under confidentiality; (c) **authorities** where required by law, and we will notify you where lawful and practicable; and (d) a **successor** in a merger, acquisition, or asset sale, under this policy's protections. We do not share Customer Content submitted to the selection API with any third party except the infrastructure on which the Services run. The one exception anywhere in the Services is the Answer Lab described in Section 1, where content you submit is sent to OpenAI at your action. ## 4. Retention We keep website inquiries and research-access records while relevant to our relationship. API usage metadata is retained for billing, audit, and security purposes and then deleted or aggregated. Customer Content on the selection path is not retained after the response is returned, except for a key whose customer's authorized representative asked in writing for the engine-review capture described in Section 1: that key's requests and responses are kept for no more than 30 days and then deleted, or deleted earlier at the customer's written request. Content you submit to the Answer Lab is likewise not retained by us; OpenAI holds it under its API terms, which provide for up to 30 days of abuse-monitoring retention and longer only where the law requires. Account and billing records are kept as required for tax and accounting. You can ask us to delete information as described in Section 5. ## 5. Your rights Where the GDPR applies, our legal bases are: performance of a contract (providing the Services you request), legitimate interests (securing, metering, and improving the Services and our website), consent (where we ask for it, such as marketing emails), and legal obligation (tax and accounting records). Depending on where you live (including under GDPR and the CCPA/CPRA), you may have rights to access, correct, delete, or export your personal information, to object to or restrict processing, and to withdraw consent. To exercise them, email **privacy@nextmoca.com**; we will verify the request and respond within the time required by law. We do not discriminate against you for exercising your rights. If you are in the EEA or UK, you may also lodge a complaint with your supervisory authority. Where we process personal information on behalf of an API customer as their processor, we will refer your request to that customer and assist them in honoring it. API customers who intend to submit personal data subject to the GDPR or UK GDPR must have a data processing agreement with us first: contact legal@nextmoca.com; until one is executed, do not submit such data. ## 6. Cookies and analytics Our website uses: (a) cookies needed to operate the site and its forms; (b) **HubSpot** cookies (such as `hubspotutk`) that identify visitors and connect form submissions to a visitor record; and (c) **PostHog** product analytics, which uses cookies or similar storage to measure how the site is used (pages viewed, referrer, approximate location from IP, device type). We use this data to understand interest in our research and product; we do not use it for third-party advertising. Your browser's settings let you block or delete cookies; the site remains usable without analytics cookies. We do not currently respond to browser Do Not Track signals. These providers may collect information about your activity on this site over time and, in HubSpot's case, may associate that activity across different websites that use its services; PostHog, as we configure it, collects activity on this site only. See their own privacy documentation for details. ## 7. Security We use technical and organizational measures appropriate to the risk, including encryption in transit, least-privilege access controls on production systems, secret scanning for leaked API keys, and audit logging of administrative actions. No system is perfectly secure; if we learn of a breach affecting your personal information, we will notify you and regulators as required by law. ## 8. International transfers We are a U.S. company and process information in the United States. Where we transfer personal information from the EEA, UK, or Switzerland, we rely on appropriate safeguards such as standard contractual clauses. ## 9. Children The Services are for business use and not directed to anyone under 16. We do not knowingly collect personal information from children; if you believe a child has provided it, contact privacy@nextmoca.com and we will delete it. ## 10. Changes We will post updates to this policy here and revise the date above. For material changes we will give prominent notice (for example on the website or by email to account holders) before they take effect. **Contact:** Next Moca Global, Inc. · privacy@nextmoca.com · legal@nextmoca.com