Modern businesses are in a constant, uphill battle against what to do with unstructured data: PDFs, contracts, scanned images, customer call recordings, meeting videos, and more. Traditional document automation workflows that rely heavily on template-based extraction or rigid rules used to make sense. But document formats have changed; they’re diverse and don’t fit standard formats, making costly, brittle, traditional systems a relic of the past. 

“Modern businesses are in a constant, uphill battle against what to do with unstructured data.”

Enterprises demand faster, more accurate processing, which raises the question: How can we reliably turn messy, multimodal content into structured, actionable insights without a mountain of manual effort?

That’s where Amazon Bedrock Data Automation (BDA) comes in.

What is Amazon Bedrock Data Automation (BDA)?

Amazon Bedrock Data Automation (BDA) is a generative AI-powered, fully managed service on Amazon Web Services for end-to-end document and media automation. It enables users to automate the extraction, classification, and transformation of unstructured content across modalities such as documents, images, audio, and video.

“At its core are Foundation models which enable intelligent extraction and understanding of content.”

At its core are Foundation models (FMs) which enable intelligent extraction and understanding of content. It allows users to configure standard output for common use cases, or even define custom extraction logic using blueprints tailored to your business. BDA is designed for scalability, accuracy, and auditability, making it ideal for enterprise workflows.

Walk-through: creating a project, standard output & custom output using blueprints

1. Create a project via console

In the Amazon Bedrock Console, navigate to Data Automation → Create Project.

Enter the name of the project:

2. Standard output:

Standard output gives you the model’s default, unstructured response (text, image, audio, or video) directly from the Data Automation pipeline.

In standard output, each modality has its own options for what is needed as an output. 

Document:

Image & Video:

Audio:

Now let’s test Document Modality for Standard Output:

First, click on “Test” in the upper right corner.

Next, select the document from the system, sample, or S3 and choose the modality from the dropdown menu. 

Click on the “Generate results” button:

After processing, it will show the summary and content of the document:

Custom output (blueprints):

Custom output lets you define a structured, predictable format using blueprints, which ensures the output matches your exact schema, fields, and business rules.

Let’s test custom output using blueprints for the same document:

Navigate to “Custom output” and click on “Add Blueprint”:

From here, two options will appear. You can either use LLM power to generate the blueprint (where it inspects the document), or you can choose to enter field names, instructions, and other information manually.

Below is a blueprint generated by LLM which has pulled all possible fields and tables from the document:

It has extracted the information using the blueprint as demonstrated below, including the  Field name, Instruction, and Results:

It also provides the Extraction type (which can be Explicit or Inferred), Confidence percentage, and other relevant information.

Additionally, it can extract information in the form of a table, such as an account summary or transaction information:

Code examples

Amazon Bedrock Data Automation (BDA) Utility Module
Description:
    Helper functions to create BDA projects, blueprints, invoke jobs,
    monitor job status, and fetch results.

import boto3
import time
import json
import botocore

class BedrockDataAutomation:
    def __init__(self, region="us-east-1"):
        self.bda = boto3.client("bedrock-data-automation", region_name=region)
        self.runtime = boto3.client("bedrock-data-automation-runtime", region_name=region)

    # ------------------------------------------------------------
    # BLUEPRINT OPERATIONS
    # ------------------------------------------------------------
    def create_blueprint(self, name, schema, description="", stage="LIVE"):
        """
        Create a BDA Custom Output Blueprint from a JSON schema.
        """
        print(f"Creating blueprint: {name}")

        response = self.bda.create_blueprint(
            blueprintName=name,
            blueprintStage=stage,
            type="DOCUMENT",
            schema=json.dumps(schema)
        )
        return response["blueprint"]["blueprintArn"]

    # ------------------------------------------------------------
    # PROJECT OPERATIONS
    # ------------------------------------------------------------
    def create_project(self, name, description, standard_output_config, custom_output_config=None):
        """
        Create a BDA Project with Standard or Custom Output.
        """
        print(f"Creating project: {name}")

        response = self.bda.create_data_automation_project(
            projectName=name,
            projectDescription=description,
            projectStage="LIVE",
            standardOutputConfiguration=standard_output_config,
            customOutputConfiguration=custom_output_config or {}
        )
        return response["projectArn"]

    # ------------------------------------------------------------
    # INVOCATION OPERATIONS
    # ------------------------------------------------------------
    def invoke_project(self, project_arn, profile_arn, input_s3_uri, output_s3_uri, blueprints=None):
        """
        Invoke a BDA project using async invocation.
        """
        print(f"Invoking project: {project_arn}")

        kwargs = {
"inputConfiguration": {"s3Uri": input_s3_uri},
"outputConfiguration": {"s3Uri": output_s3_uri},
"dataAutomationConfiguration": {
"dataAutomationProjectArn": project_arn,
"stage": "DEVELOPMENT"
},
"dataAutomationProfileArn": profile_arn
}

        if blueprints:
kwargs["blueprints"] = blueprints

        response = self.runtime.invoke_data_automation_async(**kwargs)
       invocation_arn = response["invocationArn"]

       print("Invocation ARN:", invocation_arn)
       return invocation_arn

    # ------------------------------------------------------------
    # JOB STATUS POLLING
    # ------------------------------------------------------------
    def wait_for_job(self, invocation_arn, poll_interval=10):
        """
        Poll until job finishes.
        Returns final status object.
        """
        print("Polling job:", invocation_arn)

        while True:
            try:
                resp = self.runtime.get_data_automation_status(
                    invocationArn=invocation_arn
                )
            except Exception as e:
                print("Error fetching status:", e)
                raise

            status = resp["status"]
            print(f"Status: {status}")

            if status in ("SUCCEEDED", "FAILED", "CANCELLED"):
                return resp

            time.sleep(poll_interval)



# --------------------------------------------------------------------
# EXAMPLE USAGE
# --------------------------------------------------------------------
if __name__ == "__main__":
    bda = BedrockDataAutomation(region="us-east-1")

    # 1. Create Blueprint
    blueprint_schema = {
        "type": "object",
        "properties": {
            "account_holder": {"type": "string"},
            "balance": {"type": "string"},
            "transactions": {
                "type": "array",
                "items": {
                    "type": "object",
                    "properties": {
                        "date": {"type": "string"},
                        "description": {"type": "string"},
                        "amount": {"type": "string"}
                    }
                }
            }
        },
        "required": ["account_holder", "transactions"]
    }

    blueprint_arn = bda.create_blueprint(
        name="BankStatementBlueprint",
        schema=blueprint_schema,
        description="Extract fields from bank statements."
    )

    # 2. Create Standard Output Config
    standard_config = {
        "document": {
            "extraction": {
                "granularity": {"types": ["PAGE", "LINE"]},
                "boundingBox": {"state": "ENABLED"}
            },
            "outputFormat": {
                "textFormat": {"types": ["PLAIN_TEXT", "CSV"]}
            }
        }
    }

    # 3. Create Project with Custom Blueprint
    project_arn = bda.create_project(
        name="BankStatementProject",
        description="Process PDF bank statements",
        standard_output_config=standard_config,
        custom_output_config={
            "blueprints": [
                {
                    "blueprintArn": blueprint_arn,
                    "blueprintStage": "DEVELOPMENT",
                    "blueprintVersion": "1"
                }
            ]
        }
    )

    # 4. Invoke the project
    # Ensure you replace <ACCOUNT_ID> with your actual AWS Account ID
    profile_arn = "arn:aws:bedrock:us-east-1:<ACCOUNT_ID>:data-automation-profile/us.data-automation-v1"
    invocation_arn = bda.invoke_project(
        project_arn=project_arn,
         profile_arn=profile_arn,
        input_s3_uri="s3://your-bucket/input/statement.pdf",
        output_s3_uri="s3://your-bucket/output/",
        blueprints=[
            {
                "blueprintArn": blueprint_arn,
                "version": "1",
                "stage": "DEVELOPMENT"
            }
        ]
    )

    # 5. Poll job status
    final_status = bda.wait_for_job(invocation_arn)
    print("Final status:", json.dumps(final_status, indent=4))

Types of document blueprints

When processing documents, BDA supports five core automation types:

1. Classification: invoice, bank statement, ID card, contract, HR letter, etc.

2. Extraction: Extract entities, fields, tables, metadata.

• Example: From a bank statement → Date, Description, Amount, Balance.

3. Transformation: Modify or restructure data.

• Example: Convert Home Address into separate fields -> street, city, ZIP code, etc.

4. Normalization: Standardize data values.

• Example: Convert multiple date formats (MM/DD/YYYY → YYYY-MM-DD).

5. Validation: Validate extracted fields against rules.

• Example: Amount must be numeric; dates must match the format; balances must reconcile.

Use cases that illustrate business value

Real-world scenarios where BDA provides significant ROI include:

• Financial Services: Automate processing of bank statements, invoices, and loan applications, reducing manual labor and speeding up reconciliation or underwriting.
  
• Insurance: Ingest and extract data from claims forms, medical reports, and damaged-asset photos.
  
• HR / Legal: Process resumes, contracts, and offer letters; extract structured data, including skills, clauses, salaries, and parties.
  
• Customer Support: Transcribe and summarize calls, extract intent and sentiment, and feed those insights into CRM or case systems.
  
• Security & Compliance: Analyze CCTV footage or meeting recordings to detect key actions, summarize context, and flag compliance issues.

BDA proves itself flexible and powerful, as it supports both standard outputs for basic workflows and fine-tuned custom schemas via blueprints. It is scalable and robust, with projects that enable batch processing and versions (development vs. live) for safe testing. It’s also audit-friendly, providing structured fields with types, normalization rules, and validation logic. 

“Compared with rule-based systems, foundation models achieve better semantic extraction across the board.”

A true key benefit is that BDA is multimodal across formats. Users can use the BDA framework to process documents, images, audio, and video. And, best of all, it’s highly accurate. Compared with rule-based systems, foundation models achieve better semantic extraction across the board. 

Amazon Bedrock Data Automation empowers businesses to transform unstructured, multimodal content into structured, trustworthy, and actionable data. With minimal setup, highly customizable blueprints, and a scalable project-based architecture, BDA helps organizations reduce manual workload and unlock insights faster.

The post Template-based data extraction is dead. Here’s what comes next. appeared first on The New Stack.

OpenAI on Wednesday announced Jalapeño, its first custom inference accelerator, co-developed with Broadcom and supported by Canadian electronics manufacturer Celestica, and the first step in its multi-generation compute platform. 

The AI company says Jalapeño was designed to work with all large language models (LLMs) and will help make AI faster, better, and cheaper. Behind that rosy mission, OpenAI isn’t shy about its desire to own the full AI stack, something more AI giants are already leaning into.  

“Those serious about platforms should be serious about silicon.”  

As Ben Bajarin, CEO and principal analyst at consumer technology research firm Creative Strategies, posted on X: “Those serious about platforms should be serious about silicon.”  

But with few technical details released, developers are left wondering if OpenAI’s widening footprint will be empowering or restrictive. 

Get in, Big Tech. We’re all building in-house chips now. 

OpenAI isn’t the only Big Tech name to mint its own AI chips. 

Way back in 2016, Google designed and built its own custom hardware for TensorFlow, its machine learning software, the Tensor Processing Unit (TPU). A couple of years later, Amazon debuted AWS Inferentia, its first purpose-built chip for AI and ML. Trainium then hit the scene in 2022, shortly followed by Microsoft’s Azure Maia AI Accelerator in 2023. And nothing is certain yet, but in April, Reuters reported Anthropic is contemplating designing its own chips, though the AI company remains noncommittal for now, at least publicly. 

Why is everyone jumping on the custom-chip bandwagon? 

Blame the compute gold rush, as AI companies increasingly clamor for compute power — ”a compute-powered economy,” as Greg Brockman, president, chairman, and co-founder, OpenAI, puts it. And the numbers surely back it; Stanford’s 2025 AI Index Report says, “training compute doubles every five months.”

While building custom AI chips in-house doesn’t completely alleviate compute pressures, it is one way for OpenAI and its Big Tech brethren to expand compute capacity while potentially lowering costs and reducing reliance on third-party suppliers. 

Exciting claims, no proof

In its announcement blog post, OpenAI describes its new chip as “designed to be the best inference platform for LLMs.”

Specifically, Richard Ho, head of hardware at OpenAI, states: 

“We optimized the architecture around the kernels, memory movement, networking, and serving patterns that matter most for frontier AI models. Based on early testing, Jalapeño will efficiently execute our most important workloads close to the hardware’s theoretical limits.”

But the AI company remains tight-lipped on any real technical details. 

While it claims current tests put Jalapeño’s performance “substantially better than current state-of-the-art,” it doesn’t provide benchmarks to back that up. Instead, it tells developers to expect a detailed technical report “in the coming months.”

What OpenAI does divulge is that engineering samples of the chip are currently running on ML workloads in its lab, including GPT-5.3-Codex-Spark.

Will Jalapeño serve developers, or is OpenAI’s desire to own the AI stack? 

OpenAI makes no qualms about its quest for full-stack control. In doing so, the AI company claims it will make its models “faster, more reliable, and more affordable for users.”

Its logic goes a little something like this: Better infrastructure means more efficient compute, which means better training, which means better models, which means better products, which means more revenue. Then, it explains, it can reinvest that revenue in its infrastructure to make intelligence better for everyone.

But given how little the AI company has revealed about the chip’s specs, it seems developers will have to sit back and watch where the chips fall. 

Jalapeño, then, is simply the next move in OpenAI’s quest to control the whole AI chessboard, moving beyond models and products to the underlying infrastructure itself. 

For developers, OpenAI seems adamant on insisting its full-stack strategy will lead to better performance and pricing for everyone and ultimately empower “anyone trying to learn, create, or solve hard problems.” Still, it’s worth considering: As OpenAI’s grip tightens, will developers become beholden to its ecosystem? 

Several times in its announcement, OpenAI reiterates that it designed Jalapeño for current and future LLMs — all of them. But given how little the AI company has revealed about the chip’s specs, it seems developers will have to sit back and watch where the chips fall. 

Built fast with a long roadmap ahead

The few behind-the-scenes details OpenAI does choose to share boast about its development speed, stating it brought Jalapeño from design to manufacturing tape-out in nine months — “what we believe to be the fastest ASIC development cycle ever achieved in high-performance advanced semiconductors.”

The AI company chalks up that fast timeline, in part, to its own models accelerating parts of the design and optimization processes. 

Looking ahead, Jalapeño is slated for deployment at a gigawatt scale in Microsoft’s and other partners’ data centers by the end of the year. 

That’s just the beginning. OpenAI hints at an upcoming multi-generation roadmap, posing the question: What will it seek to control next? 

The post OpenAI wants to claim more of the AI stack with Jalapeño, its first custom chip appeared first on The New Stack.

Organizations are racing to apply AI across the enterprise, and infrastructure is one of the most compelling targets: automated provisioning, self-healing networks, and agents that deploy and manage servers without human intervention. The promise is real, but so is the risk. 

No matter the domain, AI agents are only as good as the data they’re given. Agents without a complete and accurate picture of the network and associated infrastructure will make confident mistakes. In infrastructure, those mistakes have brand and revenue-related consequences: exposed databases with PII, failed deployments, and outages that take the entire business offline. 

“Agents without a complete and accurate picture of the network and associated infrastructure will make confident mistakes.”

Most enterprise infrastructure is managed through a patchwork of siloed, fragmented tools: separate systems for IP address management, data center inventory, and device configuration. The list goes on.

Each system captures a slice of the picture, but none of them complete the full vision. HyperFRAME found that over 70% of industry leaders identified this as a core bottleneck. Agentic automation cannot solve this issue, but it will expose it through its failures.

Before you can trust an AI agent with your infrastructure, you need to give it something to trust: a single, unified model of what’s on your network, how it’s configured, and how it’s supposed to behave. According to NetBox Labs CEO and cofounder Kris Beevers, that’s an Infrastructure Intelligence platform.

What is infrastructure intelligence?

Whether run by AI or human agents, infrastructure is impossible to manage when critical systems contain unknowns. Infrastructure intelligence is the foundational blueprint of your infrastructure: a unified, continuously updated model that captures not just what exists, but what is intended, what has changed, and what needs attention. It is the prerequisite for automation at any scale.

“AI is raising the stakes for infrastructure management, and the challenge is no longer just documenting infrastructure; it’s also understanding it…”

“AI is raising the stakes for infrastructure management, and the challenge is no longer just documenting infrastructure; it’s also understanding it,” says Beevers. “A source of truth was enough for the last decade. But today, teams need context – a trusted, continuously updated understanding of infrastructure that helps them (and their AI agents) model, see, act, and govern with confidence. AI doesn’t eliminate the need for infrastructure data. It makes it more important than ever.” 

It starts with a system of record. More than just an inventory list: it is a living representation of the intended state (what everything is supposed to look like) and the operational state (what it actually looks like right now) of your network. The gap between these two states is drift, and that is where risk lives. Without a system that tracks both states simultaneously, your team is always reacting, chasing down misconfigurations, and manually reconciling tool outputs (hoping nothing critical slips through).

Full infrastructure context connects the intent and design to the operational state, providing drift detection, observability, and lifecycle management tools in a single continuous data thread. Instead of switching between five different tools to answer a single question about a specific device, your team and your agents have all the information they need in one place. What is the device supposed to be doing? What is it actually doing? When did it change, and who changed it? Full context means that these questions have immediate answers.

Guardrails close the loop. Both humans and AI agents can make well-intentioned errors, and in infrastructure, the blast radius of these errors can be severe. For this reason, your infrastructure must have well-defined audit trails, branching workflows, change management processes, and operational validation from the beginning, not as an afterthought after something goes wrong. 

Teams move from handholding every agent action to trusting the system to catch bad outcomes. Cautious early adoption quickly grows into confident, autonomous, scaled deployments.

The foundation for any automation journey

Agentic automation/Agentic NetOps is coming to infrastructure teams, whether they are ready or not.

No matter where a company is in its automation journey, Infrastructure Intelligence provides a strong foundation for everything else. Organizations that are early in their automation strategy have manual processes they want to automate — they need a clear picture of the environment to do this safely. Teams that are running agentic workflows across complex, multi-site networks share the same requirement: Infrastructure intelligence.

NetBox Labs, the commercial steward of the open-source NetBox, recently expanded its platform to ensure that every infrastructure management workflow can be addressed by agents. The announcements make infrastructure AI Agent-Native: Extending the NetBox MCP server across the entire NetBox Labs Platform and releasing an array of pre-built agent skills.

These agentic tools are designed to leverage the existing infrastructure intelligence from NetBox Labs’ systems, ensuring that all agentic network provisioning capabilities are combined with the required guardrails, validations, and protections to keep the network running smoothly. 

Adding agentic features across the entire NetBox Labs infrastructure intelligence platform gives agents unprecedented knowledge, skills, and power. Agents can access NetBox Data Exchange — the world’s largest database of infrastructure metadata. NetBox Assurance and Discovery helps teams and their agents identify and mitigate drift.

“Giving AI agents access to production infrastructure without guardrails is a recipe for outages.”

According to NetBox CEO and cofounder Kris Beevers, “The future isn’t just autonomous infrastructure. It’s a trustworthy infrastructure. We know that trust and governance are the foundation of AI-driven operations. Giving AI agents access to production infrastructure without guardrails is a recipe for outages. That’s why we’ve paired these AI agent native updates with new validation tools so teams can ask, “‘Is this change safe to deploy?’ and ‘What breaks if this fails?’”

The new validation tools help agents self-correct, validate changes, and meet compliance requirements, ensuring continuous compliance and pre-change safety within the System of Record.

AIOps teams that establish a foundation of infrastructure intelligence gain more than efficiency, visibility, and control. They gain the confidence to automate services in production without losing sleep over it. Agents stop guessing and operate from verified real-time data. Teams stop reacting and focus on building. And the organization does not see AI as a liability, but as a capability that can be expanded.

NetBox Lab’s new infrastructure intelligence platform is designed for both humans and agents, making it easier to manage infrastructure across every lifecycle stage — from design through end-of-life.

Whether you’re a NetBox open source user or NetBox Labs customer, you can celebrate NetBox turning 10 at its inaugural conference, NetBox Evolve, which will be in Florida at the Kennedy Space Center on October 13, 2026.

The post Agentic infrastructure operations begin with accurate, reliable infrastructure data appeared first on The New Stack.

This week, Sakana AI released Fugu, a multi-agent orchestration system designed to deliver frontier-model performance all while reducing the risks of relying on a single provider. 

The Japanese AI R&D company says Fugu performs as well as Anthropic’s Fable 5 and Mythos Preview on engineering, scientific, and reasoning benchmarks by breaking up tasks into subtasks and strategically routing them across a swappable pool of expert agents. But early reactions are mixed.

While Sakana positions Fugu’s “collective intelligence” as the blueprint for AI sovereignty, not all users report frontier-model-level performance. Others note fast burn rates and unnecessarily high prices. 

Many agree that, though interesting, Fugu likely won’t be the hero to AI sovereignty it hopes to be. 

Is this just another router? Not really. 

Sakana says Fugu’s internal routing logic is founded on its own research in learned model orchestration, specifically noting two papers, Trinity and the Conductor. 

Unlike multi-model routers, such as OpenRouter Fusion, that send a prompt to multiple models and then compare or combine the results, Fugu breaks down user prompts into subtasks and determines which subtask to send to which model. In this way, Fugu “dynamically orchestrates the world’s best models to tackle complex, multi-step tasks,” so Sakana says. 

From the outside, you just see what looks like one model, accessible via a single OpenAI-compatible API.

But what the AI company doesn’t tell you is how it decides which tasks get routed where; that information is proprietary. From the outside, you just see what looks like one model, accessible via a single OpenAI-compatible API.

“relying on a single company’s model for national infrastructure is a massive risk. As recent export controls have shown, access to top models can disappear overnight.”

Fugu doesn’t have to farm out every task, though. It’s a language model itself, specialized for model selection, delegation, verification, and synthesis internally, so it can also solve requests directly when its own response is sufficient.

A hero for AI sovereignty, it appears not

In an X post, Sakana CEO and co-founder David Ha writes, “relying on a single company’s model for national infrastructure is a massive risk. As recent export controls have shown, access to top models can disappear overnight.”

That “massive risk” comment is likely a jab at what happened to Anthropic, when an export control directive forced the AI company to pull Fable 5 and Mythos 5 just three days after launch. 

See also: Fable 5 ban: 4 open models responded before Anthropic could restore access

Following this news, Sakana positions Fugu as the antidote to single-provider reliance. Because it relies on a pool of “entirely swappable agents,” the idea is that Fugu is less likely to leave users in a bind if one provider suddenly restricts access. It can simply route work to other models. 

The AI company considers this capability enough license to claim it’s “delivering the realistic, resilient blueprint required for AI sovereignty.” But some initial reactions call that hyperbolic: 

“This is just a highly advanced router/wrapper, not a fundamental leap like Mythos/Fable was,” argues one Redditor.

Though it’s likely not fair to call Fugu a simple multi-model router, its ultimate reliance on other models means it’s not the hero for AI sovereignty it aspires to be. After all, if more than one model provider restricts access at the same time, Fugu’s capabilities also take a hit. 

As another user writes on HackerNews: “As a developer outside the US I think it’s vital to have alternatives to OpenAI and Anthropic, but sadly this is not it,” calling out what they describe as the tool’s unfortunate price-to-burn-rate ratio, an “extremely slow” API, and poor quality in comparison to Fable:

“It’s nowhere remotely near usable as a day-to-day workhorse.”

Not all user reviews back up the benchmarks

Sakana points to coding, reasoning, science, and agent benchmarks to prove Fugu’s value, stating its tool consistently beats Gemini 3.1, Opus 4.8, and GPT 5.5.

It also highlights what it says is the success of its beta program, where almost 500 early users tested Fugu on lengthy, multi-step computational workflows.

In particular, it claims that one cybersecurity engineer confirmed Fugu successfully operated within parameters and avoided destructive actions, while other teams praised Fugu Ultra for besting GPT 5.5 in code review and maintaining an “unusually strong persona stability across long sessions.”

But moving from benchmarks and PR-ready examples to early community sentiment adds more color to the story. 

One user on HackerNews calls Fugu “quite strong” for a few agentic coding tasks, but notes they weren’t able to do many deep reviews before their quota ran out, adding: “For implementation I found it weaker, it made a few mistakes that I haven’t seen frontier models make in a long time.” 

A Redditor had a different experience. They, too, bemoan burn rate issues, but note: “It caught things Opus 4.8 ultra and codex 5.5xhigh clearly missed in a fairly large data ingestion / processing project.”

Some users question the price tag

Furu is generally available today in most regions (save the EU) in two tiers: a low-latency model that integrates with chatbots and tools like Codex for daily tasks and Fugu Ultra, the heavy-hitter that coordinates a deeper pool of experts for more complex, high-stakes tasks. (This is the one that’s supposed to rival Fable 5 and Mythos Preview.)

Subscription plans are available at $20, $100, and $200 monthly rates for both Fugu and Fugu Ultra. Pay-as-you-go pricing is also available, with Fugu billed at standard rates per underlying model, and Fugu Ultra running at $5 per million input tokens and $30 per million output tokens, with higher rates when context exceeds 272k.

Several early users on Reddit and HackerNews deem these price tags too high, especially when they’re experiencing what now feels like the soundtrack of new agent tools: burn rates that get away from you too fast. 

As one HackerNews user jabs: “I love when they put a black box in front of the other black boxes so I can get a questionably better black box for slower service and more money!” 

Is collective intelligence the future? 

On X, HA posits that large-scale, monolithic models have had their time in the sun and that solving more complex real-world challenges will require a different beast: collective intelligence. 

Moving forward, Sakana plans to incorporate new models in its agent pool, which could shore up that resilience Sakana is aiming for. But so far, users seem to question whether paying another company to sit between them and frontier models is really worth the spend.

The post Sakana Fugu is more than a router. But it’s not the blueprint for AI sovereignty, either. appeared first on The New Stack.

Kubernetes teams automate deployments without thinking about it. CI/CD pipelines fire dozens of times a day, autoscaling adjusts replicas in the background, rollback is muscle memory. But there is one category of automation where that confidence vanishes: letting a system change CPU and memory requests on a running workload without a human reviewing it first. 

And as AI inference lands on Kubernetes at scale, that hesitation is becoming hard to ignore, and increasingly expensive.

Why teams trust automation for change but not for constraint

We surveyed 321 Kubernetes practitioners at enterprise organizations earlier this year. The headline finding is one most practitioners will recognize immediately: 82% report high or complete trust in automated delivery controls. But 71% still require human review before applying resource optimization recommendations. Only 27% allow CPU and memory changes to be auto-applied, even within guardrails.

“Deploying code feels additive… rightsizing feels subtractive because you are removing safety margin from a running service, and the failure mode is fundamentally different.”

Those numbers describe a specific asymmetry. The same engineers who deploy to production dozens of times a day without hesitation slow down the moment automation wants to adjust resource allocation. And the survey data make it clear why. Deploying code feels additive. You are shipping new value, the rollback path is well understood, and if something breaks you usually see it right away. Meanwhile, rightsizing feels subtractive because you are removing safety margin from a running service, and the failure mode is fundamentally different.

As one practitioner in the survey put it: “Automated right-sizing carries a unique risk because it directly impacts the underlying stability of the application runtime. Unlike a code deployment that follows a tested path, resource changes alter the invisible contract between the workload and the scheduler.”

When you change resource requests, you change how Kubernetes schedules, prioritizes, and allocates resources. Those effects are not visible the way a code change is. You can’t trace them through a deployment pipeline. And you might not discover that something went wrong until two weeks later, when a traffic spike hits a threshold that didn’t exist at the old values. By that point, three other things have changed too, and proving causation is nearly impossible. The people responsible for those workloads are the same people who get paged at 2 a.m., and they know this.

Why AI workloads raise the stakes

That trust gap existed before inference workloads showed up. What’s changed is the cost of not closing it.

For a long time, teams could absorb the cost of manual oversight. They knew their workloads, had intuition for where the safe boundaries were, and the inefficiency of over-provisioning was a price worth paying for stability. GPU-accelerated inference workloads change that math. GPU compute is significantly more expensive per hour than CPU. The cost of over-provisioning is no longer a rounding error you can absorb quietly. And the workload behavior is less familiar, as inference jobs are bursty in ways teams haven’t built intuition for, traffic patterns shift as models are updated and usage changes, and the resource dimensions involved differ from what teams have spent years learning to tune.

That unfamiliarity compounds with scale. Rightsizing isn’t a one-lever problem the way horizontal scaling is. It involves, at minimum, CPU and memory requests and potentially limits for both, with four dimensions per workload, multiplied across hundreds or thousands of workloads per cluster. The survey data indicates that manual optimization breaks down at around 250 changes a day. Inference workloads push teams past that threshold faster than anything they’ve managed before, because the resource decisions are more frequent and the cost of getting them wrong is higher.

The economic case for automated rightsizing has never been stronger. The organization’s willingness to delegate hasn’t caught up because teams are being asked to trust automation with workloads they don’t yet have a track record with.

What the survey says about closing the gap

When we asked practitioners what would actually increase their trust in optimization automation, 48% said visibility and transparency into how decisions are made, 25% wanted proven guardrails, and 23% needed instant rollback.

Nobody asked for full manual control and very few asked for blind autonomy. What they described is automation that earns trust in stages, and that’s consistent with how the teams furthest along in their automation journey actually got there. They didn’t start with production. They started with a single namespace in a dev environment, observed the system’s behavior, compared recommendations with outcomes, and gradually expanded the scope. Different environments remained at different levels of automation maturity simultaneously, and that was intentional. Production carried more scrutiny than dev.

CI/CD followed the same curve, and the timeline is easy to forget. Most organizations took years to get from running their first automated pipeline to trusting it with production deploys without manual approval on every commit. Kubernetes resource automation is earlier in that same process, and AI workloads are extending the timeline because teams are building trust from scratch with a workload category that doesn’t yet have a track record.

Why automation design matters as much as capability

Some automation architectures deliver meaningful value only with full delegation. The system needs complete control to function the way it was designed to. That’s a form of forced autonomy, and it creates an adoption problem because it asks for exactly the level of trust that most organizations haven’t built yet. Force generally doesn’t work. Teams that feel pushed into a level of delegation they aren’t comfortable with tend to pull back entirely after the first incident.

The alternative is what I’d describe as adaptive autonomy: designing the system to work at every stage of the trust curve. A team still evaluating gets useful recommendations in read-only mode. A team ready to act but wanting boundaries can run guardrailed execution within limits they define. As confidence grows, the system handles more decisions autonomously while humans manage exceptions. And for environments where the track record supports it, closed-loop optimization runs in the background and becomes boring, which is the goal. Each stage is a legitimate operating mode, not a stepping stone you have to rush through.

That design distinction matters more with AI workloads than it ever did with traditional services, precisely because the trust-building process is starting from zero on workloads where the cost of getting it wrong is highest.

“Trust takes a long time to build and a single production incident to undermine.”

The other piece that makes this sustainable is rollout safety. Trust takes a long time to build and a single production incident to undermine. Start with the workloads showing the most headroom between requests and actual usage. Make changes incrementally, small enough that a bad outcome stays contained. Rollback needs to be fast and tied to the health signals the team already monitors. And start with opt-in, not opt-out. Let the teams willing to go first build a track record that others can look at.

The broader pattern

The 71% figure is sometimes read as resistance to automation. I think it’s a more accurate picture of how operational trust actually forms: conditional, earned over time, and moving at different speeds depending on what’s at stake. AI workloads are raising those stakes significantly, which means the path to trusted automation matters more now than it did when the cost of caution was just some unused CPU.

“Most of what gets written about Kubernetes optimization focuses on tooling capability, and the tooling is capable. The harder problem is the human one.”

Most of what gets written about Kubernetes optimization focuses on tooling capability, and the tooling is capable. The harder problem is the human one. If your team is managing AI inference workloads on Kubernetes and your optimization tooling is sitting in read-only mode, the question worth asking isn’t whether to trust the system. It’s whether the system is designed to let you build that trust gradually, starting where the stakes are low and expanding as the evidence supports it, on workloads where getting it wrong costs more than it ever has before.

The post Kubernetes teams trust automation to ship code but not to touch CPU, and AI is raising the stakes appeared first on The New Stack.

For the past two years, the conversation about AI-assisted software development has been dominated by speed. A new GitLab survey of more than 1,500 developers and technology leaders found that 60% say AI coding ROI has already exceeded expectations, and 78% report their teams are writing and committing code faster since adopting AI tools. 

But speed without control is a liability.

Most organizations have pursued agentic engineering by adding AI coding tools on top of their existing infrastructure. Coding agents are delivering speed, but that speed isn’t showing up across the full software lifecycle: Only 21% of respondents report productivity gains beyond code generation itself.

“Speed without control is a liability.”

The infrastructure problem runs deeper. Git backends, toolchains, and governance frameworks were built for human-scale concurrency. Agents operate at machine scale, and that mismatch shows up fast. Platform reliability breaks down with millions of agent sessions hitting the same backend, security exposure widens as agents touch dependencies at scale, and cost overruns mount as agents consume tokens inefficiently on infrastructure that wasn’t built for them.

Agentic adoption outpaced governance

The adoption curve for AI coding tools outpaced the development of required guardrails, with 80% of organizations saying they adopted AI tools faster than they developed policies to govern them, and 82% reporting that AI-generated code risks creating a new form of technical debt that their organizations are not prepared to manage.

In practice, that means platform reliability challenges under agent load, security and compliance exposure that widens as agents touch dependencies at volume, and agents operating with artificial confidence because they lack full context. Only 28% of organizations say their software development lifecycle tools are fully integrated with shared data and workflows, which means most teams are trying to govern agent actions across a toolchain that was never designed for them.

Agentic engineering needs agentic infrastructure

Agentic engineering requires two things: agentic coding and agentic infrastructure. Most organizations have the first but lack the second.

Agentic infrastructure spans four areas: the execution layer, the context layer, the governance layer, and the orchestration layer working together.

The first is machine-scale execution. Git backends, CI/CD pipelines, and deployment systems were designed for human-paced development. In the agentic era, they need to handle millions of agent sessions without breaking. When a production incident occurs, the path from symptom back to origin should take minutes, not days.

The second is context that travels with code. As Bastian Stahmer, Business Owner of Vehicle Software Development Platform at Mercedes-Benz, put it on a panel recently, “An agent can only be as good as the context and semantics fed to it.” A context graph connecting code, work items, pipelines, security findings, and production signals is what makes agents genuinely useful at scale and keeps artificial confidence in check.

“An agent can only be as good as the context and semantics fed to it.”

The third is governance built into the flow. Agent actions need to be tied to an identity, logged against a policy, and provable to a reviewer. Low-risk changes move fast, while higher-risk changes trigger review. For Mercedes, operating under automotive regulatory standards that require full traceability and human accountability, GitLab is the control plane where that accountability lives.

The fourth is orchestration. Execution, context, and governance are only as effective as the system coordinating them. The orchestration layer coordinates agent actions across the full software lifecycle according to the policies teams define, determining which agents run, in what order, and how failures and handoffs are managed. Without it, agentic infrastructure is a set of independent capabilities rather than a working system.

What’s next

The next phase of AI in software will focus less on generating code and more on governing it, according to 85% of respondents. That shift reflects how enterprises are maturing their thinking about AI, from a productivity tool to a foundational capability that needs to be trusted, traced, and maintained at scale.

When governance is built into the platform, speed and control are no longer in tension. Traceability becomes a competitive advantage. Context becomes institutional memory. And the codebase, rather than accumulating invisible risk, becomes an asset that grows more reliable over time.

The post GitLab just surveyed 1,500 developers. Here’s why it matters for your codebase. appeared first on The New Stack.

The Linux Foundation on Tuesday declared its intent to launch the Agent Name Service (ANS), an open standard that gives AI agents verifiable identities by tying them to the internet’s domain name system (DNS).

The idea behind the ANS has actually been around for a while. It began as a research paper published in May 2025 by the OWASP GenAI Security Project, written by a group of application-security researchers. Its authors include Ken Huang, the CEO of security consultancy DistributedApps.ai and a co-author of the widely cited OWASP Top 10 for LLM Applications that chronicles the top security risks related to LLMs, and Akram Sheriff, an AI security engineer at Cisco.

ANS is a bit of a redesign of the original idea, which has gone through a few iterations since it was published. The 2025 original described ANS as a “universal directory” — basically a central registry with naming borrowed from DNS. A second version, published as an individual draft at the Internet Engineering Task Force in April, takes this a step further and ties each agent instead to a real domain its operator already controls.

How it would work

The design essentially copies how websites already prove who they are today. An operator demonstrates control of a domain like example.com through ACME, the automated protocol behind Let’s Encrypt, and a registration authority issues the agent a pair of certificates. Every change to the agent’s status, from registration to renewal to revocation, is written to an append-only log. A client checking an agent can choose how much assurance it wants, from a basic certificate check to a tier that also consults the log.

It’s worth noting that the ANS system separates identity from discovery and hands the job of finding agents to other services built on top.

The DNS industry and AI agents

Discovery is actually handled by DNS-AID, a separate discovery standard the foundation took in on May 27. It lets agents publish their endpoints as DNS records so other agents can find them. DNS-AID was originally built by Infoblox, and GoDaddy, which is also involved in ANS, is among its backers.

Agent identity and discovery projects based on DNS aren’t limited to these two Linux Foundation projects, though. Including those two, there are now at least four similar proposals. There is DNSid, for example, a durable-identity scheme from the registry operator Identity Digital, and AID, a minimal discovery draft that came out of the developer community.

Vineeth Sai Narajala, a co-author of ANS now with OWASP, says in the announcement, “we didn’t need to reinvent the wheel, we needed to extend the foundational trust of the internet to a new generation of autonomous technology.”

Not reinventing the wheel also means basing this system on the registrars and certificate authorities that come with it and the trust hierarchy they built, which security researchers have long considered fragile.

Maybe it’s no surprise that many agent identity and discovery solutions are coming out of the domain industry. GoDaddy, after all, registers domains, Identity Digital operates top-level domains, and Infoblox, which backs ANS, sells DNS infrastructure. For all of them, DNS-linked agent identity and discovery extends a (profitable) business they already run.

What about A2A and co.?

As is so often the case, the Linux Foundation is playing host to several alternative systems. Google’s A2A protocol, for example, gives agents a signed “Agent Card” they can publish at a known web address, with an agent registry on its roadmap. Cisco’s AGNTCY ships an agent directory and its own cryptographic identity service. Outside the foundation, Microsoft’s Entra Agent ID and Okta for AI Agents, both generally available since the spring, treat an agent as an identity managed inside the corporate directory, with short-lived tokens that tie each action back to the person who authorized it.

And while Cisco is backing both ANS and AGNTCY, some names are missing here, including major players like Google, Anthropic, Microsoft, and Amazon. Given their outsized role in the agent ecosystem, it’ll be interesting to see if they’ll join in this effort or decide on their own standards (insert obligatory xkcd comic here).

The post Can DNS become the basis for AI agent identity? appeared first on The New Stack.

How much of Nvidia is reflected by their visionary CEO, Jenson Huang? With his praise and later support of OpenClaw, Huang took a big step beyond the corporate boundary to embrace the “bad boy” of the agent world. Where exactly does Nvidia fit in here?

The New Stack put that question to Nader Khalil, Director of Developer Technologies at Nvidia, as well as how Nvidia is working with developers on agentic AI projects.

Khalil, co-founder of Brev.dev, found himself acquired by Nvidia about two years ago. His company helped startups access Nvidia AI chipsets. He is still excited by the possibilities of AI, and his energy is proof that Nvidia is enjoying the moment. Khalil was expansive, showing a startup’s keenness for the pace of change around them.

Before anything else, Khalil defines what he believes an agent is. “I have some slides,” he threatens. But these are more to organize his thoughts on an oft-asked question- not an attempt to lecture.

“An agent is an LLM and a harness… Each loop should take us closer to our goal.”

“An agent is an LLM and a harness. And if you think about that, it involves two things. It involves the loop and the LLM. And obviously you don’t want each loop to do the same thing. You want to leverage the results from the LLM. That might include reasoning on new tools to use. Each loop should take us closer to our goal.”

Nader praises the early OpenAI initiative. “So ChatGPT innovated outside of the model. It was not just a great model they made; they also added prompts. There was a system prompt and then the user prompt; there was multimodal, and suddenly that felt really good as a way for me to use the LLM. Every user could benefit from a system prompt that OpenAI had written while you were using your individual prompt.” Khalil continues, “Then they added memory.”

“Suddenly my assistant became really useful because it remembers things about me. ChatGPT knows that I really like to barbecue. So when I ask a question, it remembers what my smoker is,” recalls Khalil. “The thing that I was missing was files.”

Of course, the story continues through Cursor to Claude. “But this is the harness. Everything here is the harness,” he says.

Khalil moves on to how Nvidia works today. “The way to get your product into this rapidly growing market is with skills. Hence the CUDA X library.”

These are the implementations of use cases that target GPU acceleration, usually for compute-intensive applications.

“And so we look at every product we build now, it needs to have a skill because you need to cater to this growing audience,” he says.

This is how Nvidia first works with in-house experts, and connects to their edge hardware.

Supporting OpenClaw

Khalil was happy with the wording that Nvidia are “supporting” OpenClaw. “We’re just squarely in the community”, agrees Khalil. “We do this by the way, through a lot of projects that are very important in the open source ecosystem.”

But OpenClaw is not just any project and could be considered quite a risk to associate with. “We have a couple of developers at the company that contribute to OpenClaw full time.” Pushed on the nature of the relationship a little more, Khalil offers, “I think we just try to contribute wherever we can. I think what’s very clear is that harnesses had a moment, right?”

“We have a couple of developers at the company that contribute to OpenClaw full time.”

It has been quite a moment. “There is a lot of change happening right now, and we’re really thankful to [Peter Steinberger], OpenClaw, and the community for creating this moment around agents and harnesses. We of course want to contribute.”

Related to this, the OpenClaw project currently has many unresolved pull requests (PRs). In fact, there were rumors that new PRs are no longer accepted at all.

“We saw Peter tweeting about some of the issues they had, and we just rolled up our sleeves and were eager to help. They bless us by allowing our contributions.”

“You know,” says Khalil, “We saw Peter tweeting about some of the issues they had, and we just rolled up our sleeves and were eager to help. They bless us by allowing our contributions.”

Khalil reflects on things a little more: “You know the cardinal rule of code. It is easier to write than it is to read.”

And at over 800,000 lines of code, this must be true. Khalil continues, “It is easier not to have to process this complicated codebase, but every successful project right now has the same issue. It is easier to enlist many agents to help write code and build these PRs. The bottleneck is in merging the PRs through.” As well as dealing with the fallacies.

“OpenClaw was a major change for the industry. It was a huge moment, and everyone’s eyes are on it. It got more stars than Linux in months. Developers care deeply about the project because it was influential, and so I think you’re gonna see a mountain of PRs, right?”

“It got more stars than Linux in months… so I think you’re gonna see a mountain of PRs, right?”

Their attitude to OpenClaw is clearly to accept its problems, like that raucous friend who seems to wind up in police custody after a wild party, but is good at heart.

Blueprints and microwaves

Hermes is one of the newer projects in the wake of OpenClaw (like NanoClaw) that wants to bottle the lightning but in a safer way. Nvidia is also embracing it, but Khalil backs up to explain how Nvidia looks at projects in general.

“So, NemoClaw is our blueprint. When we see amazing harnesses, we try to figure out how we can help enterprises adopt them. Consumers sometimes want the security to run any agent; then there’s the model and harness. Then there are the skills, right. You have to give it access to your terminal.’

The term “blueprint” takes on a bit more formality in Nvidia, meaning the structure for building AI agents and systems. And of course Khalil needs to show these working with the Nemotron model and other Nvidia solutions.

“There’s a blueprint for Hermes and a blueprint for OpenClaw”. It sets up the runtime, enables the policies if there’s a local GPU, and runs the model.

Working with agents in the enterprise is seen as a significant risk. “There are a bunch of camps,” says Khalil. “There are teams within enterprises who are more worried. We have a project called OpenShell that is our security runtime and we’ll work with.”

“Our goal is to create the tooling that’s needed in the ecosystem. Developers in industry and enterprises have actually been adopting agents. And we have been building for this audience. One way to do so is to build a specialized agent or a sub-agent. “

So Nvidia doesn’t offer a big takeover solution, but fits in with where teams already are.

Your microwave, your agent

“The way to think about it is like when you use a microwave that you haven’t used before, you have to press a lot of buttons or spend time figuring it out. But when it’s your microwave at home, you just go ‘Boop, boop. Done.’ Right?”

“So every industry in enterprise will be building these specialized agents, and many already have. Nvidia is already working with CrowdStrike and Cadence, Palantir, among many others.”

The future will be agents

Khalil believes a lot of the concern over long-running agents is slowly petering out. Which leads to the final question: is Nvidia looking to stay in the open sea where there may be dragons, or become a calm port for developers to work in?

“So our approach is: Who can we help and how?” Khalil shows no fear, or lack of sea legs. “The inflection point happened months ago, so we ask what can we do to usher in all of this technology.” Here, Khalil ties his — and, to a degree, Nvidia’s — future to green-field developers.

“There are gonna be some people quick to adapt. And some people that aren’t; and what we’re noticing, if you look at the adoption curve, many people have yet to experience this. So there’s much work in helping make sure that we deliver this safely.”

The post “An agent is an LLM and a harness”: What Nvidia really thinks about OpenClaw appeared first on The New Stack.

The biggest news to emerge from the AI world this week was undoubtedly that Elon Musk’s SpaceX had agreed to acquire AI coding startup Cursor in an all-stock deal valued at $60 billion.

But on the very same day, at an invite-only developer conference hosted by Cursor in San Francisco, Tomas Reimers took to the stage to unveil a fledgling project that could prove just as consequential for the developer tools industry.

Origin, as it’s called, is a Git-compatible code-hosting platform designed from the ground up for a world where AI agents — rather than humans — do the bulk of the work.

Reimers, it’s worth noting, is co-founder of Graphite, a code-review startup that Cursor revealed it was acquiring back in December (a deal that apparently closed in January). At the time, some commentators noted the deal’s implications for GitHub — among them was Gergely Orosz.

Orosz, author of The Pragmatic Engineer newsletter and an investor in Graphite, who wrote on LinkedIn: “I’m telling you: GitHub’s biggest competitor could soon be Cursor. Graphite — in my view — is the best AI code review + stacked diffs + PR workflow product out there. GitHub is already playing catch-up to Cursor/Graphite.”

Put simply, Graphite had already built workflow tools that GitHub was scrambling to replicate — and with Cursor’s resources behind it, the gap was only going to widen. And now with the might of SpaceX, a $2.5 trillion company, behind it, things could be about to get very interesting.

The Origin origin story

On stage in San Francisco ahead of Origin’s unveiling, Reimers pointed to Graphite’s customer base — which includes Shopify, Snowflake, Notion, and Figma — as evidence of a problem already well underway before Origin existed.

“When we were acquired by Cursor, we accelerated our most ambitious project — to rebuild that tooling from scratch.”

“Over the past few years, we noticed the trend as these companies adopt AI tooling,” Reimers said. “The tools that they relied on started to become unreliable. That’s because over the past few years, AI tooling has totally changed our industry. It’s enabled every developer to be a 10 to 100x developer, but that change has required fundamentally different tooling. That’s why, when we were acquired by Cursor, we accelerated our most ambitious project — to rebuild that tooling from scratch.”

Amid all the hullaballoo of SpaceX hitting the public markets, becoming one of the world’s most valuable companies overnight, and doling out a cool $60 billion for a four-year-old startup, it’s easy to appreciate why Origin might have slipped under the radar. But the infrastructure problem it’s setting out to solve is real.

It’s easy to appreciate why Origin might have slipped under the radar. But the infrastructure problem it’s setting out to solve is real.

GitHub, the world’s dominant code hosting platform by some distance, is having a rough time of it. As The New Stack reported in June, the platform has logged hundreds of incidents over the past 12 months, struggling to keep pace with the volume of code that AI agents are generating. The company says it’s now processing about 1.4 billion commits per month — up from 1 billion across all of 2025 — with agents alone generating more than 17 million pull requests per month.

The irony isn’t lost on anyone: GitHub helped kickstart the AI coding era with the launch of Copilot in 2021, and it’s now buckling under the weight of it. And for some, the cracks are already showing in their day-to-day habits.

Brian Douglas, GitHub’s former director of developer advocacy who recently launched his own AI infrastructure startup called Paper Compute, tells The New Stack that the shift is already underway.

“Agents are quickly killing the will for doing open source.”

“Agents are quickly killing the will for doing open source,” Douglas says. “I’d love to see what GitHub’s [monthly active user] numbers look like today, because I am sure there are a number of folks choosing to do code reviews elsewhere — or exclusively collaborating with agents to get the work to the last mile — which is at an all-time high.”

Douglas, for what it’s worth, counts himself among them, saying he now does much of his review and PR work directly in AI coding tools.

“As a GitHub power user, I find myself using it less, and relying more on Claude and Codex for review and PR interactions,” he says.

A post-GitHub world?

Origin remains in waitlist-only mode ahead of a planned fall launch, and those present at Compile reported enough detail to sketch its ambitions. Developer advocate and independent commentator Shawn Wang Yuexian, known as swyx, described it as a “long-awaited Git competitor, scalable for agent workloads, extensible with API and MCP, and with built-in merge conflict and CI failure agent resolution.”

Whatever Origin looks like in its launch guise, it’s clear the appetite for an alternative to the status quo is growing. The software development world has changed considerably since GitHub popularized the pull request model back in 2008 — a feature that Douglas calls its “best ever.” But the pull request was designed for a world where humans deliberately wrote and reviewed code, one change at a time. That world is receding fast.

“Right now, the velocity of projects being created is overwhelming GitHub, and engineers are not looking at the code.”

“Right now, the velocity of projects being created is overwhelming GitHub, and engineers are not looking at the code,” Douglas says. “So if the goal is to put it in the cloud so agents are managing the code, I think that is absolutely an opportunity for disruption.”

So, as AI agents push code at a rate no human reviewer can keep up with, the pull request risks becoming a formality — a box to tick rather than a meaningful quality gate. Which raises a deeper question about how the industry should measure the value of software work at all.

For Douglas, the answer lies in a different unit entirely. Commits and lines of code — the traditional proxies for developer output — tell you little in a world where an agent can generate thousands of lines in seconds. Tokens, by contrast, map directly to compute cost and, therefore, to the real effort and value generated. It’s a reframing that suits Cursor rather well.

“Tokens are a better metric than commits.”

“Tokens are a better metric than commits,” Douglas says. “They align to a dollar spent that correlates to the effort of work. Previously, we pretended lines of code were the metric, and that was proven incorrect. But tokens plus agent sessions equals customer value — and Cursor is positioned well to own a deeper part of the collaboration stack.”

Cursor, though, isn’t alone in that conviction, and a slew of tangential efforts to rebuild that infrastructure for the agentic era are emerging.

At its Transcend conference in London on June 10, GitLab announced a private beta of what it calls Next Generation Source Code Management — known internally as Project Switch. Unveiled on stage by GitLab chief product and marketing officer Manav Khurana, the new backend keeps the Git protocol intact but redesigns the underlying architecture entirely, allowing agents to query repositories server-side rather than cloning them in full.

GitLab says it delivers up to 50 times faster task execution per agent, with up to 3 times fewer tokens consumed. And notably, Anthropic is a design partner on the project.

“The most popular Git platforms in the world are buckling under the load, not just because of your teams cloning, branching, and merging code, but also dozens, in some cases hundreds, of agents working simultaneously and putting a lot of pressure on those systems,” Khurana said.

The day after GitLab’s Transcend announcement, Zed co-founder Nathan Sobo published details of DeltaDB, a project the company had first teased the previous fall. A more radical proposition than either Origin or Project Switch, DeltaDB replaces Git’s commit-based model entirely with a continuous stream of fine-grained deltas — every operation an agent performs, linked directly to the conversation that produced it. Sobo confirmed that a beta version is just weeks away.

HashiCorp co-founder Mitchell Hashimoto, meanwhile, has seen this coming. Back in December, he wrote on X: “The AI companies are on track to become GitHub faster than GitHub is becoming an AI company.”

When Origin was announced this week, he retweeted himself with a single line: “Cursor announced Origin today. More will come.”

Hashimoto, as it happens, is an investor in another agent-native code hosting startup called East River Source Control (ERSC), which is building a Git-compatible platform designed to land thousands of commits per second.

The model is the moat

For Douglas, the convergence of competing efforts to rebuild version control from the ground up isn’t hugely surprising. In the past year, he points out, a similar dynamic played out with developer sandboxes — the environments where code gets written and tested — as companies like Docker, Cloudflare, and Vercel moved into that space because that’s where developers were spending their time.

The same gravitational pull is now acting on version control. The way developers work has changed fundamentally — where once they wrote code directly inside their editors, many now spend their time directing AI agents that do the writing for them. The IDE is no longer primarily a place to type; it’s increasingly a place to watch, review, and steer.

“I think all the folks who are part of the story have a shot, and we need to rethink our infrastructure to prepare for this.”

“Now, IDEs are suffering from the fact that developers have evolved to foundational model harnesses writing code, and they need to position themselves as the tool you open to watch agents write the code,” Douglas says. “I think all the folks who are part of the story have a shot, and we need to rethink our infrastructure to prepare for this.”

Underpinning all of this, though, is a commercial reality. Cursor has been building toward this position for some time, having launched its own first-party coding model, Composer, in 2025 and iterating on Composer 2.5 in May, giving it cheaper, in-house inference rather than relying entirely on costly API calls to Anthropic and OpenAI. Composer 2.5 costs a fraction of Claude Opus at equivalent tasks — as much as a tenfold difference on output tokens. Owning the model, in other words, is what makes owning the rest of the stack viable.

“It’s clear you can’t just insert an OpenAI key and expect hyper-growth or longevity in this market anymore,” Douglas says. “Instead, you need to own the model to win.”

Whether SpaceX’s firepower accelerates that ambition or complicates it remains to be seen. But the companies placing bets on the next era of software development aren’t waiting for GitHub to catch up.

The post Cursor, GitLab and Zed agree GitHub is breaking. They disagree on how to rebuild it. appeared first on The New Stack.

Inference is now the dominant force in enterprise AI — and with it has come an inconvenient reality: Data is almost always transported to compute. Every inference call moves sensitive enterprise information out of the systems where it lives and into external environments optimized for GPU throughput rather than data governance. This creates friction that compounds at scale: rising costs, expanding security exposure, and a growing tangle of data copies that drift out of sync with operational reality.

What enterprises actually want is different: to keep data and IP intact within the database rather than creating multiple copies and managing the resulting inconsistencies.

Research across more than 2,050 senior executives from major enterprises worldwide suggests that 95% of organizations intend to become their own AI and data platforms within the next 780 working days. Yet only 13% have successfully reached that goal. The organizations that have succeeded are achieving almost five times the return on investment of those still struggling to operationalize AI.

What separates the leaders from the followers is not model quality. It is infrastructure strategy.

The most successful organizations have adopted a sovereign-by-design approach. More than 75% are operating across multiple clouds and on-premises environments rather than relying on a single hyperscale provider. They are building AI around their own business, regulatory, and operational requirements rather than adapting those requirements to fit a cloud vendor’s architecture.

As AI moves from experimentation into production, CIOs are discovering that training models is relatively easy. Running them efficiently, securely and compliantly across thousands of operational workloads is where the real challenge begins.

The shift from training to inference

Training is a discrete event. Inference is an ongoing business process.

A model may be trained once, but it could be called millions of times each day. Every fraud assessment, insurance claim review, customer service interaction, medical recommendation, sanctions check, or predictive maintenance event relies on inference occurring against live operational data.

“What separates the leaders from the followers is not model quality. It is infrastructure strategy.”

This distinction fundamentally changes enterprise infrastructure requirements.

Training workloads prioritize compute density and GPU availability. Inference workloads prioritize latency, governance, reliability and cost control. They must operate where business data resides and where compliance requirements can be enforced.

For heavily regulated industries such as financial services, healthcare, telecommunications, energy and the public sector, inference cannot simply occur in whichever region offers the lowest compute cost. Data sovereignty requirements, audit obligations and security mandates often dictate exactly where workloads must execute.

The challenge therefore becomes much larger than AI itself. Organizations need an operating model capable of bringing together compute, data and governance without sacrificing flexibility.

Why neoclouds are emerging as a critical layer to cross the chasm to production

This is where neoclouds have become increasingly important.

Unlike traditional hyperscalers, neoclouds are purpose-built around AI infrastructure. Their focus is not delivering hundreds of generic cloud services but rather optimizing for GPU access, AI performance, and flexible consumption models.

For many enterprises, neoclouds offer a compelling answer to the growing demand for specialized AI compute. They provide access to the latest accelerator technologies while enabling organizations to scale workloads without the complexity often associated with large cloud environments.

“The future of AI architecture therefore depends on bringing models closer to data rather than moving data closer to models.”

However, neoclouds solve only one part of the enterprise AI equation.

AI does not create value in isolation. Models require context. They need access to customer records, transaction histories, operational workflows, policy documents, supply chain information and enterprise knowledge. Moving these assets into separate AI environments creates duplication, latency and governance challenges.

The future of AI architecture therefore depends on bringing models closer to data rather than moving data closer to models.

Why Postgres has become the enterprise AI foundation

As organizations look for a common platform that supports both operational and AI workloads, Postgres has emerged as a natural foundation.

Postgres already serves as the operational backbone for many of the world’s most important applications. It combines transactional reliability, extensibility, and scalability with the openness that enterprises increasingly demand. 70%+ of AI-related application development is happening on Postgres.  

What makes Postgres particularly relevant in the AI era is its ability to become more than a database. It can serve as a governed memory layer for AI systems, integrating operational data, application context, permissions, observability, and retrieval capabilities into a single architecture.

This dramatically reduces complexity.

Instead of maintaining separate infrastructures for transactional systems, vector stores, AI memory layers, and governance frameworks, organizations can consolidate around a trusted operational platform that already supports their mission-critical workloads.

For CIOs seeking to balance innovation with control, this architectural simplification represents a significant strategic advantage.

Why sovereignty matters more than ever

Sovereignty has become one of the defining themes of enterprise technology.

For banks, sovereignty means maintaining control over financial data and regulatory obligations. For healthcare organizations, it means protecting patient information while enabling innovation. For governments, it means ensuring national and citizen data remains under appropriate jurisdictional control.

The rise of AI has amplified these concerns.

Organizations increasingly need assurance that models, data, policies and operational controls can remain within designated environments while still benefiting from advances in AI technology.

This requirement is driving demand for sovereign AI architectures capable of operating across clouds, private infrastructure and on-premises environments.

The challenge is creating consistency across these environments without introducing operational complexity.

EDB Postgres AI: connecting sovereign data and sovereign AI

EDB Postgres AI addresses this challenge by bringing together operational Postgres, AI capabilities and hybrid infrastructure management into a unified platform.

Rather than forcing enterprises to choose between innovation and control, EDB Postgres AI enables organizations to deploy AI where their data already resides. Through capabilities spanning operational databases, analytics, agentic AI workloads and hybrid management, organizations can create a consistent operating model across sovereign environments.

This approach is particularly relevant for regulated industries where moving sensitive information into external AI services may introduce compliance, security or governance concerns.

By enabling inference close to operational data, organizations reduce data movement, improve performance, and strengthen their compliance posture. At the same time, they maintain the flexibility required to leverage emerging AI technologies and modern infrastructure models.

“By enabling inference close to operational data, organizations reduce data movement, improve performance, and strengthen their compliance posture.”

The result is a platform that aligns with the realities of enterprise AI rather than the assumptions of consumer AI.

“The reality is that the new AI at scale world needs a new infrastructure. That isn’t just the compute; it’s the governance, heuristic data access and level of observational and orchestration control that are absolute, governed, agile and work for humans and agents.”  Nancy Hensley, CPO, EDB

The new enterprise AI stack

The emerging enterprise AI architecture is increasingly built around complementary rather than competing technologies.

Together, these layers create an architecture capable of supporting the complete AI lifecycle—from experimentation and model training through production inference and continuous optimization.

The CIO imperative

The organizations realizing the greatest value from AI are no longer asking how to train better models. They are asking how to operationalize AI across the enterprise while maintaining control over cost, governance, and risk.

Their answer is increasingly consistent.

They are adopting multi-cloud and hybrid strategies rather than relying on a single cloud. They are prioritizing sovereign architectures rather than centralized data movement. They are building around open operational foundations rather than proprietary lock-in. Most importantly, they are recognizing that AI success depends on bringing intelligence to data, not data to intelligence.

Neoclouds provide the compute layer required for modern AI. Postgres provides the operational foundation required for trusted enterprise systems. EDB Postgres AI connects these worlds through a sovereign architecture designed for the realities of regulated industries.

As AI transitions from experimentation to operational necessity, the winning enterprises will be those that can make inference secure, governed, low-latency, and economically sustainable at scale.

In the next era of enterprise AI, the greatest business value will not come from model selection or raw GPU access. It will come from infrastructure strategy built around data — keeping intelligence close to where data already lives, governed, trusted, and ready to act.

The post Neoclouds, sovereign AI and Postgres: The new operating model for regulated enterprises appeared first on The New Stack.

For most of its 30-year history, Postgres has been viewed as a transactional database. Organizations trust it with customer records, financial transactions, and countless other operational workloads. Its reputation was built on reliability, strong transactional guarantees, and a vibrant open-source community that has spent decades refining the database without compromising its foundations.

However, some of the most important innovations in the Postgres ecosystem today have little to do with storing data. They have to do with reducing the need to move it around.

“Some of the most important innovations in the Postgres ecosystem today have little to do with storing data. They have to do with reducing the need to move it around.”

Database innovation has historically focused on performance, scalability, and reliability. Increasingly, the harder problem is interoperability: how operational data can be shared across analytical systems, AI applications, and downstream services without creating yet another pipeline or copy.

Why Postgres keeps showing up

The reality of modern software architecture is that data rarely stays in one place. Information created in operational systems quickly finds its way into warehouses, search platforms, machine learning environments, and AI applications. Every new system solves a legitimate business problem, but it also creates another destination for data and often another copy to maintain.

The costs of this approach extend beyond infrastructure spending alone. Every additional copy introduces latency, creates another potential source of inconsistency, and increases the operational burden of keeping systems synchronized. Many organizations now spend as much effort moving data as they do storing it.

“Many organizations now spend as much effort moving data as they do storing it.”

For many businesses, Postgres serves as the system of record for customer interactions, transactions, application state, and other business-critical information. As organizations expand their analytical, machine learning, and AI capabilities, they are not looking to create another source of truth; rather, they’re looking for better ways to work with the one they already trust.

That shift is changing how Postgres fits into modern architecture. Historically, Postgres was viewed primarily as the place where operational data originated before being copied into downstream systems. Increasingly, organizations want those systems to work more seamlessly with operational data while reducing the pipelines, copies, and synchronization processes required to support them.

Technologies such as logical replication, change data capture, and foreign data wrappers have helped Postgres participate more directly in larger data ecosystems. As a result, organizations are no longer asking only whether Postgres can store their data. They’re instead asking how easily it can connect to everything around it.

That shift, from evaluating databases primarily on storage and performance to evaluating them on interoperability, may be one of the most important changes happening in the Postgres ecosystem today.

AI is exposing old problems

The recent focus on AI has brought renewed attention to data movement. AI didn’t create the problem. If anything, it exposed a limitation that has been quietly growing for years. For decades, organizations built architectures around the idea that data would move between systems through pipelines and periodic synchronization. That model worked because most analytical workloads could tolerate some degree of delay.

AI is changing those expectations. Many AI applications depend on access to current operational context. The challenge is not that organizations lack data. In many cases, they already have it. The challenge is that the data is spread across multiple systems, each with its own copy, latency profile, and synchronization process.

“AI is forcing organizations to confront a broader question: How many copies of the same data are actually necessary? The answer increasingly appears to be fewer than most architectures maintain today.”

As a result, AI is forcing organizations to confront a broader question: How many copies of the same data are actually necessary? The answer increasingly appears to be fewer than most architectures maintain today. As expectations around freshness rise, reducing unnecessary data movement becomes just as important as accelerating it. The underlying challenge is not new. AI has simply made it harder to ignore.

What’s next

The database industry spent decades solving storage. Databases became more reliable, storage became cheaper, and infrastructure became dramatically easier to operate. The next challenge is not where data lives, but how easily it can be shared across systems without introducing additional pipelines, copies, and synchronization overhead. Increasingly, the goal is not simply moving data faster. It is reducing unnecessary movement altogether.

Postgres has a habit of outlasting predictions about its replacement. For years, members of the community have joked that every year is “the year of Postgres.” The joke works because it keeps turning out to be true. 

Three decades after its creation, Postgres continues to adapt to new workloads, new architectural patterns, and new ways of building applications.

That longevity is not an accident. Enterprises continue to rely on Postgres because it provides a stable and trusted foundation for operational data.  While that foundation is unlikely to change, the scope of what organizations expect Postgres to do will continue to expand.  

As new workloads continue to emerge, much of the innovation will come through extensions that expand Postgres’s capabilities without sacrificing the stability that made it successful. In that sense, the future of Postgres may not be about reinventing the database itself, but continuously expanding what can be built on top of it.

The post The database storage problem is solved. Here’s what comes next. appeared first on The New Stack.

AI consumes a lot of data, but all-you-can-eat data in the world of agentic intelligence eventually loses its flavor. Simply increasing the sheer volume of databases, data repositories and data volumes does not necessarily enrich any given AI function’s ability to reason. 

Context, on the other hand, does.

We know that agents are only as intelligent as the context they have access to. In order to codify the inclusion of context into algorithmic logic for AI, technology vendors have extolled the virtues of using a knowledge graph to make their data more useful for agentic purposes.

AWS knows this story all too well. The organization’s sprawling datacenter footprint hosts vast pools of context on behalf of its customers, but that context often sits in a raw and unstructured form across data lakes, data warehouses, data lakehouses, databases, and data streams. It also permeates through the rarely-documented institutional knowledge that agentic engines rarely get access to.

All of which explains why the cloud giant used its AWS New York Summit today to introduce AWS Context, a new service that automatically maps the relationships that exist across a firm’s existing data into a knowledge graph and provides agentic search so AI agents in the organization can access what are governed data relationships, business rules, and domain knowledge at runtime. 

But weaving all this together is hard work. Knowledge graphs need more than simple keyword matching to work; they require structural and semantic traversal. This means they need to make multiple hops across various information silos and repositories so that they can aggregate context and (for example) be able to explain why cybersecurity vulnerability A is a factor of system compromise B, which has a core dependency link to codebase C, which executes in application D and risks taking users X, Y and Z offline. So how is AWS doing this?

A data lake of nuance & information

Mai-Lan Tomsen Bukovec, AWS vice president of technology (data and analytics) tells The New Stack that AWS Context provides a “data lake of nuance and information that AI agents swim in” to reason correctly and make the right decisions for the business. 

“This is no different from how humans work. When we take action, we depend on our own context about the domain, prior decisions and their outcomes, and other information.” – Mai-Lan Tomsen Bukovec, AWS.

“This is no different from how humans work,” Tomsen Bukovec says. “When we take action, we depend on our own context about the domain, prior decisions and their outcomes, and other information. With AWS Context, AI agents have all the nuance of every form of data in their business in a knowledge graph and in open data formats. AWS Context will make the difference between an AI agent simply taking an action versus making the right decision.”

Given the option to embrace this new service, software engineers will need to set out a plan of action and work out what to do first. For AI developers and data science professionals, this throws up the question of what to prioritize first when preparing existing enterprise data for context-aware agents using AWS Context capabilities and how they can control what data is (and isn’t fed) into the mouth of the beast.

Mercifully, it appears, options for control appear to exist.

“If developers want to exclude information from AWS Context, they will have the ability to prevent certain datasets, like test data or sandbox environments, from being included with AWS Context,” explains Tomsen Bukovec. “Because AWS Context is continuously updated as relationships between data resources changes, AI agents have the latest context available without any intervention from AI developers – and the control to set guardrails to exclude content that agents should not take action upon.”

Should developers trust this technology?

AWS Context extends the same knowledge graph technology that runs Amazon Quick, the organization’s AI work assistant that “connects scattered work” across applications and resources, including Slack, Microsoft Teams and Outlook, CRMs, databases, and documents.

So, should software developers place their trust here? After all, even once captured and connected, not all business context is useful. Some contextualizations could be corrupted, weak, fragmented and not productively useful for the business? Is AWS at risk of encapsulating context without considering how the data that comprises it is is quantified in terms of business usefulness?  

AWS has thought of this factor.

Because AWS Context uses the same knowledge graph technology that powers Amazon Quick, it can learn from usage patterns to make every interaction smarter. With AWS Context, the company says it is extending what was a personal knowledge graph into an organizational one i.e. a shared, governed context layer that agents and applications in an organization can draw from.

“Developers can govern and shape a dynamic and intelligent context layer that AI agents depend on to make the right decisions – AI agents won’t just get smarter as the models improve – they will be smarter because they have a vast amount of curated context at their fingertips.” – Tomsen Bukovec.

“AWS Context provides a data lake of context in graph and open data format,” clarifies Tomsen Bukovec. “That means that AI developers everywhere can use capabilities at the data layer to govern and shape a dynamic and intelligent context layer that AI agents depend on to make the right decisions. With this change, AI agents won’t just get smarter as the models improve – they will be smarter because they have a vast amount of curated context at their fingertips.”

Curated knowledge beyond a user’s personal graph

Existing Amazon Quick users will see that when AWS Context is enabled, Quick’s agents gain access to the broader enterprise knowledge graph, including cross-system relationships, business rules, and curated context that go beyond what any single user’s personal graph can provide. 

Tomsen Bukovec has also said that AWS Context gets smarter the more agents use it. As agents query the graph, it observes which sources produce correct results, which join paths agents rely on, and which curated rules get applied. It ranks sources by actual usage and shares what it learns across an organization, so when one agent discovers a correct join path or resolves a schema ambiguity, other agents pick it up, without requiring a human to re-curate the graph.

Any agent you put into production raises a governance question: what data can it reach, and can you show exactly what it accessed and under whose authority? The organization has explained that AWS Context answers both by making every query identity-aware.

Each call is designed to inherit the calling user’s identity access management (IAM) and Lake Formation permissions, so an agent can only see and traverse the relationships its identity is authorized to access. Because access runs through identity, every interaction is auditable. Security and compliance teams can verify what an agent accessed and under what authority, using the same controls.

AWS Glue Data Catalog

Related news to the arrival of AWS Context today saw the company also announce the preview of business context and semantic search functions for AWS Glue Data Catalog, the company’s centralized metadata repository for all data assets across various data sources. The new functions are designed to make it easier for humans and AI agents to discover and understand data. 

Also in this product stream, AWS now offers offer a preview of skill assets in Glue Data Catalog, a service designed to allow “data producers” (a somewhat arbitrary term that AWS applies to anyone who creates data, but is most likely a DBA or developer) to create skill assets. 

Associating skill assets to data assets gives agents additional context and instructions they can retrieve progressively for working with specific data without re-teaching it to every agent one prompt at a time. 

A renaissance of context engineering

Will this new drive from AWS herald the birth (or perhaps renaissance, the industry has been talking about this approach for some time) of context engineering as a sub-discipline of data science? It may well do… and if it does, it will likely drag role-based multi-agent orchestration along into the fray with it as we weave ever more complex interrelationship structures through enterprise data stacks.

If AWS or indeed the other hyperscalers or major frontier model companies starts acquiring more multi-model graph structure companies and vector database specialists, that could be the sign that things are cementing around context engineering at large. 

In the meantime, developers setting sail on the contextualized data lake of nuance are advised to wear a life jacket.

The post “A data lake of nuance for AI agents to swim in”: AWS Context gets shipshape on reasoning  appeared first on The New Stack.

AI is already inside most enterprises’ IT stacks, but it’s had a somewhat shambolic and unsystematic early adolescence. Employees use personal tools, teams adopt different models, different company departments get forced into corners by vendors who push closed stacks, and agents are beginning to act inside systems that were built for people. 

That makes AI invisible, fragmented, and hard to change later. 

AI access and control platform company Tailscale announced on Tuesday the results of its work to address and redress these imbalances with new capabilities for Aperture, the company’s flagship toolset designed to provide a stable layer for managing AI across changing models, tools, data sources, and agents.

Designed to enable software developers to control and orchestrate the arguably almost too-dynamic state of AI, Aperture now offers a new chat interface, universal data connectors for both MCP and APIs, and sandbox support. 

What makes agents useful, also makes them risky

Avery Pennarun, CEO and co-founder of Tailscale tells The New Stack that the “same mechanics” that makes AI agents useful also make them risky i.e. they can do in seconds what would take a person dozens of clicks, commands, and context switches. 

But he advises that the risk factor here is not really a matter of pitting humans against agents and trying to place one above the other in terms of potential fragility. He says that the real risk is “giving any actor too much room” to act without clear boundaries.

“With agents, that risk moves faster,” Pennarun says. “With humans, the weak point is often the control model itself. If security depends on a developer approving a long stream of prompts, they will either get slowed down or hit approval fatigue and start approving things by reflex. That is not much of a security model.”

“Agents need boring infrastructure around them – robust identity management, limited access controls, carefully tracked logs, and sandboxes – that boring outer shell is what lets them do useful work without making every developer’s laptop the place where all the risk lands,” Avery Pennarun, Tailscale CEO.

Interestingly, agents need boring infrastructure

For Pennarun, the answer lies in making sure agents have what he calls “boring infrastructure around them”, by which he means robust identity management, limited access controls, carefully tracked logs, and (where necessary) sandboxes to execute in before they are exposed to mission-critical datasets, applications, or both.

“That boring outer shell is what lets them do useful work without making every developer’s laptop the place where all the risk lands,” Pennarun clarifies. “The answer is not agentic control or human control alone. Humans set the policy and boundaries up front. Infrastructure enforces them. Agents operate inside them.”

Aperture can be defined as a centralized AI gateway built to monitor and route LLM requests in a secure manner using Tailscale’s identity layer to automatically authenticate “users” (a cohort which we now obviously expand to include both humans and machines), eliminating the need to distribute API keys to authenticate with each AI model.

The gateway holds the API keys securely, meaning that when a developer (or a container) makes a request, Aperture verifies who they are via their Tailscale identity and then automatically routes requests to upstream LLM providers such as OpenAI, Anthropic, and Google without requiring changes to existing tools or workflows.

Yeah, we use AI, dunno where

Given the amount of work-related activity currently happening on personal and free AI accounts, we might suggest that concerns here are validated i.e. organizations today can not see, govern, or recover the information streams at this level. Research cited by Axios found companies typically have 67 generative AI tools running across their systems, with 90% lacking proper licensing or approval. 

Tailscale has reemphasized the fact that AI providers are bundling models, chat interfaces, data access, and execution environments into closed stacks. Those bundles can make the first deployment easier, but they can also leave organizations locked into one provider’s models, tools, and roadmap and pricing. In a market where model quality, speed, and cost keep changing, that lock-in can quickly become a disadvantage. 

“Aperture is built to give developers a practical way to manage AI without locking down their choices. It makes approved AI tools easier to use, connects them to internal data with identity preserved, and gives agents controlled environments to work in.”

“AI agents are also changing the risk model. They can write code, call tools, browse systems, manipulate files, and run commands. In many setups, they do that with the same permissions as the person running them, which can expose local files, credentials, and internal systems if something goes wrong,” said Pennarun and team.

What it means for developers: a controlled environment for agents to work in

Aperture is built to give developers a practical way to manage AI without locking down their choices. It makes approved AI tools easier to use, connects them to internal data with identity preserved, and gives agents controlled environments to work in. It also keeps the AI stack essentially modular, so teams can keep experimenting with new models, interfaces, tools, and providers without starting over.

The new chat interface is a browser-based way to use approved AI models through Aperture. The interface supports switching between configured LLM providers and works with Aperture data connectors and sandboxes. The universal data connectors help AI tools reach internal systems, documents, APIs, and operational data without forcing every team to build its own integration path.

Teams can use Aperture’s chat UI, coding agents, agent frameworks, or implement custom interfaces through OpenWebUI or LibreChat. Sandbox support (available in private alpha at the time of writing) is designed to give AI agents controlled environments where they can complete work without acting directly on a user’s laptop, workstation, or unmanaged system.

Aperture is designed to work with API keys from major LLM providers and with tools, agents, and interfaces that can be configured to route through Aperture. 

AI stacks inevitably, constantly and persistently change

With the frontier model race apparently unlikely to slow down any time soon, the fact that the best model, interface, sandbox, and data connection will all keep constantly changing… combined with the need to juggle these balls across multi-cloud deployment instances (poly-cloud even, where one app is split into different component parts across more than one hyperscaler), organizations looking to harness AI effectively and securely will surely face challenges. 

The central technology proposition with Tailscale Aperture is that it gives software developers a stable layer for identity, access, and control, so teams can keep changing tools without losing track of who is doing what.

The post “Agents need boring infrastructure around them”: Why we need to take an interest in ‘invisible’ AI appeared first on The New Stack.