Building an agentic app deployer with Amazon Bedrock and AWS Lambda

來源原標題

Building an agentic app deployer with Amazon Bedrock and AWS Lambda

作者

Ramesh Kadali

原始標籤

Advanced (300) · Amazon Bedrock · Amazon Nova

原始連結

https://aws.amazon.com/blogs/machine-learning/building-an-agentic-app-deployer-with-amazon-bedrock-and-aws-lambda/

摘要原文

Many enterprises have a long tail of internal tools that never get built. A team needs a shipping-cost calculator, a straightforward intake form, a small dashboard over a spreadsheet, but each one requires a developer, a backlog slot, and a deployment pipeline. The tools are too small to prioritize and too numerous to ignore. PDI Technologies serves the convenience retail and petroleum wholesale industries, helping businesses around the globe increase efficiency and profitability by securely connecting their data and operations. PDI has 40 years of experience, a workforce of approximately 4,000 employees, and serves over 200,000 customer locations across more than 200 countries and territories. PDI recognized that traditional deployment pipelines were blocking non-technical teams from shipping the tools they needed. To close that gap, PDI Technologies built PDI Brew. A non-technical employee describes the tool they want in plain English, and within seconds they receive a fully provisioned, multi-tenant web application, protected by single sign-on (SSO) and running on AWS. No Git, no terminals, and no DevOps knowledge required. The person who needs the tool is the person who ships it. Because every app inherits the same platform, each one can opt into a governed AI capability (chat, summarize, classify) backed by Amazon Bedrock . This occurs without its author ever touching a model endpoint or an API key. In this post, we show how PDI Technologies built PDI Brew around an agentic provisioning pattern . A planning agent captures user intent as a structured manifest using a skill inside an AI assistant (for example, Claude, ChatGPT, or Claude Code) or as an Amazon Bedrock model invocation inside an AWS trust boundary. A provisioning agent running on AWS Lambda then decomposes that manifest, classifying the workload, selecting tools, and orchestrating the creation of every downstream AWS resource in one request. We then show how the same platform exposes in-app AI as a governed, least-privilege gateway to Amazon Bedrock. We describe the architecture, the security model, long-running provisioning steps inside Lambda, the AI guardrail-and-budget design, and the cost profile of running this system at scale. To understand this architecture, familiarity with the following AWS services is helpful: AWS Lambda, Amazon API Gateway, Amazon DynamoDB, Amazon Simple Storage Service (Amazon S3), Amazon CloudFront, and Amazon Bedrock. Experience with Microsoft Entra ID (formerly Azure AD) and MSAL.js is useful for the authentication sections. Verify you have the AWS Command Line Interface (AWS CLI) installed and configured with credentials that have sufficient permissions to create AWS Identity and Access Management (IAM) roles and policies if you plan to implement a similar pattern in your own environment. Traditional internal-tool delivery couples a straightforward business need to a full software delivery lifecycle. Even a single-page calculator inherits the cost of a repository, a build pipeline, an authentication integration, a hosting decision, a TLS certificate, DNS, logging, and ongoing maintenance. The result is a permanent queue of small tools that are always deprioritized behind revenue-generating features. We wanted a system with four properties: “Agentic” does not need to mean “a large language model in the request path for every decision.” We define an agent as a system that takes a goal, decomposes it, selects tools, and acts toward that goal. PDI Brew separates the two halves of that definition into two agents with very different trust profiles. The planning agent captures intent. It interviews the user, helps them refine what they want, generates the application front end, and critically emits a structured deploy manifest: a JSON description of the user’s intent (app name, type, data schema, and access-control settings). The planning logic is packaged as the Vibe App Builder skill, which runs inside whatever AI assistant the employee already uses. Running the planner in the assistant gives users a rich conversational experience in a tool they already have open and keeps the surface area on the AWS side small. The provisioning agent is an AWS Lambda function. It receives the manifest and acts as a deterministic, auditable, tool-using orchestrator. It validates the request, classifies the workload, and chooses a provisioning path. It then calls AWS and Microsoft Graph APIs as tools, handles long-running steps through asynchronous self-invocation, and returns a live URL. Putting the provisioning logic in Lambda rather than in a chat session is deliberate: provisioning is exactly the kind of workload where every decision must be logged, reproducible, and free of hallucination. Intent can come from anywhere, so the planner is designed as a pluggable layer with two interchangeable paths. A single environment variable ( PLANNER_MODE ) selects which one is active, and both paths emit the identical deploy manifest, so everything downstream is unchanged. Path A — the Vibe Skill in any AI assistant. The Vibe App Builder skill (hereafter, the Vibe Skill) packages the planning logic and runs inside whatever AI assistant the employee already uses. The assistant interviews the user, generates the front end, and produces the manifest. The planner runs outside AWS, which gives users a rich conversational experience in a tool they already have open. Path B — Amazon Bedrock inside the AWS trust boundary. For channels like Teams, a web form, or an IDE, the request is sent to Amazon Bedrock. A Bedrock model invocation ( InvokeModel ) acts as the planner: it classifies the workload, emits the same manifest, and can validate or repair the data schema before provisioning. This path operates entirely inside AWS, so every decision is captured in AWS CloudTrail and tied to a model-invocation ID, and no intent data leaves the AWS boundary. This is important for teams with strict data-residency requirements. One contract, one provisioning agent. Because both planners emit the same manifest JSON, the provisioning agent on Lambda and the entire per-app runtime are identical regardless of path. Adding the Bedrock path was an additive change, not a rewrite. And PLANNER_MODE can be pinned per organization, workspace, or user, so one enterprise can require the Bedrock path while another keeps the in-assistant experience. It also leaves a clean forward path: the Bedrock invocation can later be replaced with a richer managed agent runtime without touching Path A or the provisioning agent. The following diagram illustrates the end-to-end architecture. It has three layers: a pluggable intent and planning layer, a unified agentic provisioning runtime, and a per-app runtime, supported by shared edge, identity, and observability services. The following walkthrough traces a request through each layer: The provisioning agent performs two core functions: classifying workloads and orchestrating long-running provisioning steps. The Deploy Lambda treats the AWS SDK for JavaScript v3 and the Microsoft Graph API as its tool belt. Based on the manifest, it decides which tools to call and in what order. A static app touches only S3, CloudFront, and the DynamoDB registry. A full-stack app additionally drives DynamoDB and API Gateway, and, for capability-bearing apps, Lambda and IAM. Access control reaches into Microsoft Graph to create and manage the app’s M365 group. The classification is deterministic and fully logged: the same manifest always produces the same plan. Some provisioning steps take longer than a user wants to wait on a synchronous request, notably directory propagation after creating an M365 group. Rather than hold the request open, the agent uses asynchronous self-invocation: it calls lambda:InvokeFunction on itself with an Event invocation type, returns the live URL immediately, and lets the background copy finish the slow work.