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:
User
|
| prompt
v
AgentCore managed Harness
| CloudOps system prompt
| memory disabled
| no infrastructure tools configured by me
v
Amazon Nova Micro
|
v
CloudWatch logs, metrics, and traces
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. 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 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, 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.
The next dry run reached another boundary:
✓ Synthesize CloudFormation
✗ 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.
That distinction is going to matter later. A remembered user preference may be useful. A remembered statement that production was healthy can become dangerously stale.
Finding the Trace Was Its Own Experiment
The Harness worked, but these commands did not:
agentcore traces list
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. 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:
CloudWatch displayed the cost as $0.000. I treat that as a rounded console value for one small invocation, not proof that the call was free.
The same token attributes appeared on several parent spans. Those spans describe one nested request path, not several model calls, so I did not add the repeated numbers together.
AWS's AgentCore Observability guide says agents hosted on Runtime receive automatic OpenTelemetry instrumentation through the CLI deployment path. Seeing the root invocation, agent loop, event loop cycle, and model call in one timeline made that statement much more useful than reading it alone.
Cleaning Up Without Deleting the Learning
After the tests, I removed the AWS Harness and deployed that deletion. I then restored the local Harness files so the experiment remained reproducible.
The final check was:
AgentCore Status (target: default, 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.
Top comments (0)