top of page

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)

AgentCore Harness: Hands-On with Amazon Bedrock AgentCore

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


AWS Billing Inquiry Agent Architecture

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.


Bedrock Guardrail Configuration


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


Bedrock Guardrail Configuration
Bedrock Guardrail Configuration

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.


Lambda Setup for AgentCore Gateway
Lambda Setup for AgentCore 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.


Creating AgentCore Harness


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


Creating AgentCore Harness

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.


Creating AgentCore Harness

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.


Creating AgentCore Harness

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.

AWS FinOps Agent
AWS FinOps Agent

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

bottom of page