Workday, the payroll and HR data platform, has been pursuing AI and agents for a while, but while other businesses may allow a little room for error, getting a payroll run in Workday 99% right is not exactly good enough.

Gabe Monroy, Workday’s chief technology officer, tells The New Stack that enterprise AI has to clear this bar before anyone will let it near their HR and finance data.

“There aren’t many systems that are more critical — or less forgiving — than ones that are dealing with people and money,” he says. There’s no tolerance for “well, it works most of the time,” Monroy says in an interview.

At its DevCon developer conference in early June, Workday laid out its plans to clear this correctness bar. The company introduced Agent-Ready Tools, a set of connectors that let agents act across the platform over the Model Context Protocol (MCP), a Developer Agent that lets people build apps and agents on Workday in plain language, and Agent Passport, which tests and verifies agents before they go into production and keeps monitoring them after, with Cisco as the first attestation partner.

Guardrails belong in the inference engine

Monroy spent most of his career in infrastructure and the developer space: at Deis, Microsoft, DigitalOcean, and, most recently, Google. At Google, he focused on building infrastructure for large AI labs to run inference at scale. For someone so focused on infrastructure, coming to Workday might seem a bit like an odd move, but Monroy argues that, at this point, LLM safety is — or at least should be — part of the core infrastructure for enterprises.

“The stakes are higher … in the world of people and money”

“The stakes are higher in the world of Workday and in the world of people and money, and that’s something that I was really excited about tackling at Workday specifically — and I do look at it as a core infrastructure,” he says. “A lot of what I’ve been doing in my recent past has been building infrastructure for large AI labs to do inferencing at scale, and what you pick up pretty quickly is that inferencing is probabilistic.

“[Inferencing] involves prefill and decode, and a whole bunch of really technical machinery in place to stream tokens out to end users, but what is nowhere in that stack today is the concept of native LLM-level enforced guardrails — guardrails that are part of the core inference.”

In his view, making it safe for enterprises to operate inference at scale has to be done at the inference engine layer. Agent gateways and similar add-ons that wrap the model from the outside sit at the wrong layer, he argues.

For a system of record like Workday, the system must strictly enforce guardrails on who the user is, what their budget authority is, and where they sit in the org chart. Those constraints, Monroy says, can be wired deep into the inference rather than checked after the fact. “These are things that we have the opportunity to wire deeply into the inferences at a very, very low level, in a way that produces much safer outcomes,” he says.

Workday’s recent acquisition of Pipedream partially plays into this. With Pipedream, an agent can reach out to third-party systems outside Workday to, for example, pull a policy document from Google Drive, and the platform can then verify that this specific agent has all necessary access rights to do so.

“Bring it to our shop”

All of those agents need to be managed, of course, and while many SaaS companies are currently building out their own agent platforms and agent orchestration services, seemingly all offering the same services, Monroy argues that orchestration should happen close to the data sources.

“If you’re trying to run an agent interaction that is integrating with people and money, that orchestration loop should probably happen closer to Workday, ideally on the Workday,” he says. “I do think there is something to be said for inference engines having proximity to the underlying system, because when it comes to a low-level inference engine and runtime perspective, there are some differentiated things you can do at the inference engine level that are only possible due to proximity to.”

“I do think there is something to be said for inference engines having proximity to the underlying system…”

He likened it to car repair. If somebody hands you a toolbox, you may or may not be able to fix your car’s problem. “Maybe you’ll get the outcome, but I tell you what, if you really want your car repair done right, bring it to our shop. We got the hydraulic lift, we got the trained engineers who know how to do this stuff, and we got the tools — but our tools are the best in the industry.”

For the part of an agent’s orchestration loop that has to run next to HR and finance data, “you really should be running that in our shop.”

For more general-purpose workflows, though, he believes there is room for general-purpose platforms. Not everything needs to run on Workday, after all, and Workday does offer MCP servers that third-party tools can tap into to access its data and tools as well.

To some degree, every system-of-record vendor is making some version of the proximity-and-context case right now. Owning the context for AI agents to work with is a major moat for these companies, after all, even as APIs and MCP servers allow agents to pull in data across vendors.

Meanwhile, there is also a group of other companies positioning themselves as neutral parties benefiting from the fact that these other vendors are now opening their platforms to third-party agents. It seems unlikely that, in the long run, enterprises will want to manage multiple agent platforms, but at this point, it is still far from clear in which direction this pendulum will swing.

Happy to lose the tooling fight

If proximity is where Workday thinks it can win, there is one area where the company doesn’t want to compete: developer tools.

“We’re not going to differentiate Workday on building better tools for developers,” Monroy says. “We’re going to differentiate on safety, on trust, on the inference engine.” It’s telling that the demos at DevCon ran on Claude Code, Cursor, OpenAI’s Codex, and Google’s Antigravity rather than on anything Workday-branded. “On the tooling front, I’m happy to have Claude Code and Codex and others,” he says.

It’s no secret that developer loyalty to AI tools doesn’t really exist at this point. Developers definitely don’t want a one-off tool from a single vendor, and Monroy notes that he isn’t going to ask them to adopt one. Instead, Workday wants to own skills, which he calls “the underlying lingua franca that we’re using to converge across the system.”

Workday is happy to be the system of record for its vertical and to let others fight over the tools.

The post “Bring it to our shop”: Workday’s pitch for keeping AI agents close to your most valuable data appeared first on The New Stack.

Okta has made its AI agent governance platform generally available for FedRAMP- and HIPAA-regulated environments, becoming what it claims is the first independent identity platform to extend AI agent lifecycle management inside the compliance boundaries federal agencies and healthcare organizations already trust.

The product, Okta for AI Agents – Core, elevates AI agents to first-class identities managed alongside human and machine workforces. This is a shift from the practice of treating agents as static service accounts or hardcoded API keys. The launch comes as federal agencies face mounting pressure from the recent executive order on AI innovation and security, which directs agencies to deploy AI agents and mandates that they secure them.

“The message to agencies is clear: Adopt AI aggressively, but secure it as you go,” writes Amy Johanek, Okta’s VP of Federal, in a blog post. “That puts identity at the center of the mission.”

“The fastest-growing class of NHI yet, and the hardest to see.”

Johanek also writes that AI agents are “the fastest-growing class of NHI [non-human identity] yet, and the hardest to see.” Anyone can spin one up, agents can spawn additional agents, and each connects across apps, APIs, SaaS tools, MCP servers, and data systems with little visibility, she says.

For organizations under mandates to harden systems and defend against AI-enabled criminal access, an unmanaged agent is not just an operational gap; it is more like an unguarded door, the company says.

“An unmanaged agent is not just an operational gap; it is more like an unguarded door.”

Johanek laid out four specific risks facing agencies running ungoverned agents: compliance violations when agents touch data outside authorized boundaries; compounding breach risk, where a single compromised credential doesn’t grant access to one system but to everything an agent can reach before a human can intervene; failed audits when agents run as orphaned accounts with no owner or evidence trail; and stalled AI adoption when delay becomes the only compliant option.

Moreover, the platform is organized around three governance questions: Where agents operate, what resources they can access, and what actions they’re authorized to take. Agents are registered in Okta’s Universal Directory inside an organization’s regulated cell, each assigned a unique identity and a named human owner, Johanek says. Every agent becomes a known, owned, first-class identity inside the environment, whether it came from a third-party platform or the organization’s own developers.

The platform replaces static credentials with scoped, short-lived tokens enforced at runtime. Least privilege is applied across authorization servers, third-party applications, and MCP servers. The governance layer mirrors existing federal workforce identity controls: access certifications, entitlement reviews, time-bound permissions, and a full audit logging stream that can be streamed to SIEM platforms for U.S. Government Accountability Office reporting requirements, Johanek says.

The offering also provides a kill switch

The offering also provides a kill switch. When an agent deviates from its intended mission or unexpectedly accesses sensitive data, security teams have a real-time mechanism to contain the risk before it escalates into a larger incident.

Johanek says she sees the offering as continuity rather than new infrastructure.  Agencies already trust Okta to manage human identities. Okta Identity Governance achieved FedRAMP High authorization earlier this year; bringing agents into that same identity fabric, she writes, is the natural next step, not a parallel system to build and defend.

However, there is one caveat: Okta for AI Agents – Core is not authorized in Okta for US Military cells.

The post Okta is the first to bring AI agent governance inside FedRAMP boundaries appeared first on The New Stack.

Over the past few months, four AI giants quietly rebuilt the same thing at once: AWS, Microsoft, Google, and Anthropic each shipped agent runtime updates that point to the same architectural shift.

Microsoft rebuilt its Foundry-hosted agents in April around per-session isolation. Anthropic’s Managed Agents virtualize the agent into a session, a harness, and a sandbox. AWS routes each session to its own microVM, and Google isolates agent code execution in a dedicated sandbox. The common pattern is not another model feature or developer tool. It is a move from request-level load balancing to session-aware execution.

This matters because enterprise agents are not ordinary API calls. They are long-running, stateful, tool-using processes that often run code influenced by user input. At its core, the agent runtime is becoming a control plane for state, identity, isolation, and lifecycle, and the unit it schedules has moved from the individual request to the agent session. The convergence across four platforms suggests session-aware execution is becoming a baseline requirement for production-grade agents.

The traditional cloud scaling model

To appreciate why this matters, it helps to start with what the traditional model got right. NGINX and HAProxy tiers typically sit in front of a pool of workers and route each incoming request to the next available backend. The state is deliberately kept elsewhere, in Redis or a database, so any worker can serve any request. That externalization of state is what enables elastic scaling, fault tolerance, and infrastructure replacement without disrupting the application. Sticky sessions were available, but enterprises treated them as an exception for stateful applications rather than the default.

The model rests on two assumptions: that requests do not depend on one another and that any backend can serve any request. For web APIs and microservices, those assumptions held for nearly two decades and enabled the scaling of the largest systems ever built. Agents challenge both at once, which is why conventional load balancing alone is no longer sufficient.

Why agents break the model

Agents pose two distinct challenges: preserving conversational state across turns and enforcing a security boundary strong enough to withstand untrusted code. Only the first can be addressed by routing alone.

Why can the agent state not be pooled?

Imagine an enterprise support agent processing a refund. It reads the order, calls a tool, and then waits for the model. The next turn asks a clarifying question. If that turn is routed to a different replica without access to the prior context, the agent loses the state it needs to finish the workflow.

The load balancer starts to behave less like a traffic distributor and more like a session router.

The industry already has a name for the workaround, session affinity, and it already concedes the cost. Load-balancing approaches increasingly rely on consistent hashing, using a conversation identifier to keep related steps in a warm state. In plain English, the load balancer starts to behave less like a traffic distributor and more like a session router.

Why the trust boundary forces isolation

The second challenge is harder because it turns on isolation rather than on the state alone. An agent can execute model-generated code shaped by user input, so the backend must be treated as a security boundary rather than a generic compute target. A shared kernel does not give untrusted, agent-generated code the tenant isolation that enterprise security teams require. Session affinity can preserve routing continuity, but it does not by itself provide per-tenant isolation for untrusted execution. For platform and security teams, that is the line where a tuned load balancer is no longer enough.

This is not a theoretical concern. When Asana disclosed a flaw in its MCP server in June 2025, the server had been live since May 1, a window of about five weeks. A tenant-isolation check failed, and around 1,000 organizations could see project data belonging to other customers. Based on the reported details, security researchers traced the issue to a server that validated the user but did not consistently enforce the agent and tenant context behind cached responses. No external attacker was involved, and data still crossed organizational boundaries. The incident shows why user identity, agent context, and session state must be consistently bound together.

The session as a unit of compute

Once that binding becomes a correctness and security requirement, the session becomes the unit that the platform schedules. The clearest evidence is in the lifecycle. A session now has a state it never had before. AWS documents that an AgentCore session remains Active while it processes work and sits Idle when it is provisioned but waiting. It reaches Terminated after a 15-minute idle timeout or an 8-hour maximum lifetime. That is the lifecycle of a long-running execution environment, not of a short-lived HTTP request.

The economics follow the same logic. When billing is tied to active sessions, concurrency, idle time, and agent sizing become the cost drivers rather than request volume. That puts a new line item in front of platform teams and finance. The better mental model is no longer a traditional load balancer. It is closer to a virtual actor runtime, where an addressable identity is instantiated on demand, kept active while it is needed, and deactivated when idle, with one live instance per key.

Four approaches to the same shift

All four platforms are moving away from treating stateful, untrusted agent work as ordinary load-balanced traffic. The key difference is the compute primitive each provider chooses for the isolated execution environment.

AWS AgentCore is the most opinionated of the four. Each session gets a dedicated Firecracker microVM with isolated compute, memory, and filesystem, and a request carrying the same runtimeSessionId is routed back to that microVM through a session header. When the session ends, the microVM is terminated and its memory sanitized.

The agents hosted on Microsoft Foundry implement a similar model through a different set of primitives. The platform creates a per-session VM-isolated sandbox on demand, runs it, and tears it down at session end, with no replica count and no warm pool to size. Each agent gets a dedicated Microsoft Entra identity, and sessions run a 15-minute idle timeout against a 30-day maximum lifetime.

Google Agent Engine is the most instructive hybrid. Its runtime keeps request scaling within the reasoning loop, a managed environment with configurable minimum and maximum instance counts, and a container_concurrency that defaults to 9. Even where Google retains request scaling for the loop, it separates untrusted code execution into an isolated Code Execution sandbox and externalizes conversation state to Sessions and Memory Bank. The provider that kept the load balancer in the loop still would not point it at stateful untrusted work.

Anthropic provides the clearest decomposition of the architecture. Managed Agents virtualize the agent into three components: a session that logs everything that happens, a harness that runs the loop and routes tool calls, and a sandbox where code runs. The harness becomes a near-stateless control plane, while the sandbox becomes a callable, rebuildable resource. The Cloudflare integration shows that the substrate can be decoupled. The agent loop runs on Anthropic while each tool call runs in a Cloudflare sandbox, which can be a full microVM or a lighter V8 isolate.

The four platforms converge on the routing and lifecycle model and diverge on the execution substrate, as the table shows.

No single architecture is the right answer for every enterprise workload. A multi-day research agent fits Azure’s longer-lived session, a code-heavy agent needs microVM-grade isolation, and high-volume automation favors a lighter isolate. Many enterprise platforms will end up combining more than one of these patterns.

The binding the application still owns

The platform can isolate and route a session, but it does not know which human owns it. AgentCore explicitly states that it does not enforce session-to-user mappings, so the application backend must maintain the relationship between users and their session IDs and set per-user session limits. This is why the Asana incident is relevant to enterprise architecture.

Isolation was maintained while the user-to-session binding broke.

In that case, isolation was maintained while the user-to-session binding broke. The platform solves isolation and lifecycle, and it hands back identity mapping, authorization, and tenant context to the application. For an enterprise buyer, the key question is who owns that binding and how it is tested under concurrent, multi-tenant load.

How this differs from sticky sessions

A reasonable objection is that this appears to be sticky sessions combined with autoscaling on a microVM substrate. The distinction is worth drawing out. Traditional sticky sessions are usually performance optimizations, whereas in an agent runtime, session binding becomes a correctness and security requirement. Traditional load balancers route traffic to existing backends and do not own the lifecycle of the execution environment.

The new control plane provisions an environment when it first sees a session key, routes work to it, and tears it down after idle or lifetime limits. The primitive underneath is genuinely old, and its age is what makes the move legible. AWS open-sourced Firecracker at re:Invent in 2018 to pair VM-grade isolation with container speed. I covered it for The New Stack then, and ran more than a hundred microVMs on a single laptop to see that trade firsthand. The same microVM now powers Lambda and Fargate across trillions of executions a month. This is how cloud architecture tends to evolve, with existing primitives recombined around a new unit of abstraction.

The agent session is becoming the operational unit of enterprise AI infrastructure.

In summary, the important shift is not that cloud providers have found a better load balancer for agents. It is that the agent session is becoming the operational unit of enterprise AI infrastructure. Traditional load balancing routed independent requests to interchangeable workers. A session-aware runtime routes work to an isolated environment, preserves state across turns, and owns the lifecycle of the execution context. The dispatch layer did not disappear when agents arrived. It became session-aware, stateful, and lifecycle-aware, making it a control plane rather than a conventional load balancer.

Three practical questions will shape what comes next, and enterprises will need to evaluate each. The economics of per-session billing will decide how costs scale with concurrency. The open-source effort to rebuild this routing model on Kubernetes will determine its portability. The argument between microVMs and lighter isolates will decide the trade-off between isolation and density. For enterprises building agents, a runtime that owns isolation, routing, and lifecycle turns background plumbing into a deliberate architectural choice. It gives platform, security, and operations teams a foundation they can standardize on rather than rebuild for every workload.

The post AWS, Microsoft, and Google agree the session is the new unit of compute. They disagree on how to isolate it. appeared first on The New Stack.

Many agentic projects can sail through development just fine. Then they hit security review — and that’s where things can grind to a halt. Unclear identity models and overly broad permissions quickly become blockers.

You’ve probably seen this play out: A customer support agent is working well; it triages tickets and processes refunds, handles the whole workflow without a hitch. Then security asks a simple question: Under whose identity is this running? The answer stops the process cold: It’s a shared account with broad permission, no clear ownership, no audit trail, and no least-privilege controls in sight.

The root issue isn’t complicated. It’s undefined identity and poorly scoped permissions. And that challenge is accelerating fast. Research from the 2026 Tech Leader Study, conducted with Oxford Economics and IBM, shows surveyed enterprises expect to deploy an average of 1,661 AI agents, a 38% increase from today. Each new agent introduces another identity to secure, and without clear boundaries, the problem compounds quickly. 

As a result, many agentic systems focus on what agents can do without defining what they should do, or under whose authority. Agents also don’t hold a fixed set of permissions. They request access, call new tools, and assume roles as they work, so access paths compound in ways no one explicitly granted or reviewed. Without a verifiable identity, there’s no accountability, making least-privilege enforcement, traceability and incident response difficult.

“Each new agent introduces another identity to secure, and without clear boundaries, the problem compounds quickly.”

To address these gaps, this guide is written for developers, architects and DevOps engineers building agentic systems — and for the IT leaders responsible for approving them.

The four identity decisions every agentic system must make

Identity decisions can’t be treated as an afterthought. Identity shapes how agents authenticate, what they can access, and how their actions are controlled and audited over time. Get it wrong early, and you’re building on a shaky foundation.

Here are the four decisions that matter most:

Workload identity vs. shared service accounts 

Shared service accounts are easy, and that’s exactly what makes them dangerous. When multiple agents act under a single identity, it becomes hard to tell what happened or what went wrong after the fact. If an account is leaked or misused, everything it touched is exposed. 

“Shared service accounts are easy, and that’s exactly what makes them dangerous.”

Workload identity assigns each agent its own identity. Permissions stay scoped, and actions are attributable. It requires more setup but creates isolation and auditability.

Static API keys vs. short-lived credentials

Static API keys tend to stick around forever. They get hardcoded into apps, passed around between systems, and rarely rotated — which makes them a persistent vulnerability waiting to be exploited. 

Short-lived credentials work differently. They’re issued on demand, scoped to a specific task, and expire automatically. In practice, this often relies on identity federation (for example, using OIDC tokens) combined with systems that can issue dynamic credentials at runtime, rather than storing long-lived secrets in code or configuration

Direct credential handoff vs. brokered session access

Handing credentials directly to an agent is simple. It’s also opaque. You don’t have a natural point to evaluate policy or understand what’s happening in real time. 

Brokered access introduces a control point into the flow. Requests go through a broker, policies are evaluated in real time, and temporary credentials are issued per session. It adds infrastructure, but restores visibility and policy enforcement. 

Fragmented logging vs. full identity lineage

Most systems log what happened. Far fewer capture who initiated it or how an action propagated through a chain of agents and services. 

Full identity lineage connects every step. You can trace an operation from triggers to outcomes, which can make debugging faster and enable more credible incident response. The catch is that this requires consistent identity propagation and structured logging from the beginning—it’s hard to retrofit.

When these tradeoffs become real risks

These aren’t abstract architectural preferences. They show up as concrete vulnerabilities.  

Nightfall AI reports that organizations expose nearly 350 secrets per 100 employees each year, with 35% of exposed API keys still active. Combine that with persistent credentials and shared identities, and the potential blast radius grows fast. 

The pattern is consistent: shared accounts and long-lived keys are faster to build but harder to secure. Workload identity and short-lived credentials require more upfront investment but can deliver more security over time.

Debugging breaches by feel

Think about what happens when an agent running on a shared account with a long-lived key suddenly spikes its data access. Was it a bug? A breach? Routine behavior? Hard to say. Revoking the key might stop the issue, but it could also break a half-dozen unrelated workflows in the process. You’re now debugging by feel. 

Shortcuts reduce friction at the start and accumulate risk over time. 

Standardize identity at the platform layer

The answer isn’t to rebuild authentication, authorization and auditing from scratch for every agent you ship. That’s not scalable. 

Instead, standardize identity at the platform layer—centralized identity providers, policy engines and a credential broker to enforce secure defaults and make compliance straightforward rather than a constant negotiation. 

“Shortcuts reduce friction at the start and accumulate risk over time.”

Agentic AI works in production when identity is designed up front and enforced at runtime, rather than assumed from a prior login. When projects are treated as an afterthought, they stall. When it’s built in deliberately, agents can operate with the control that production environments demand. 

IBM supports this through an integrated identity-first approach that spans secrets management, secured access, and identity governance—helping organizations scale agentic systems securely without adding operational complexity. 

Learn how IBM approaches identity-first security for agentic systems

© Copyright IBM Corporation 2026. IBM and the IBM logo are trademarks of IBM Corp., registered in many jurisdictions worldwide. Examples presented are illustrative only. Actual results will vary based on client configurations and conditions; therefore, general expected results cannot be provided.

The post The AI agent identity problem nobody’s talking about appeared first on The New Stack.

We’re more than 20 years past the launch of AWS, the starter gun for the shift of compute and storage from on-prem racks to the cloud. 

The rapid growth of AWS and competing services like Azure and Google Cloud underscores how many companies have made the jump from controlling their own infrastructure to renting capacity from hyperscale public clouds.

For the major providers, the public cloud has proved an incredible business. Amazon’s cloud service generated nearly 60% of its first-quarter operating profit, for example. For cloud customers, however, the tides may be turning.

Think back to the early days of the public cloud. Azure and AWS scrapped for market share, offering price cuts to entice workloads to their centralized silicon. The situation has evolved over the ensuing decades. Today, cloud costs are material and rising, prompting some companies to question whether being cloud-first is the best path forward.

Cloud bills are expanding due to increased usage of hyperscaler infrastructure, yes, but also because many customers today use the cloud for everything, rather than for what it is best suited for.

n the latest episode of The New Stack podcast, Byron Dill, Director of Solutions Engineering at Summit, tells us that shared compute and storage have their place in the modern IT mix, but that many companies would do well to segment their workloads and move some of that work back on-prem. (Think lower costs and simpler management of high-risk data.)

The argument echoes what we’ve seen recently in the AI realm. Many companies quickly adopted AI technology, only to be surprised later by the bills they incurred. The public cloud is a similar frog-boiler, albeit on a slightly longer timeframe.

In both cases — AI and the public cloud — companies have learned that a product once pitched as a way to reduce spend can evolve into the opposite without careful management. Summit, which offers managed private clouds to enterprise customers, thinks that some corporate workloads should be removed from the cloud and moved in-house.

What will that cost? How long does it take to move? And which industries are most primed to benefit from their own private cloud? We get into it all in this episode.

The post Public cloud vs. on-prem: Summit on where each workload belongs appeared first on The New Stack.

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.