AI News Archive: July 31, 2026 — Part 4
Sourced from 500+ daily AI sources, scored by relevance.
- The Next AI Boom Is in Health Care and Robotics, Says Lux Capital's Shakir
Recent disclosures from Anthropic and OpenAI have shifted the AI conversation from model capabilities to real-world deployment and security. Lux Capital Partner Deena Shakir says the next wave of AI innovation will be built on trust, partnerships and vertical applications like health care and robotics, not just more powerful foundation models. She joins Ed Ludlow on "Bloomberg Tech." (Source: Bloomberg)
Score: 32🌐 MovesJul 31, 2026https://www.bloomberg.com/news/videos/2026-07-31/-ai-is-now-an-operating-system-says-lux-capital-video - Structured AI data pipelines score 10.9 points below free-form code — DataFlow-Harness closes the gap
If you ask an AI coding agent to write a standalone Python script to parse a single JSON file, it will likely give you a perfect answer in seconds. But the same agent often breaks if you ask it to build a systematic data processing pipeline, like ingesting thousands of messy documents, chunking text, scoring quality, and filtering noise for a Retrieval-Augmented Generation (RAG) system that fits your specific enterprise stack. While large language models (LLMs) excel at one-off code generation, their outputs for complex data-processing tasks are typically free-form, disposable scripts. These scripts are detached from the governable workflow abstractions that MLOps teams rely on for production, making them difficult to audit or edit visually. To address this, researchers at Peking University, Zhongguancun Academy, and Shanghai’s Institute for Advanced Algorithms Research introduced DataFlow-Harness , an open-source framework that guides an LLM agent to build structured, visual data-processing workflows step-by-step, rather than writing raw code from scratch. The framework makes AI-generated pipelines easier to manage and integrate into existing architectures because the generated artifacts are persistent and easily editable. The researchers report that the platform achieves a 93.3% observed end-to-end pass rate on a 12-task data-engineering benchmark. Compared to standard Claude Code, it reduces API costs by up to 72.5% and response latency by 49.9%, while achieving nearly the same success rate as an AI given the entire codebase to write standard scripts. For enterprise teams, this means getting the speed of AI automation without accumulating unmanageable technical debt, ensuring that pipelines remain secure, auditable, and ready for production. The "NL2Pipeline gap" Data-centric AI requires workflows for tasks like synthetic data generation, retrieval augmentation, and model training. While LLMs can translate natural language into executable implementations to perform these tasks, high task accuracy is insufficient for production deployment. "The first wall is usually not writing Python," Runming He, first author of the DataFlow-Harness paper, told VentureBeat. "Modern coding agents can often produce a plausible script quickly. The harder problem is grounding that script in a live production platform: using operators that are actually installed, matching the real dataset schema, referring to registered datasets and model services, preserving dependencies between stages, and leaving behind an artifact that another engineer can understand and revise." General-purpose AI agents frequently hallucinate dependencies, relying on unavailable operators or outdated platform assumptions. Instead of leaving behind an artifact that another engineer can understand and revise, they generate disposable code that is difficult to audit through workflow managing tools. The researchers define this challenge as the "NL2Pipeline gap": the disconnect between a user expressing workflow requirements in natural language and the production environment requiring structured and persistent pipeline assets. The researchers demonstrated this gap in their experiments. For example, when Claude Code was allowed to write standard, free-form scripts using codebase context, it hit a 94.2% success rate. However, when restricted to only using the platform's specific building blocks to create a native workflow graph, its success rate dropped to 83.3%. This gap is the paper's central finding: native, governable pipelines are meaningfully harder for the agent to produce than throwaway code. “Closing this gap requires more than improving code-generation accuracy: construction must remain grounded in platform semantics and produce artifacts that integrate with the host platform,” the researchers write. How the four components work together "DataFlow-Harness changes the agent’s action space," He said. "Instead of asking the agent to emit arbitrary code, it retrieves the live operator registry and current pipeline state through MCP and applies typed, incremental changes to a persistent DAG." To achieve this, the platform organizes workflow synthesis around four components: the Data Pipeline Backend, the interaction layer (DataFlow-WebUI), the MCP Tools Layer, and the AI guidance layer (DataFlow-Skills). The Data Pipeline Backend acts as the authoritative source of truth across conversational, visual, and programmatic interfaces. It represents the pipeline as a directed acyclic graph (DAG), a structured workflow map containing data sources, configured pre-built processing modules (which the researchers refer to as "operators"), and execution dependencies. Instead of generating free-form code, agents interact with this backend through “typed mutations,” like adding an operator or connecting edges. DataFlow-Skills are markdown files that inject domain-specific knowledge into the model's context window, guiding it on operator-selection patterns, schema inference, and assembly procedures. Rather than letting the AI guess how to assemble components, skills provide the AI with compatibility rules, teaching it how to correctly match different data formats and handle complex data structures without breaking the pipeline. The MCP Tools Layer gives the AI access to the operator registry and current state of the data workflow. The AI proposes structured changes through the tools layer. The system validates the changes to ensure the workflow runs in a valid sequence and that every connected module speaks the same data language. DataFlow-WebUI provides two interfaces that allow humans and AI to build the workflow together. Developers can describe workflow requirements in natural language through a conversational interface. They can also access the workflow as a graphical map in a visual DAG editor. Here, they can directly inspect the changes proposed by the AI and make modifications. “The current implementation performs static checks against platform metadata before accepting pipeline changes,” He said. “These include checks for registered datasets, operators and model-serving references, field flow, and some invalid parameter usage, as well as structural validity. The result is visible in a graphical editor and can be revised either manually or by the agent in later turns.” The results: 93.3% pass rate, 72.5% lower cost The researchers tested DataFlow-Harness on a benchmark of 12 tasks across six industrial data-processing scenarios, such as QA generation, review governance, and schema normalization. They used Claude Opus 4.7 as the backbone model in their experiments. They compared DataFlow-Harness against three baselines: Vanilla CC: An unconstrained coding baseline using standard Claude Code. Context-Aware CC: An agent that has access to the DataFlow codebase in its context window. MCP-only: An agent that has access to the DataFlow MCP tools and is instructed to generate platform-native DAGs (without access to DataFlow-Skills). DataFlow-Harness achieved a 93.3% end-to-end pass rate, improving by 10.0 percentage points over MCP-only and beating Vanilla CC (91.7%), while being within 0.9 percentage points of Context-Aware CC (94.2%). Importantly, it reduced API costs to $0.261 per task, a 72.5% drop compared to Vanilla CC and 42.8% compared to Context-Aware CC. In generating workflows, it was 49.9% faster than Vanilla CC and 17.6% faster than Context-Aware CC. DataFlow-Harness proved particularly effective on complex tasks that depend on implicit domain knowledge, like QA generation. The baseline MCP-only approach frequently generated structurally valid DAGs but struggled to infer task-specific procedures from operator descriptions alone. To show how this works in the real world, the researchers detailed a textbook-to-VQA extraction task. This job required the AI to stitch together capabilities such as PDF parsing, layout recovery, OCR, figure extraction, multimodal understanding, and long-range question-answer matching. DataFlow-Harness achieved 97.2% precision and an 87.3% coverage rate, easily beating the baselines. By having the AI snap together existing platform assets rather than coding complex tasks from scratch, it recovered more valid QA pairs from the document. Their experiments also showed that DataFlow-Harness is highly effective at creating data generation pipelines. For example, in a synthetic instruction-data generation task, the agent built a multi-stage pipeline that generated candidate instruction–response pairs, critiqued and rewrote them, scored them with an LLM-based judge, and filtered low-quality outputs before training. "Such workflows are costly to build and fragile to maintain as collections of ad hoc scripts," He said. "The harness does not make them automatically safe, but it turns them into explicit, editable stages that engineers can inspect, test, and govern using normal production controls." Similarly, when tasked with building a math data cleaning-and-synthesis pipeline, the data produced by the DataFlow-Harness pipeline trained a better-performing model with higher average accuracy on AIME24 and AIME25 benchmarks than the data produced by the vanilla Claude Code pipeline. Tech stack fit and implementation tradeoffs For engineering teams evaluating DataFlow-Harness, it is important to understand how it fits into existing infrastructure. Released under the Apache 2.0 license, the current implementation requires a bit of engineering to fit into popular tech stacks. "The current implementation is native to the DataFlow platform; it is not a turnkey Airflow, Prefect, or Spark plug-in," He said. To use those systems as an execution backbone, teams must build an adapter to connect their organization’s registry, metadata, and execution interfaces to the agent's control layer. Furthermore, organizations must invest in the boundaries they want the AI to respect. This requires maintaining an operator registry, defining schemas, and encoding recurring domain procedures as Skills. Because of this overhead, He recommends against using the framework for small, one-off transformations where a simple script suffices, or in legacy environments that cannot expose reliable metadata. Finally, while the platform prevents illogical connections by validating structural properties, it is an engineering control layer, not a compliance substitute. "The harness should still be treated as an engineering control layer, not as a substitute for compliance policy, validated detection models, access controls, audit logging, or human approval," He said. The platform is open-source, and developers can access the source code and codebase documentation directly via the project's GitHub repository . As protocols like MCP become standardized, the boundary between human engineers and AI agents will shift. "The goal is not autonomous data engineering without oversight," He said. "It is a better division of labor: agents perform repetitive construction inside explicit boundaries, while engineers remain responsible for the semantics, policies, and consequential decisions that require domain accountability."
- No AI bubble, better rules: Why India escaped the Korea shock
SEBI’s measures to safeguard market integrity also help market stay relatively calm
- How is your enterprise tracking AI agent telemetry? Groundcover thinks it should never leave your cloud
The AI agent observability space is taking off — but how can enterprises be sure what observability products and solutions they need? Observability startup groudcover (lower case "g" intentional) announced this week that it raised $100 million in a round led by One Peak, bringing its total funding to $160 million. The company says it has more than 250 paying customers, tripled annual recurring revenue over the past year and is increasingly replacing established observability platforms inside enterprise environments. Those are company-reported figures, but together they point to growing momentum in one of enterprise software's most competitive markets. That market has long been dominated by companies including Datadog, Dynatrace, New Relic, Splunk and Grafana. Between them, they represent billions of dollars in annual revenue and years of product maturity. Breaking into that group has never been easy. groundcover's argument is that artificial intelligence has fundamentally changed the assumptions those platforms were built on. Rather than competing feature for feature, the four-year-old company is trying to convince enterprises that the architecture underpinning observability itself needs to change as AI systems become more autonomous, produce vastly more telemetry and increasingly participate in software operations. Whether that thesis proves correct remains an open question, but it offers a compelling lens through which to examine how observability is evolving alongside enterprise AI. AI is turning telemetry into an infrastructure problem Observability has traditionally been viewed as a post-production discipline. Engineers deploy applications, monitor logs, metrics and traces, investigate incidents, and improve reliability over time. That workflow is changing. AI-assisted software development has dramatically accelerated deployment cycles. Coding assistants generate more code, infrastructure evolves more rapidly, and organizations are deploying increasingly complex distributed systems that combine microservices, Kubernetes clusters, APIs and large language models. At the same time, enterprises are beginning to operate AI agents that execute multi-step workflows, call external tools and interact with production systems. Each of those activities generates telemetry. The result is an explosion of operational data that organizations increasingly want to retain rather than discard. AI applications introduce additional layers of observability beyond traditional infrastructure monitoring, including prompt execution, model latency, token consumption, retrieval pipelines, tool invocations and agent behavior. As enterprises experiment with autonomous systems, that telemetry becomes increasingly valuable because it provides the context needed to understand what an AI system actually did and why. For many organizations, this creates tension with pricing models that charge according to the amount of data ingested. Historically, engineers have often responded by sampling traces, shortening retention periods or limiting which data is collected. Those approaches reduce costs, but they also reduce visibility precisely when AI-driven systems demand more complete operational context. "We've seen telemetry exploding," groundcover co-founder and CEO Shahar Azulay said during a recent media briefing. "Users are frustrated by not getting all the value from Datadog and similar platforms. They're limiting the data, siloing it, sampling it." Whether that frustration is widespread enough to reshape the market remains to be seen, but the underlying trend is difficult to ignore. AI is making observability less about collecting enough data and more about collecting everything organizations may eventually need. Rather than adding AI, groundcover argues the architecture itself has to change Many observability vendors have introduced AI assistants, AI-powered root cause analysis and AI observability features over the past two years. Datadog, Dynatrace, New Relic and Grafana have all announced products aimed at helping enterprises monitor AI applications or automate operational tasks. groundcover acknowledges those developments but argues they do not address what it sees as the more fundamental issue: where telemetry lives and how customers pay for it. Instead of operating a conventional SaaS platform that stores customer telemetry in vendor-managed infrastructure, groundcover uses what it calls a bring-your-own-cloud (BYOC) architecture. Customers keep the data plane—including telemetry storage and processing— inside their own AWS, Microsoft Azure or Google Cloud environments, while groundcover provides a managed control plane and user experience. A fully self-hosted deployment option is also available. While some competitors, including Datadog and a few other observability vendors, do offer limited hybrid or customer-controlled data residency options, these are generally not equivalent to a full BYOC model. In most cases, telemetry is still processed and stored within the vendor’s managed infrastructure, with only partial controls (such as regional data residency, private links, or selective log forwarding) available. That architectural decision influences nearly every aspect of the company's strategy. Because customers already pay for their own cloud infrastructure, groundcover argues it can avoid charging based on telemetry ingestion. Instead, pricing is based primarily on monitored hosts, regardless of telemetry volume. The company believes this changes customer behavior. Rather than deciding which logs or traces are too expensive to keep, organizations can theoretically retain complete telemetry and use it for operational analysis, compliance and AI-assisted troubleshooting. "We don't price by data volume," Azulay said. "We price by the size of the infrastructure." The distinction matters because AI workloads tend to increase telemetry far faster than infrastructure itself. That does not necessarily make host-based pricing universally cheaper. Organizations with relatively light workloads spread across many hosts may find different economics than dense Kubernetes environments generating enormous amounts of telemetry. The company's own briefing notes that per-host pricing is most advantageous for organizations with high telemetry density and may be less compelling for lightly utilized fleets. Still, the broader argument is less about cost alone than predictability. Enterprise infrastructure teams often struggle with observability bills that fluctuate alongside application growth. groundcover's model attempts to align pricing more closely with infrastructure planning rather than data generation. eBPF sits at the center of the company's technical differentiation The second pillar of groundcover's strategy is eBPF, a Linux kernel technology that has rapidly become one of the most important building blocks for modern cloud observability. Instead of requiring developers to manually instrument applications, eBPF allows software running inside the operating system kernel to observe network traffic, system calls and application behavior with minimal code changes. That enables faster deployment and broader visibility across infrastructure. For organizations operating Kubernetes clusters and cloud-native applications, reducing instrumentation complexity can significantly shorten deployment times while increasing telemetry coverage. Azulay argues this becomes especially important as AI systems generate increasingly complex interactions across services. "Our sensor allows us to observe systems very deeply from infrastructure to application to AI workloads without developers needing to instrument code," he said during the briefing. eBPF itself is hardly unique. Many observability vendors now incorporate it into their platforms. What groundcover argues differentiates its approach is combining automatic eBPF collection with customer-controlled storage, OpenTelemetry compatibility and unified pricing inside a single platform. The company's own research briefing acknowledges that none of these technologies individually represents a competitive moat. The claimed differentiation lies in the combination of eBPF-first collection, managed BYOC architecture, host-based economics and full-stack observability delivered together. AI agents are becoming both customers—and users—of observability Perhaps the most interesting aspect of groundcover's strategy extends beyond traditional monitoring. The company increasingly describes observability as infrastructure for autonomous software development. Historically, observability platforms have served human operators investigating production incidents. groundcover believes future observability platforms will increasingly serve AI agents as well. Its Agent Mode product allows engineers to investigate incidents using natural language across logs, metrics, traces and Kubernetes events. More importantly, Azulay envisions observability becoming the feedback mechanism that informs coding agents about what actually happened in production. Rather than simply detecting failures after deployment, observability becomes continuous operational context that autonomous systems can use to evaluate changes, identify regressions and eventually recommend or implement fixes. "We're seeing observability moving from being a post-production tool... to people taking context from production and feeding it back to their coding agents so they can write code better," Azulay said. Today, the company emphasizes that humans remain in the loop. Agent Mode investigates incidents and surfaces recommendations, but production changes still require human approval. Azulay expects autonomy to increase gradually as organizations become more comfortable allowing AI systems to participate in operational workflows. That vision reflects a broader trend emerging across enterprise software, where AI agents increasingly span development, testing, deployment and operations rather than functioning as isolated assistants. Why some enterprises are considering alternatives groundcover is entering an intensely competitive market populated by vendors with decades of enterprise experience. Datadog alone generated more than $3 billion in annual revenue in 2025 . Dynatrace, Cisco's Splunk business, Grafana Labs and New Relic all maintain extensive partner ecosystems, mature integrations and enterprise support organizations that newer entrants cannot easily replicate. groundcover is not attempting to outscale those incumbents overnight. Instead, it argues that AI creates an architectural inflection point similar to previous transitions from on-premises infrastructure to cloud-native computing. According to Azulay, many customers initially adopt groundcover to reduce observability costs but increasingly remain because they want unrestricted access to richer telemetry and AI-native workflows. He says deployments typically replace incumbent platforms rather than operate alongside them, although the company has not publicly disclosed customer migration data or independent studies validating that claim. The company's journalist briefing also urges caution around some performance claims. Revenue growth, customer counts and enterprise adoption figures originate from groundcover itself. Published customer case studies reporting significant cost savings are vendor-authored and should not be treated as independent validation without additional evidence. The briefing also recommends scrutinizing exactly what metadata leaves customer environments in standard BYOC deployments, rather than assuming that no operational data ever reaches vendor infrastructure. Those caveats are important because the observability market has become crowded. Gartner currently tracks more than one hundred observability products, and nearly every major vendor now markets AI-powered operational capabilities. Success will likely depend less on whether AI matters—which increasingly appears inevitable—and more on whether enterprises conclude that existing architectures remain sufficient. The larger question investors are betting on Viewed narrowly, groundcover's Series C is another large infrastructure funding round. Viewed more broadly, it reflects a growing debate about what observability becomes in an era where software increasingly writes, tests and operates itself. If AI continues generating exponentially larger volumes of operational data, traditional assumptions about telemetry collection, pricing and storage may come under increasing pressure. Vendors that built businesses around charging for data ingestion may need to evolve their economics alongside customer expectations. New entrants, meanwhile, have an opportunity to design around those changing assumptions from the outset. groundcover believes that opportunity lies in combining customer-controlled infrastructure, automatic telemetry collection and AI-assisted operations into a platform designed for autonomous software rather than simply adding AI features to existing observability products. Whether that architectural bet proves durable will depend on enterprise adoption over the next several years. But the company's latest funding round suggests at least some investors believe the next battle in observability will not be fought over dashboards or alerts. It will be fought over who builds the operational data layer that increasingly intelligent software relies upon to understand—and eventually manage—the systems it runs.
- Open Model Wars + Claire Stapleton’s Dishy Google Memoir + Substack’s Slop Fight
“It just seems like the temperature is rising on Silicon Valley.”
- Indian shares notch monthly gains as AI unwind, upbeat earnings draw foreign inflows
Indian shares notch monthly gains as AI unwind, upbeat earnings draw foreign inflows Reuters
Score: 30🌐 MovesJul 31, 2026https://www.reuters.com/world/india/indian-shares-seen-opening-higher-global-cues-foreign-buying-2026-07-31/ - What Optimizely Customer Zero Teaches About Agentic AI Governance
This is the story behind writing Customer Zero Case Study: Optimizely Shows AI Success Requires Operating Model Governance. When I Went Looking For Agentic Marketing, I Found A Constraint Early in my career, my dad handed me a copy of The Goal by Eliyahu Goldratt. The book introduced me to the Theory of Constraints: Improve […]
Score: 30🌐 MovesJul 31, 2026https://www.forrester.com/blogs/what-optimizely-customer-zero-teaches-about-agentic-ai-governance/ - A Simple Answer to AI Job Loss: Tax Capital, Not Labor
U.S. policy has long favored lower taxes on profits and investment. That might need rethinking.
Score: 30🌐 MovesJul 31, 2026https://www.wsj.com/tech/ai/a-simple-answer-to-ai-job-loss-tax-capital-not-labor-cb900e62?mod=rss_Technology - AI Slop Melodramas Are Taking Over X—and Their Creators Are Cashing In
Viral tales of good triumphing over evil are racking up millions of views. They’re almost entirely AI-generated clickbait.
Score: 30🌐 MovesJul 31, 2026https://www.wired.com/story/ai-slop-melodramas-are-taking-over-x-and-their-creators-are-cashing-in/ - Americans worry robots will take jobs, but not theirs
A new poll offers an early snapshot of Americans’ attitudes toward robots in various corners of everyday life.
Score: 29🌐 MovesJul 31, 2026https://www.semafor.com/article/07/31/2026/americans-worry-robots-will-take-jobs-but-not-theirs-survey-shows - Air India to study use of electric air taxis for healthcare deliveries
Airline signs MoU with SkyDrive and Suzuki to assess feasibility of eVTOL-based medical logistics in India
- Are Tabular Foundation Models Ready to Replace Gradient Boosting Models?
A practical comparison covering architecture, TabArena benchmarks, latency, licensing, and runnable code. Continue reading on Towards AI »
- India seen as hedge against AI bubble, says Bay Capital white paper
The India-focused fund manager says foreign portfolio investors will return to Indian equities once sentiment around AI normalises
- Why Cylingo is moving into home robotics after building a 60 million-user app
After building Cece into a profitable app, Cylingo is applying its tech to a home robot designed to read the mood of a household.
Score: 28🌐 MovesJul 31, 2026https://kr-asia.com/why-cylingo-is-moving-into-home-robotics-after-building-a-60-million-user-app - Legal AI vs. Traditional Legal Research Tools
Comparison of AI-powered legal research tools against conventional methods.
- AI Software Development Metrics That Measure More Than Speed
As AI and automation become more deeply embedded in software development, CTOs need ways to distinguish genuine performance gains from simple increases in activity.
- $2m crime novel deal collapses amid questions over AI use
Agents withdraw Jerry Falade’s hotly anticipated debut after saying they can no longer authenticate ‘how the manuscript evolved’ A high-profile publishing deal for a debut crime novel has collapsed after doubts emerged over whether artificial intelligence played a role in writing it. The hotly anticipated manuscript Call Me, I’ll Hide the Body, by Jerry Falade, was withdrawn from sale by its agent despite reportedly receiving an offer for more than $2m (£1.5m) from Minotaur, owned by Macmillan US, as part of a 14-way auction. The plan was to publish it in 2028. Continue reading...
- Top Anti-Fraud Tech Helping Businesses Fight AI Fraud
Reaching never-seen-before levels, AI fraud is affecting companies of all sizes. This is how to respond and the top anti-fraud tech, according to experts.
Score: 25🌐 MovesJul 31, 2026https://www.forbes.com/sites/ray-fernandez/2026/07/31/top-anti-fraud-tech-helping-businesses-fight-ai-fraud/ - Behind the Blinking Cursor: How NPCterm Gives AI Agents a Real Terminal to Live In
If you have spent any time building AI agents that need to touch a real shell, you have probably run into the same wall: your agent fires… Continue reading on Towards AI »
- How SNTUC’s Siow Shong Seng is setting the tone for an AI-ready workforce in Singapore with Microsoft 365 Copilot
The post How SNTUC’s Siow Shong Seng is setting the tone for an AI-ready workforce in Singapore with Microsoft 365 Copilot appeared first on Source .
- From operational efficiency to intelligent decision-making: AI's new role for COOs
Chief Operating Officers now leverage artificial intelligence for enhanced operational efficiency. AI solutions analyze vast data, predicting outcomes and recommending proactive actions. This technology provides unified enterprise visibility and real-time disruption response. Intelligent automation enables businesses to scale efficiently and reduce operational costs. The ET Most Innovative AI Product Awards 2026 recognize these impactful AI solutions.
- Univé builds an AI-ready workforce
See how Univé built an AI-ready workforce with ChatGPT Enterprise by combining leadership, responsible governance, and employee-led innovation to transform work at scale.
- Building a Production-Grade Coding Agent on Snowflake: From Trial Account to Enterprise Deployment
Deploy Snowflake’s CoCo runtime as a managed agent, with a Groq-powered fallback that works today on any account — including read-only SQL guardrails and a Streamlit chat UI. What is the Coding Agent? At Snowflake Summit 2026, Snowflake announced a game-changing capability: the same runtime that powers CoCo (Cortex Code — Snowflake’s AI coding assistant) is now deployable as a managed agent via the Cortex Agents REST API. This means you can: Build a coding agent with code_toolset_all Deploy it in any application (web apps, CLI tools, pipelines) Get the full CoCo sandbox: Bash, Python, SQL, file I/O, web search Run it inside Snowflake’s governance boundary The agent is defined declaratively — a single CREATE AGENT statement — and invoked via a REST API. Snowflake handles model routing, tool invocation, and result assembly. What code_toolset_all Provides | Tool | Capability | | --------------- | ------------------------------------- | | Bash | Execute shell commands | | Read/Write/Edit | File operations on mounted workspaces | | Grep/Glob | Search files and patterns | | SQL Exec | Query Snowflake directly | | Python 3.12 | Full sandbox with pip access (PyPI) | | Web Search | Find documentation and references | | Skills Engine | Extend with custom domain skills | All running inside a managed sandbox — no infrastructure to maintain, no data leaving your governance boundary. The Reality: Not Every Account Can Run It Yet Here’s what the announcement didn’t address: code_toolset_all execution (via DATA_AGENT_RUN) requires the Cortex Code entitlement. Trial accounts get error 399504: { "message": "Cortex Code CLI is not enabled or the usage limit has been reached.", "code": "399504" } But here’s the insight: the agent object can be created on any account . Only execution is gated. This means you can deploy the entire architecture today and activate it instantly when the entitlement becomes available. Architecture: Three Paths to Production Implementation: End-to-End Step 1: Infrastructure Foundation -- Dedicated database for all agent objects CREATE DATABASE IF NOT EXISTS CORTEX_AGENTS; CREATE SCHEMA IF NOT EXISTS CORTEX_AGENTS.CODING_AGENT; -- XS warehouse - compute happens inside the managed sandbox CREATE WAREHOUSE IF NOT EXISTS CODING_AGENT_WH WAREHOUSE_SIZE = 'X-SMALL' AUTO_SUSPEND = 60 AUTO_RESUME = TRUE; -- Stage for custom skills CREATE STAGE IF NOT EXISTS CORTEX_AGENTS.CODING_AGENT.SKILL_STAGE DIRECTORY = (ENABLE = TRUE); -- PyPI access for the sandbox GRANT DATABASE ROLE SNOWFLAKE.PYPI_REPOSITORY_USER TO ROLE ACCOUNTADMIN; Step 2: Three-Tier RBAC ACCOUNTADMIN └── CODING_AGENT_ADMIN (manages lifecycle, versions, skills) └── CODING_AGENT_DEVELOPER (modifies spec, deploys candidates) └── CODING_AGENT_CONSUMER (invokes agent only) CREATE ROLE IF NOT EXISTS CODING_AGENT_ADMIN; CREATE ROLE IF NOT EXISTS CODING_AGENT_DEVELOPER; CREATE ROLE IF NOT EXISTS CODING_AGENT_CONSUMER; GRANT ROLE CODING_AGENT_CONSUMER TO ROLE CODING_AGENT_DEVELOPER; GRANT ROLE CODING_AGENT_DEVELOPER TO ROLE CODING_AGENT_ADMIN; GRANT ROLE CODING_AGENT_ADMIN TO ROLE ACCOUNTADMIN; -- Consumer can invoke but never modify GRANT CREATE AGENT ON SCHEMA CORTEX_AGENTS.CODING_AGENT TO ROLE CODING_AGENT_ADMIN; Step 3: Workspace Mounts Workspaces provide persistent file storage that the agent sandbox can mount: CREATE WORKSPACE IF NOT EXISTS CORTEX_AGENTS.CODING_AGENT.AGENT_WORKSPACE COMMENT = 'Persistent workspace for agent file operations'; CREATE WORKSPACE IF NOT EXISTS CORTEX_AGENTS.CODING_AGENT.SHARED_DATA COMMENT = 'Shared reference data'; The agent sees these as /workspace and /data — standard filesystem paths. Step 4: Create the Agent CREATE OR REPLACE AGENT CORTEX_AGENTS.CODING_AGENT.PRODUCTION_CODING_AGENT COMMENT = 'Production Coding Agent - full CoCo runtime' FROM SPECIFICATION $$ models: orchestration: claude-sonnet-4-5 instructions: system: | You are a production data engineering assistant deployed inside Snowflake. Safety Rules (NEVER violate): - NEVER execute DROP, TRUNCATE, or DELETE without explicit confirmation - NEVER modify user credentials (ALTER USER, GRANT, REVOKE) - NEVER access databases/schemas outside authorized scope - NEVER output raw credentials or secrets Operational Rules: - Always validate SQL before executing - Write outputs to /workspace for persistence - Use LIMIT clauses on exploratory queries - When errors occur, explain root cause and suggest fix tools: - tool_spec: type: code_toolset_all name: code_toolset_all tool_resources: code_toolset_all: permission_policy: type: always_allow workspace_mounts: - name: "CORTEX_AGENTS.CODING_AGENT.AGENT_WORKSPACE" type: workspace mount_path: "/workspace" - name: "CORTEX_AGENTS.CODING_AGENT.SHARED_DATA" type: workspace mount_path: "/data" artifact_repositories: - SNOWFLAKE.SNOWPARK.PYPI_SHARED_REPOSITORY $$; Key configuration choices: | Parameter | Choice | Rationale | | --------------------- | ----------------- | ---------------------------------------------- | | orchestration | claude-sonnet-4-5 | Best speed/quality for coding tasks | | permission_policy | always_allow | No human gate for automated workflows | | workspace_mounts | 2 mounts | Separate working directory from read-only data | | artifact_repositories | PyPI shared | Enables `pip install` in the sandbox | For interactive use, create a second variant with always_ask that requests permission before state changes. Step 5: The Execution Layer (7 Procedures) These Snowpark procedures are the foundation. They work on ALL accounts: EXECUTE_PYTHON — Run arbitrary Python CREATE OR REPLACE PROCEDURE EXECUTE_PYTHON(code VARCHAR) RETURNS VARCHAR LANGUAGE PYTHON RUNTIME_VERSION = '3.11' PACKAGES = ('snowflake-snowpark-python') HANDLER = 'execute' AS $$ import sys from io import StringIO def execute(session, code): old_stdout = sys.stdout sys.stdout = buffer = StringIO() local_vars = {'session': session} try: exec(code, {}, local_vars) output = buffer.getvalue() if not output and 'result' in local_vars: output = str(local_vars['result']) return output if output else "(no output)" except Exception as e: return f"ERROR [{type(e).__name__}]: {str(e)}" finally: sys.stdout = old_stdout $$; PROFILE_TABLE — Comprehensive data profiling CREATE OR REPLACE PROCEDURE PROFILE_TABLE(table_fqn VARCHAR) RETURNS VARCHAR LANGUAGE PYTHON RUNTIME_VERSION = '3.11' PACKAGES = ('snowflake-snowpark-python') HANDLER = 'profile' AS $$ def profile(session, table_fqn): df = session.table(table_fqn) row_count = df.count() fields = df.schema.fields # Returns: row count, column types, null rates, # cardinality, and sample data (first 5 rows) ... $$; VALIDATE_SQL — Read-only guardrails CREATE OR REPLACE PROCEDURE VALIDATE_SQL(sql_text VARCHAR) RETURNS VARCHAR LANGUAGE PYTHON RUNTIME_VERSION = '3.11' PACKAGES = ('snowflake-snowpark-python') HANDLER = 'validate' AS $$ import re BLOCKED_PATTERNS = [ (r"\bINSERT\b", "INSERT blocked - read-only mode"), (r"\bUPDATE\b", "UPDATE blocked - read-only mode"), (r"\bDELETE\b", "DELETE blocked - read-only mode"), (r"\bCREATE\b", "CREATE blocked - read-only mode"), (r"\bALTER\b", "ALTER blocked - read-only mode"), (r"\bDROP\b", "DROP blocked - read-only mode"), (r"\bGRANT\b", "GRANT blocked - read-only mode"), (r"\bREVOKE\b", "REVOKE blocked - read-only mode"), (r"\bCOPY\s+INTO\b", "COPY INTO blocked - read-only mode"), (r"\bEXECUTE\b", "EXECUTE blocked - read-only mode"), (r"\bSYSTEM\$", "System functions blocked - read-only mode"), (r"\bUSE\s+ROLE\b", "USE ROLE blocked - read-only mode"), # ... more patterns ] def validate(session, sql_text): for pattern, msg in BLOCKED_PATTERNS: if re.search(pattern, sql_text.upper(), re.IGNORECASE): return f"BLOCKED: {msg}" return "PASS" $$; Full procedure inventory: | # | Procedure | Purpose | Verified | | -: | ------------------------------------- | -------------------------------------- | -------- | | 1 | EXECUTE_PYTHON(code) | Run arbitrary Python | Yes | | 2 | PROFILE_TABLE(table) | Schema, nulls, cardinality, and sample | Yes | | 3 | EXECUTE_SQL(sql, max_rows) | Formatted tabular output | Yes | | 4 | TRANSFORM_AND_LOAD(sql, target, mode) | ETL pipeline | Yes | | 5 | EXPORT_TO_STAGE(sql, path, format) | Export CSV/JSON to stage | Yes | | 6 | COMPARE_TABLES(table_list) | Multi-table comparison | Yes | | 7 | VALIDATE_SQL(sql) | Read-only guardrails | Yes | The Groq Hybrid Agent: Full LLM Reasoning on Any Account Since trial accounts block all Snowflake LLM functions (CORTEX.COMPLETE, DATA_AGENT_RUN), we use Groq's free API for reasoning and Snowflake for execution. How It Works User: "What are the top 5 customers by order value?" │ ▼ Groq LLM (Llama 3.3 70B) reasons and plans │ Returns: {"action": "execute_sql", "sql": "SELECT C_NAME..."} │ ▼ Client-side guardrails check (read-only patterns) │ ▼ Snowflake executes: CALL EXECUTE_SQL('SELECT C_NAME...') │ Returns: formatted results │ ▼ Groq LLM analyzes results │ Needs more data? → loop back. Has answer? → respond. │ ▼ Final answer to user Production Hardening The hybrid agent isn’t a toy. It includes: class HybridCodingAgent: def __init__(self, groq_api_key, snowflake_config): self.audit = AuditLogger() # Structured event trail self.reasoner = GroqReasoner(...) # Token tracking + pruning self.executor = SnowflakeExecutor(...) # Retry + health check | Feature | Implementation | | ----------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Retry with backoff | 3 retries with exponential backoff (2s, 4s, 8s) for both Groq and Snowflake | | Conversation pruning | Caps conversation at 20 messages while retaining the system prompt and latest messages | | Token budget | 50K tokens per session; blocks further API calls when the limit is exceeded | | SQL guardrails | Development mode allows `CREATE`, `INSERT`, `UPDATE`, and `DELETE` (with `WHERE` clause); blocks destructive operations such as `DROP`, `TRUNCATE`, and unrestricted `DELETE`/`UPDATE` | | Connection health check | Verifies Snowflake connectivity and required stored procedures during application startup | | Audit logger | Logs every action, error, and guardrail event with timestamps | | Rate limit handling | Detects Groq HTTP 429 responses, waits using exponential backoff, and retries automatically | | Graceful degradation | Handles partial failures gracefully without terminating the user session | Why Groq? | Attribute | Value | | --------- | -------------------------------------------------------------- | | Free tier | 30 requests/minute, no credit card required | | Speed | Less than 500 ms response time (custom LPU hardware) | | Model | Llama 3.3 70B – versatile and code-aware | | API Key | [https://console.groq.com/keys](https://console.groq.com/keys) | Running the CLI Agent pip install groq snowflake-connector-python export GROQ_API_KEY='gsk_...' export SNOWFLAKE_ACCOUNT='FQDRZOE-SD47007' # org-account format export SNOWFLAKE_USER='SATISH' export SNOWFLAKE_PASSWORD='...' python groq_hybrid_agent.py ============================================================ HYBRID CODING AGENT (Production) Groq LLM (reasoning) + Snowflake (execution) Type 'quit' to exit, 'reset' to clear, 'audit' for stats ============================================================ Snowflake: connected (CZ04821, ACCOUNTADMIN) Procedures: available Groq model: llama-3.3-70b-versatile Token budget: 50,000 > Profile the ORDERS table --- Iteration 1 [tokens: 1,247/50,000] --- AGENT: {"action": "profile_table", "table": "SNOWFLAKE_SAMPLE_DATA.TPCH_SF1.ORDERS"} RESULT: Total Rows: 1,500,000 | Columns: 9 | ... --- Iteration 2 [tokens: 3,891/50,000] --- FINAL ANSWER: The ORDERS table has 1,500,000 rows with 9 columns: - O_ORDERKEY: 1.5M distinct (primary key) - O_CUSTKEY: 99,996 distinct customers - O_ORDERSTATUS: 3 values (F, O, P) - O_TOTALPRICE: range $857 to $555,285 - O_ORDERDATE: 2,406 distinct dates (1992-2998) ... Streamlit Chat UI A full-featured chat interface that brings it all together: Features | Feature | Description | | ------------------- | ------------------------------------------------------------------------------- | | Chat interface | `st.chat_input` and `st.chat_message` with full conversation history | | Agent trace | Expandable execution steps showing action, parameters, result, and duration | | Guardrail banners | Warning banner displayed when SQL execution is blocked | | Token budget meter | Visual progress bar with threshold warnings | | Quick actions | One-click buttons to trigger predefined agent actions | | Health indicators | Status indicators for Groq and Snowflake connectivity | | Export session | Download complete conversation history and execution traces as JSON | | Auto-reconnect | Automatically retries Snowflake connection failures | | Rate limit handling | Displays a waiting message and automatically retries on Groq HTTP 429 responses | Cortex Coding Agent — UI Feature Map Running It pip install streamlit groq snowflake-connector-python export GROQ_API_KEY='gsk_...' export SNOWFLAKE_ACCOUNT='FQDRZOE-SD47007' export SNOWFLAKE_USER='SATISH' export SNOWFLAKE_PASSWORD='...' streamlit run streamlit_groq_app.py Open http://localhost:8501 — you'll see the chat interface with sidebar controls. Quick Actions (Instant Trigger) The sidebar has quick action buttons that execute immediately on click — no second step needed: if st.button("📊 Profile ORDERS", use_container_width=True): st.session_state.messages.append({"role": "user", "content": "Profile ORDERS"}) st.session_state.trigger_agent = True st.rerun() # Immediately triggers agent execution DEV Environment Guardrails: Defense in Depth Since this is a coding agent for developers , the guardrails are tuned for a DEV environment — allowing developers to build and iterate while preventing destructive or privilege-escalation operations. Design Philosophy A coding agent needs to create things . Blocking all DML/DDL would make it useless for development. Instead, we protect against: Dropping entire databases/schemas (catastrophic) Bulk deletes without WHERE (data loss) Privilege escalation (GRANT/REVOKE/ALTER USER) Data exfiltration to external clouds Modifications to production reference data Layer 1: Client-Side (Python, before Snowflake call) DANGEROUS_SQL_PATTERNS = [ # --- DESTRUCTIVE OPS (blocked even in dev) --- (r"\bDROP\s+(DATABASE|SCHEMA)\b", "DROP DATABASE/SCHEMA blocked — too destructive"), (r"\bTRUNCATE\b", "TRUNCATE blocked — use DELETE WHERE instead"), (r"\bDELETE\b(?!.*\bWHERE\b)", "DELETE without WHERE blocked"), (r"\bUPDATE\b(?!.*\bWHERE\b)", "UPDATE without WHERE blocked"), # --- PRIVILEGE ESCALATION (never allowed) --- (r"\bGRANT\b", "GRANT blocked - request via admin role"), (r"\bREVOKE\b", "REVOKE blocked - request via admin role"), (r"\bCREATE\s+USER\b", "CREATE USER blocked - admin only"), (r"\bALTER\s+USER\b", "ALTER USER blocked - admin only"), (r"\bCREATE\s+ROLE\b", "CREATE ROLE blocked - admin only"), (r"\bALTER\s+ROLE\b", "ALTER ROLE blocked - admin only"), # --- ACCOUNT/ORG LEVEL (never allowed) --- (r"\bALTER\s+ACCOUNT\b", "ALTER ACCOUNT blocked - org admin only"), (r"\bALTER\s+WAREHOUSE\b.*\b(SUSPEND|RESUME)\b", "Warehouse SUSPEND/RESUME blocked"), # --- DATA EXFILTRATION (never allowed) --- (r"\bCOPY\s+INTO\b.*'s3://", "COPY to external S3 blocked"), (r"\bCOPY\s+INTO\b.*'gcs://", "COPY to external GCS blocked"), (r"\bCOPY\s+INTO\b.*'azure://", "COPY to external Azure blocked"), # --- SECURITY/NETWORK (never allowed) --- (r"\bCREATE\s+.*\bNETWORK\s+RULE\b", "Network rule creation blocked"), (r"\bCREATE\s+.*\bSECRET\b", "Secret creation blocked"), # --- PRODUCTION SCHEMA PROTECTION --- (r"\b(INSERT|UPDATE|DELETE|DROP|ALTER|CREATE)\b.*\bSNOWFLAKE_SAMPLE_DATA\b", "SNOWFLAKE_SAMPLE_DATA is read-only - use CORTEX_AGENTS schema"), ] Layer 2: Server-Side (Snowflake procedure) CALL CORTEX_AGENTS.CODING_AGENT.VALIDATE_SQL('DROP DATABASE PRODUCTION'); -- Returns: BLOCKED: DROP DATABASE/SCHEMA blocked CALL CORTEX_AGENTS.CODING_AGENT.VALIDATE_SQL('CREATE TABLE CORTEX_AGENTS.CODING_AGENT.MY_TEST AS SELECT 1'); -- Returns: PASS CALL CORTEX_AGENTS.CODING_AGENT.VALIDATE_SQL('DELETE FROM MY_TABLE'); -- Returns: BLOCKED: DELETE without WHERE blocked DEV Permission Matrix | Operation | Allowed | Rationale | |-----------|---------|-----------| | `SELECT`, `SHOW`, `DESCRIBE` | Yes | Read-only operations | | `CREATE TABLE`, `CREATE VIEW` | Yes | Create development objects | | `CREATE OR REPLACE` | Yes | Iterate on object definitions | | `INSERT INTO` | Yes | Load test or development data | | `UPDATE ... WHERE ...` | Yes | Modify specific rows only | | `DELETE ... WHERE ...` | Yes | Remove specific rows only | | `DROP TABLE`, `DROP VIEW` | Yes | Clean up development objects | | `USE DATABASE`, `USE SCHEMA` | Yes | Navigate databases and schemas | | `CREATE TABLE AS SELECT (CTAS)` | Yes | Materialize query results | | `COPY INTO @internal_stage` | Yes | Export data to internal Snowflake stages | | `DROP DATABASE`, `DROP SCHEMA` | No | Too destructive, even in development | | `TRUNCATE` | No | Use `DELETE ... WHERE ...` instead | | `DELETE` (without `WHERE`) | No | Requires a `WHERE` clause | | `UPDATE` (without `WHERE`) | No | Requires a `WHERE` clause | | `GRANT`, `REVOKE` | No | Prevent privilege escalation | | `ALTER USER`, `ALTER ROLE` | No | Administrative operations only | | `COPY` to Amazon S3, Google Cloud Storage, or Azure Blob Storage | No | Prevent data exfiltration | | Modify `SNOWFLAKE_SAMPLE_DATA` | No | Protect reference datasets | | Network rules, secrets, and security integrations | No | Infrastructure team responsibility | Even if the LLM generates a blocked operation, it shows a clear warning explaining why it was blocked and what to do instead . Version Management Agent specs evolve. Use ALTER AGENT to deploy updates: ALTER AGENT PRODUCTION_CODING_AGENT MODIFY LIVE VERSION SET SPECIFICATION $$ models: orchestration: claude-opus-4-6 -- Upgraded model ... $$; The Versioning UI (Public Preview) in Snowsight lets you compare versions side-by-side, rollback with one click, and promote candidates. Operational Monitoring -- Procedure usage by type SELECT CASE WHEN query_text ILIKE '%EXECUTE_PYTHON%' THEN 'EXECUTE_PYTHON' WHEN query_text ILIKE '%PROFILE_TABLE%' THEN 'PROFILE_TABLE' WHEN query_text ILIKE '%EXECUTE_SQL%' THEN 'EXECUTE_SQL' WHEN query_text ILIKE '%VALIDATE_SQL%' THEN 'VALIDATE_SQL' ELSE 'OTHER' END AS procedure_name, COUNT(*) AS calls, AVG(DATEDIFF('second', start_time, end_time)) AS avg_sec FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY WHERE query_text ILIKE '%CORTEX_AGENTS.CODING_AGENT.%' AND start_time >= DATEADD('day', -7, CURRENT_TIMESTAMP()) GROUP BY 1 ORDER BY calls DESC; -- Guardrail block rate SELECT DATE_TRUNC('day', start_time) AS day, COUNT(*) AS total_validate_calls, COUNT_IF(query_text ILIKE '%BLOCKED%') AS blocked_count, ROUND(blocked_count / NULLIF(total_validate_calls, 0) * 100, 2) AS block_rate_pct FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY WHERE query_text ILIKE '%VALIDATE_SQL%' AND start_time >= DATEADD('day', -30, CURRENT_TIMESTAMP()) GROUP BY 1 ORDER BY 1 DESC; Account Tier Reality ┌─────────────────────────────────────────────────────────┐ │ TRIAL ACCOUNT (what works today): │ │ ✅ Agent objects (created, versioned, ready) │ │ ✅ 7 Snowpark procedures (full execution layer) │ │ ✅ VALIDATE_SQL guardrail (server-side) │ │ ✅ Groq Hybrid Agent (CLI + Streamlit UI) │ │ ✅ Workspaces, stages, RBAC, cost controls │ │ ❌ DATA_AGENT_RUN (error 399504) │ │ ❌ CORTEX.COMPLETE (blocked) │ │ ❌ External access integrations │ ├─────────────────────────────────────────────────────────┤ │ PAID ACCOUNT (after upgrade): │ │ ✅ Everything above, PLUS: │ │ ✅ DATA_AGENT_RUN (full managed CoCo runtime) │ │ ✅ REST API + SDK + Async execution │ │ ✅ External access (GitHub, etc.) │ │ ✅ Streaming responses, multi-turn sessions │ │ │ │ UPGRADE REQUIRES: ZERO REDEPLOYMENT │ │ Agents are already created and waiting. │ └─────────────────────────────────────────────────────────┘ Upgrade Path (Trial → Paid) When your account gets the Cortex Code entitlement: No infrastructure changes — everything is deployed Enable external access (one statement): CREATE OR REPLACE EXTERNAL ACCESS INTEGRATION github_integration ALLOWED_NETWORK_RULES = (CORTEX_AGENTS.CODING_AGENT.github_access_rule) ENABLED = TRUE; 3. Verify agent runtime : SELECT SNOWFLAKE.CORTEX.DATA_AGENT_RUN('CORTEX_AGENTS.CODING_AGENT.PRODUCTION_CODING_AGENT', '{"messages": [{"role": "user", "content": [{"type": "text", "text": "Reply: AGENT_OK"}]}]}' ); -- Should return "AGENT_OK" instead of error 399504 4. Switch clients from Groq hybrid to native REST API/SDK 5. Fallback procedures remain as backup What’s Coming Next (Summit 2026 Announcements) | Feature | Status | Impact on This Architecture | |---------|--------|-----------------------------| | Skills Package | Preview Soon | Package custom skills as a single reusable URI | | Agent Toolset | Preview Soon | Reuse tools across multiple agents without duplication | | Tool Search | Preview Soon | Progressive tool discovery instead of loading all tools upfront | | Async Agent API | GA Soon | Enable background execution for long-running tasks | | Code Execution Tool | Preview Soon | Sandboxed Python execution with PDF and chart generation | | Interrupt and Resume | GA Soon | Pause, modify, and continue agent workflows | | Partial Access | Preview Soon | Support multiple permission levels for a single agent based on role | | Versioning UI | Public Preview | Visual comparison of skill and agent versions in Snowsight | ``` Our architecture supports all of these. The foundation is ready. Key Takeaways 1. Deploy Everything on Day One Agent objects, RBAC, workspaces, procedures — all deployed on trial. When the entitlement activates: zero redeployment. 2. Read-Only by Default The agent should NEVER modify production data without explicit override. 25+ regex patterns at two layers ensure this. 3. Groq is the Perfect Bridge Free, fast, no credit card. The hybrid pattern keeps data inside Snowflake while reasoning happens externally. 4. Audit Everything Every action, every blocked query, every token spent — logged and queryable. In production: “What did the agent do at 3am?” 5. Budget Your Tokens Track usage, prune conversations, cap sessions. A runaway agent loop can burn through limits fast. 6. One-Click UX Matters Quick actions should trigger immediately. Users expect instant feedback from AI interfaces. Project Structure cortex-coding-agent/ 22 files, ~4,500 lines ├── 01-infrastructure/ Database, RBAC, network ├── 02-agent/ CREATE AGENT + workspaces + versioning ├── 03-skills/ Custom skill templates ├── 04-client-integration/ │ ├── groq_hybrid_agent.py ★ Production CLI agent (555 lines) │ ├── streamlit_groq_app.py ★ Chat UI with trace (431 lines) │ ├── rest_api_example.py REST client (paid accounts) │ ├── sdk_example.py SDK client (paid accounts) │ └── async_example.py Async pattern (paid accounts) ├── 05-operations/ Monitoring + guardrail tracking ├── 06-deployment/ Checklist + CI/CD └── 07-fallback-trial/ 7 procedures + full test suite Try It Yourself # 1. Run infrastructure SQL in Snowflake (5 min) # 2. Deploy procedures (2 min) # 3. Set up locally: pip install groq snowflake-connector-python streamlit export GROQ_API_KEY='gsk_...' # Free from console.groq.com/keys export SNOWFLAKE_ACCOUNT='YOUR_ORG-YOUR_ACCOUNT' export SNOWFLAKE_USER='YOUR_USER' export SNOWFLAKE_PASSWORD='YOUR_PASSWORD' # 4. Run Streamlit UI: streamlit run streamlit_groq_app.py # 5. Or CLI mode: python groq_hybrid_agent.py "Profile the ORDERS table" The agent reasons, executes, and answers — all within your data governance boundary. No data leaves Snowflake. The LLM only sees query results, never raw data. Youtube Demo : https://medium.com/media/d4eaa4921058f2df6a7200ab07a67657/href Implementation verified on Snowflake account FQDRZOE-SD47007 (July 22, 2026). Groq hybrid agent tested with Llama 3.3 70B. All procedures and guardrails passing. Full source code in the Github cortex-coding-agent project. This article represents the author’s personal views and experience, not those of any employer. 👏 Clap if it added value 🔗 Share it with your team ➕ Follow for more 📘 Medium: Satish Kumar 🔗 LinkedIn: satishkumar-snowflake Stay tuned for the next one! 👋 Building a Production-Grade Coding Agent on Snowflake: From Trial Account to Enterprise Deployment was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.
- Chinese AI Researchers Are Finding Their Voice on X
As OpenAI and Anthropic employees grow quieter online, researchers at Chinese AI labs are flocking to X to explain their work, recruit talent, and shape the global conversation on AI.
Score: 22🌐 MovesJul 31, 2026https://www.wired.com/story/chinese-ai-researchers-are-finding-their-voice-on-x/ - The great corporate AI con has been unleashed on customers
The great corporate AI con has been unleashed on customers The Telegraph
Score: 21🌐 MovesJul 31, 2026https://www.telegraph.co.uk/business/2026/07/31/the-great-corporate-ai-con-has-been-unleashed-on-customers/ - New Frontiers Programme brings AI-native workflows to Physics PhDs
New Frontiers Programme brings AI-native workflows to Physics PhDs phy.cam.ac.uk
Score: 20🌐 MovesJul 31, 2026https://www.phy.cam.ac.uk/news/new-frontiers-programme-brings-ai-native-workflows-to-physics-phds/ - Building a Policy-Governed Multi-Agent Financial Research Workflow with Omnigent
Building a Policy-Governed Multi-Agent Financial Research Workflow with Omnigent MarkTechPost
- RAG: Mistakes that Quietly Kill Retrieval Quality
Ten specific RAG retrieval mistakes, from bad chunking to missing reranking, with concrete fixes, code, and what to measure to know it Continue reading on Towards AI »
- 34-year-old CEO bet on AI video 5 years before ChatGPT—convincing Mark Cuban to invest was the easy part
Victor Riparbelli launched Synthesia in 2017 to help people 'make a Hollywood film from a laptop.' After four years of middling results, he made a major shift.
Score: 20🌐 MovesJul 31, 2026https://www.cnbc.com/2026/07/31/ceo-bet-on-ai-video-years-before-chatgptnow-his-startup-is-worth-billions.html - Indian employees are AI-ready but enterprise workflows are a stumbling block: Study
Indian employees are AI-ready but enterprise workflows are a stumbling block: Study YourStory.com
- When A.I. Invaded ‘Heated Rivalry’ Fan Fiction, the Meltdown Was Epic
An anonymous X account posted a detailed breakdown of chatbot text in 38 popular stories inspired by the hockey romance. The fandom spiraled.
Score: 18🌐 MovesJul 31, 2026https://www.nytimes.com/2026/07/30/technology/ai-heated-rivalry-fan-fiction.html - From Framework to Reality: Operationalizing AI in Enterprise Marketing
Explores how to move AI strategies into practical, scalable marketing operations.
Score: 18🌐 MovesJul 31, 2026https://www.typeface.ai/blog/from-framework-to-reality-operationalizing-ai-in-enterprise-marketing - When the Code Becomes the CEO: Why Your Next Manager Might Be a Decentralized Agentic Loop
In five to ten years, the sharpest manager in your company might not be human, might not sleep, and might exist entirely in shared GPU memory. This is the systems-level view of the algorithmic corporation — why middle management collapses into a protocol, what breaks in the current AI stack, and what has to be built for autonomous agents to actually run a business. The post When the Code Becomes the CEO: Why Your Next Manager Might Be a Decentralized Agentic Loop appeared first on Towards Data Science .
- Bausch & Lomb CEO: the AI hysteria is nothing new
Bausch & Lomb CEO: the AI hysteria is nothing new fortune.com
Score: 18🌐 MovesJul 31, 2026https://fortune.com/2026/07/31/bausch-lomb-ceo-ai-hysteria-nothing-new-overlooks-people/ - How to Debug AI Coding Agents When They Change the Wrong Thing
A practical tutorial for recording model tool requests, real function results, patches, checks, screenshots, and a saved run log. The post How to Debug AI Coding Agents When They Change the Wrong Thing appeared first on Towards Data Science .
Score: 18🌐 MovesJul 31, 2026https://towardsdatascience.com/how-to-debug-ai-coding-agents-when-they-change-the-wrong-thing/ - When a district in Florida's Everglades used robot rabbits to eliminate Burmese pythons
Florida is employing AI-powered robot rabbits to help locate invasive Burmese pythons. These solar-powered decoys mimic prey using heat and scent to lure snakes. When a python is detected, officials are alerted to remove the invasive species. This technology complements the annual Python Challenge, which has removed thousands of snakes. These efforts aim to control the python population impacting native wildlife.
- AI fluency isn't the finish line
More than 90% of product builders say AI skills are essential to their future success. But what if we’re focused on the wrong ones?
- LingBot-Map Tutorial: GPU-Aware Inference and Point Cloud Export
LingBot-Map Tutorial: GPU-Aware Inference and Point Cloud Export MarkTechPost
Score: 15🌐 MovesJul 31, 2026https://www.marktechpost.com/2026/07/31/lingbot-map-tutorial-gpu-aware-inference-and-point-cloud-export/amp/ - AI Startup Apologizes for Offering Job Interviews in Exchange for Company Tattoos
The co-founder of LemonLime set off an uproar after offering attendees at a networking party a dare of sorts.
- Uplers introduces AI-powered matching to help startups hire faster
Uplers introduces AI-powered matching to help startups hire faster YourStory.com
Score: 15🌐 MovesJul 31, 2026https://yourstory.com/2026/07/uplers-introduces-ai-powered-matching-help-startups-hire-faster - What Most Developers Still Don’t Know about OpenAI API
A practical breakdown of OpenAI API tool use: web search, code interpreter, vision, function calling, and JSON mode, the features most AI… Continue reading on Towards AI »
- Would you get tattooed just to interview at a 7-days-a-week AI startup?
LemonLime’s CEO got “carried away” with tattoo gimmick.
Score: 15🌐 MovesJul 31, 2026https://arstechnica.com/culture/2026/07/ai-startup-admits-tattoo-for-interview-stunt-was-reckless/ - Why AI-powered marketing is becoming essential to partner growth
The post Why AI-powered marketing is becoming essential to partner growth appeared first on Source .
Score: 15🌐 MovesJul 31, 2026https://partner.microsoft.com/en-us/blog/article/partner-marketer-campaign - Special Digital Issue: The AI Economy
Special Digital Issue: The AI Economy fortune.com
- Sudan civil war: When drones strike the classroom
Children in Sudan's besieged city of el-Obeid are afraid to go to school as drone attacks hit civilian infrastructure. Aid groups warn of a worsening humanitarian crisis.
Score: 13🌐 MovesJul 31, 2026https://www.dw.com/en/sudan-civil-war-when-drones-strike-the-classroom/a-78089487?maca=en-rss-en-all-1573-rdf - 100% Recall, 38.5% Precision: What Happened When My AI Auditor Audited Itself
Building a review-gated, tamper-evident audit pipeline for agentic AI and discovering that the auditor was not ready for production The most useful output from my AI-auditing system was a red status label: Requires Review. ThirdLine had caught all five defects I deliberately planted in a synthetic fleet of banking agents. Recall was 100%. On the deterministic evaluator, F1 reached 0.909. Then I ran the audit end to end with GPT-4o-mini on the same test fleet. Precision fell to 38.5%, F1 fell to 0.556, and the system’s own model card failed it against the threshold I had written. ThirdLine is a system that audits other AI agents, checking them for hallucination, bias, drift, and security failures before those failures reach production. This piece walks through how the audit pipeline and its human-review gate work, and what the results revealed about the limits of using AI to audit AI. That failure became the real project. ThirdLine is open source under the MIT license, the full implementation discussed below is available on GitHub. The governance gap is narrower and stranger than it sounds On April 17, 2026, the Federal Reserve, OCC, and FDIC issued revised model-risk guidance. A footnote explicitly states that generative and agentic AI are outside its scope because they are novel and rapidly evolving. The same footnote immediately adds that banks should still use their risk-management and governance practices to determine appropriate controls. That is not an exemption from governance. It is a gap in prescriptive model-validation guidance. Traditional validation works best when the object under review is comparatively stable: defined inputs, defined outputs, a measurable error distribution, and a controlled release process. An agent can retrieve different context, change the prompt it sends downstream, call tools, retry failed steps, and follow a different execution path for the same user request. The unit under audit is no longer just a model. It is a system with state, permissions, dependencies, and runtime behavior. I built ThirdLine to test one possible response: an orchestrator and five specialist evaluators auditing five synthetic banking agents across hallucination, bias, drift, robustness, and reliability. The pipeline discovers the fleet, collects evidence, evaluates interactions, maps failures to controls, drafts findings, and places every finding into a human review queue. The obvious objection is that an AI auditor can be wrong too. I agree. The design only makes sense if the auditor can produce evidence but cannot grant itself authority. Figure 1: ThirdLine’s six-step audit pipeline, from fleet discovery to the human review queue. Image by author. A human-in-the-loop gate has to be more than a warning Many agent workflows call something “human in the loop” when they really mean “log a warning and continue.” That is monitoring, not a control boundary. In ThirdLine, the orchestrator’s final step writes each finding to a queue with a PENDING status and a severity-based service-level deadline. The orchestration component contains no branch that changes the finding to APPROVED. def _step_hitl_gate( self, findings: list[dict], run_id: str, ) -> list[dict]: queue_entries = [] for finding in findings: sla_hours = { "CRITICAL": 4, "HIGH": 24, "MEDIUM": 72, "LOW": 168, } now = datetime.now(timezone.utc) deadline = now + timedelta( hours=sla_hours.get(finding["severity"], 24) ) entry = { "queue_id": str(uuid.uuid4()), "finding_id": finding["finding_id"], "severity": finding["severity"], "status": "PENDING", "sla_deadline": deadline.isoformat(), "run_id": run_id, } queue_path = ( self._queue_dir / f"{entry['queue_id']}.json" ) queue_path.write_text( json.dumps(entry, indent=2, default=str) ) queue_entries.append(entry) return queue_entries The important choice is not the JSON file. It is the absence of an approval capability inside the component that generated the finding. Severity also changes the operational expectation. A critical finding is due in four hours; a low-severity item can wait seven days. But reviewing the implementation forced me to narrow my own claim. The current API exposes approval and rejection endpoints without an authentication dependency. Reviewer identity is supplied as a string in the request body, with “auditor” as its default value. The orchestrator also marks an audit run COMPLETE after placing its findings in the queue, even though those findings remain pending. The prototype therefore enforces a workflow boundary inside the orchestrator. It does not yet prove that the caller approving the finding was an authorized human. That distinction matters in a regulated system: “The agent cannot approve its own output” is weaker than “only a separately authenticated reviewer with the correct role can approve it.” Before calling this production-ready, I would add identity-aware authentication, role-based authorization, separation-of-duties checks, reviewer identity derived from an access token, transactional state transitions, and an explicit WAITING_FOR_REVIEW run state. The architecture had the right instinct. The security boundary was incomplete. The ledger is tamper-evident, not tamper-proof The second mechanism is a SHA-256 hash-chained audit ledger. Each finding event — drafted, approved, or rejected — stores a hash derived from the previous ledger entry and the current event: chain_hash = sha256(previous_hash + finding_hash) If someone edits an old entry without updating the rest of the chain, verification fails at that point. This is better than a plain mutable log because partial historical edits become detectable. It is not a blockchain, and it is not a complete answer to privileged tampering. A user with permission to rewrite the entire JSON ledger can modify history and recompute every later hash. The chain will verify because the attacker replaced both the data and the evidence used to verify it. Hash chaining proves internal consistency. By itself, it does not prove that the chain is the original one. For a defensible production design, I would anchor periodic chain heads outside the application’s write boundary. Options include signed checkpoints, a signing key held in a key-management system, append-only storage retention, or an external transparency service. That would turn the current local tamper signal into evidence that a privileged application user cannot silently recreate. This also changed the language I would use to describe the feature. Tamper-evident is accurate. Cryptographically verified is too broad unless the root used for verification is independently protected. The metric that looked best hid the real problem The headline result was 100% recall in both evaluation modes. Every injected defect was detected. That sounds excellent until precision enters the picture. The deterministic run produced 83.3% precision, 100% recall, and an F1 score of 0.909. With five injected defects and no misses, those values correspond to five true positives and one false positive. The GPT-4o-mini run also found all five defects, but precision dropped to 38.5% and F1 to 0.556. That corresponds to five true positives and eight false positives. Evaluation mode True positives False positives Recall Precision F1 Deterministic 5 1 100% 83.3% 0.909 GPT-4o-mini 5 8 100% 38.5% 0.556 Eight false alarms for five real defects is not a cosmetic issue. In an audit queue, false positives consume reviewer time, delay real findings, and teach operators to distrust the system. High recall protects against missed risk; low precision creates alert fatigue. A governance tool needs both. This also exposed an error in my first headline. I had written “100% recall, 55% precision.” The 55.6% number was F1, not precision. The actual precision was 38.5%. That is exactly the kind of flattering metric substitution an audit system should prevent — including when the person making the mistake is its builder. The gap between deterministic and LLM-based evaluation is the most important result in the project. The controlled evaluator benefited from known signatures and synthetic failure patterns. Real model outputs varied in length, phrasing, and borderline behavior. Rules that looked calibrated in a controlled environment became noisy when the generator was allowed to behave like a generator. Figure 2: Detection performance in deterministic and GPT-4o-mini evaluations. Recall remained at 100%, while precision fell from 83.3% to 38.5%. Image by author. My auditor failed its own audit ThirdLine includes a “Validate the Validator” module with minimum thresholds: F1 must be at least 0.70. Recall must be at least 0.90. The false-positive rate must not exceed 0.25. The GPT-4o-mini run passed recall at 100% and judge consistency at 97.9%. It failed F1 at 0.556 and failed the false-positive-rate limit at 61.5%. The generated model card therefore labeled the system Requires Review and stated that it did not meet its minimum governance standards for deployment. That is the result I trust most. There is another important nuance. The model card identifies PSI-based drift detection as a known limitation: output-length variance from real LLM responses can create false drift findings. But the self-audit code does not autonomously isolate PSI as the root cause. Its calibration check compares observed precision with a fixed confidence assumption of 0.85, while the PSI explanation is documented separately as a suspected limitation. The accurate claim is: The self-audit exposed overconfidence and unacceptable false positives; follow-up analysis pointed to PSI calibration as one contributor. Saying the system “diagnosed its own PSI bug” would overstate what the code does. I also added an eval-as-test gate to GitHub Actions. The workflow generates a synthetic fleet, runs the audit and meta-evaluation, and fails when F1 falls below 0.70. That is useful because evaluator quality becomes a release condition instead of a dashboard metric. It is still a narrow gate. The checked-in workflow does not exercise the live GPT-4o-mini path, so passing CI does not establish that the behavior that failed the model card is ready. What I would change next First, I would calibrate each evaluation dimension separately. A single global result hides whether the false positives originate mainly in drift detection, hallucination judging, or another evaluator. Precision-recall curves by dimension would make tuning decisions visible instead of anecdotal. Second, I would replace output-length PSI with representations closer to semantic behavior: embedding distributions, task-specific outcome features, and drift tests conditioned on prompt category. Length can be a useful signal. It is a fragile proxy for meaning. Third, I would test the reviewer boundary as aggressively as the model boundary. Can an unauthenticated caller approve a finding? Can one identity both create and approve it? Can queue state be changed without a ledger event? Governance claims should have adversarial tests, not just architecture diagrams. Finally, I would externally anchor the ledger and run the real-model evaluation as a scheduled quality gate. A deterministic test is valuable for regression control. It should not become a comforting substitute for the behavior that actually failed. The implementation, evaluation code, and generated model card are available in the ThirdLine repository . The limitation report is as important as the feature list. The broader lesson is not that AI should never audit AI. It is that a probabilistic auditor needs non-probabilistic boundaries around authority, identity, evidence, and release decisions. When your AI auditor raises a finding, what proves that the reviewer was authorized and what proves that the audit history was not rewritten afterward? 100% Recall, 38.5% Precision: What Happened When My AI Auditor Audited Itself was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.
- Partnerships - NSF AI Institute for Societal Decision Making
Partnerships - NSF AI Institute for Societal Decision Making Carnegie Mellon University
- RoshAi Company Profile Funding & Investors
RoshAi Company Profile Funding & Investors YourStory.com
- Isn’t AI terrible enough already? Now they want to eat the world’s books?! | First Dog on the Moon
Leave books alone! Sign up here to get an email whenever First Dog cartoons are published Get all your needs met at the First Dog shop if what you need is First Dog merchandise and prints Continue reading...
- Podcast - NSF AI Institute for Societal Decision Making
Podcast - NSF AI Institute for Societal Decision Making Carnegie Mellon University