I Deployed My First AgentCore Harness and Asked It About Production

My first CloudOps agent gave me the right answer by refusing to answer. I asked: Is production healthy? The agent said it could not verify the current state because it had no access to live infrastructure, deployment data, monitoring systems, or production environments. That was not a disappointing first result. It was the boundary I wanted to prove. This was Stage 1 of a larger project. The end goal is a small CloudOps agent that can answer the same question by calling a Lambda that only reads deployment status. Before adding that tool, I wanted to understand what Amazon Bedrock AgentCore gives me when the agent has only a model, a prompt, and a managed agent loop.

Why I Started with Harness

The AgentCore CLI currently offers two paths. I can bring an agent loop written with a framework such as Strands, or I can use a managed Harness. With the Harness, I declare the model, prompt, tools, and memory in configuration while AgentCore runs the loop. I chose Harness because I wanted the first experiment to isolate the managed platform - no custom orchestration code, no Lambda, no Gateway, no durable memory. The architecture was deliberately small:

AWS describes the managed Harness as the path where AgentCore runs the agent loop from configuration. The alternative gives the developer control of the loop in code. The distinction sounds simple in documentation, but deploying both the configuration and its infrastructure made it concrete.

The Boundary Was the Product

I named the Harness CloudOpsHarness and gave it a narrow system prompt:

You are a CloudOps assistant in an early learning stage. You currently have no access to live infrastructure, deployment data, monitoring systems, or production environments. Never claim that an environment is healthy or unhealthy without current tool evidence. Do not imply that you can deploy, roll back, restart, or modify resources. Those capabilities have not been provided.

Memory was disabled, and I configured no external tools. The key takeaway was the difference between local validation and infrastructure synthesis - both passed locally but the synthesis step revealed the real constraint.

The First Deployment Failed

Before It Reached AWS

My first Harness name was descriptive enough to become a problem. The physical name generated by the CLI combined the project and Harness names. That composed value exceeded the Harness name limit, so CDK synthesis failed. agentcore validate still said the project was valid because the local schema was valid, but the failure appeared when the infrastructure was synthesized. Shortening the resource name to CloudOpsHarness fixed it. That gave me the first useful lesson: a friendly logical name can become a longer physical name after a deployment system adds context. Local validation and infrastructure synthesis are different checks.

Next Dry Run Reached Another Boundary

The second dry run hit a different barrier: ✓ Synthesize CloudFormation but ✗ Check bootstrap status. AWS environment needs bootstrapping. I reran the dry run with permission to bootstrap the environment:

agentcore validate
agentcore deploy --dry-run --yes

This time the dry run completed and the stack was ready to deploy.

Model Access Was a Separate Failure Domain

The initial configuration used an Anthropic model. The Harness deployed, began producing the expected refusal, and then the Bedrock streaming call failed because the account had not submitted the details required for Anthropic model access. That was not an AgentCore hosting failure. It was a prerequisite for model access. For this learning stage, I changed the model to Amazon Nova Micro:

{
  "modelProvider": "bedrock",
  "modelId": "us.amazon.nova-micro-v1:0",
  "tools": [],
  "skills": [],
  "memory": {
    "enabled": false
  }
}

The next deployment completed successfully.

What AgentCore Dev Taught Me

I expected a command named dev to mean "run only on my machine." The managed Harness flow challenged that assumption. The command validated the project, synchronized CDK dependencies, built and synthesized the CDK project, checked AWS bootstrap and stack status, and persisted deployment state. The lesson was not that the command was wrong. The lesson was that names such as dev are not a security or cost boundary. I need to read the proposed actions and inspect status before assuming where something will run.

The Tests I Ran

Once the Harness was running with Nova, I tested the questions that mattered for this stage.

1. Can it admit that it does not know?
   When I asked whether production was healthy, it explained that it could not verify the environment without current operational evidence. It suggested signals such as application metrics, logs, health checks, database performance, and user feedback. That response passed the test. It did not turn general CloudOps knowledge into a fabricated observation.

2. Can a user talk it into a capability it does not have?
   I tried to override the prompt and also requested a production rollback. Neither test gave the assistant new infrastructure access.

3. Does a session behave like memory?
   A follow-up in the same session recognized that I had asked about production health before. A new session provided the comparison. That did not mean I had added AgentCore Memory. AgentCore Runtime sessions can preserve ephemeral context across invocations in one session. AgentCore Memory is the separate capability intended for structured information that must persist beyond that lifecycle. A remembered user preference may be useful - a remembered statement that production was healthy can become dangerously stale.

Finding the Trace

The Harness worked, but certain commands did not return results:

• agentcore traces list → No runtimes defined in agentcore.json
• agentcore logs --since 30m → Both returned: No runtimes defined in agentcore.json

The reason was visible in the project structure. The managed resource was declared under harnesses, while those CLI commands looked for configured runtimes. The Harness still had a backing Runtime log group in CloudWatch, but it simply was not discovered through that configuration path. I went to CloudWatch Logs directly and found standard Runtime logs plus OpenTelemetry output. At first, the trace exporter reported HTTP 400. CloudWatch Transaction Search had not finished enabling span ingestion. AWS documents Transaction Search as a setup that each account needs once to view AgentCore spans and traces. After its status changed to enabled, I invoked the Harness again and opened the trace in CloudWatch. The complete path was visible:

• The model span reported
• Cost was shown as $0.000 (rounded console value for one small invocation)

Seeing the root invocation, agent loop, event loop cycle, and model call in one timeline made the observability statement much more useful than reading it alone. AWS's AgentCore Observability guide states that agents hosted on Runtime receive automatic OpenTelemetry instrumentation through the CLI deployment path.

Cleaning Up

Without deleting the learning, I removed the AWS Harness and deployed that deletion. Then I restored the local Harness files so the experiment remained reproducible. The final check was:

AgentCore Status (target: us-east-2)

• Harnesses: CloudOpsHarness - Local only

That status is stronger evidence than a successful deletion command by itself. It says the CLI can still see the local definition but no deployed Harness for the selected target. The CDK bootstrap stack and CloudWatch evidence are separate resources with separate lifecycles. Removing the Harness does not mean the AWS account has returned to a completely untouched state.

Conclusion

The biggest lesson is that an agent can be correctly deployed and still be unable to answer the business question. That is not a prompt problem. It is an architecture problem.