Building an AI Agent with AgentCore Harness (AgentCore Hands-On)
- Aug 5
- 4 min read
Updated: Aug 5
Building an AI Agent with AgentCore Harness(AgentCore Hands-On)

Written by Minhyeok Cha
Introduction
We're living in an era where AI seems to handle just about everything.
But honestly, until last year, the idea of "building an agent" still felt like a heavy lift. Even with AI-assisted workflows, getting a single PoC off the ground could easily take over a week.
Then in June, Amazon Bedrock AgentCore Harness went GA. The promise — "spin up an agent with no code, just a few clicks in the console" — sounded too good not to verify. So I decided to take it for a spin.
What I built is an AWS billing inquiry agent. As an MSP, we regularly get questions from customers like "Why is my bill so high this month?" It's a natural fit. (To be clear, this is a blog scenario, not my actual production workload.)
In this post, I'll walk through what AgentCore Harness is, connect Lambda functions via Gateway, and stand up an agent prototype in the console — all in the order I actually did it.
As a bonus, since security and data privacy are top of mind these days, I'll also wire up Guardrails for PII protection.
Table of Contents
What Is AgentCore Harness?
AgentCore is not a single monolithic service. It's a collection of individual building blocks — or primitives — such as Runtime (agent execution environment), Memory (state storage), Gateway (external tool integration), Identity (authentication), and Observability (monitoring). Each can be used independently, but that also means the burden of wiring them together falls squarely on the developer.
Harness is the layer that takes care of that wiring for you. It's a managed abstraction layer where you simply declare your model, system prompt, and tool list, and Harness automatically orchestrates all the underlying primitives into a working agent.
Before Harness, developers had to:
Write the reasoning loop — where the agent calls a tool, receives the result, and feeds it back into the next decision
Manually connect Memory logic — deciding when to save and when to retrieve context
Carefully tune prompts and parsing logic so the model would correctly select and invoke the tools exposed through Gateway
In other words, the "wiring" to make things actually work consumed a significant chunk of time, even for a single prototype. With Harness, you define the what — model, prompt, tools — and Harness handles the how internally.
Designing the AWS Billing Inquiry Agent

What Each Component Does
Inbound Auth (IAM in this post) The operator calls the chatbot with a JWT token issued by an OIDC provider such as Cognito. The Inbound Authorizer built into AgentCore Runtime/Gateway verifies the signature, issuer, and audience by looking up the public key via the discovery URL.
Outbound Auth (IAM in this post) Just before Lambda executes, the system verifies that data access stays within the scope of permissions delegated by the user (3LO, OAuth authorization code flow). Without this gate, a query from Customer A could inadvertently pull Customer B's data.
Guardrails — PII Check Bedrock Guardrails are linked to AgentCore policies and inspect inputs against approved agent actions. Prompt injection attempts and harmful content are filtered at this stage. Blocking before Lambda runs means there's no need to roll back a query that has already executed.
Gateway — Tool Integration When Harness determines that billing data needs to be retrieved, Gateway converts the Lambda function into an MCP (Model Context Protocol)-compatible tool and routes the actual execution.
MCP / API — Data Retrieval When AgentCore decides a tool call is needed, the flow moves down into the Gateway layer. Two tools are registered inside the Gateway.
Hands-On: From Guardrail to Harness
In this section, we'll walk through connecting the Gateway and Bedrock Guardrails to AgentCore Harness.
1. Bedrock Guardrail Configuration
Start by navigating to Bedrock in the AWS Console and selecting Guardrails from the left-hand menu.

For the billing agent, I configured billing-related topic filters and PII filters as shown below.


2. Lambda Setup for AgentCore Gateway
This post uses a billing-cost-management-mcp-server hosted as an MCP server and an AWS detect_cost_anomalies Lambda function.
As shown below, the MCP server and the pre-configured anomaly detection Lambda are connected to the Gateway.


3. Creating AgentCore Harness
For a detailed guide on attaching Bedrock Guardrails to AgentCore, refer to the following post:
Implementing Guardrails on AWS Bedrock AgentCore By:: John Walker · AWS Community Builders (dev.to) 🔗 https://dev.to/aws-builders/implementing-guardrails-on-aws-bedrock-agentcore-acj
In this post, we used create_guardrail to define three Guardrail policies (off-topic filtering / PII & financial data / prompt injection) and connected them via guardrailConfig during Harness creation.
Next, open the console and connect the Gateway you want to use with Harness.

Then navigate to the Harness Playground in the left-hand menu, select the agent you just created, and run a test.

When I asked about account costs, the agent routed the query through one of the targets configured in the Gateway and returned the billing data.
Next, let's verify that the Guardrails are working.

During testing, I noticed the agent was returning only a fixed output. After investigating, I found the issue: a Guardrail setting that I had left at its default value during creation.

If you plan to use Guardrails, make sure to review and adjust the policy and filter settings so that legitimate use cases aren't inadvertently blocked.
Wrap-Up
When AgentCore first launched, I was writing orchestration code by hand with the Strands Agents SDK, packaging it into containers, and deploying to Custom Runtime. Tool invocation, error handling — everything had to be explicitly coded. But after moving to AgentCore Harness, the orchestration code we'd written became unnecessary. Model selection, system prompts, tool connections — all configurable through the console.
Harness is excellent for building agents through configuration alone, without worrying about infrastructure. That said, wiring in Guardrails did require a bit of code.

P.S. Only after finishing this whole project did I discover that AWS has a beta service called FinOps Agent...







