Build an Agent with Strands

Build a Strands agent with a custom tool, memory, and token comparison.

Introduction

30 Second Summary

A useful assistant needs to remember what came before. Connecting every supporting piece by hand can consume more time than testing the idea itself.

In this project, you will build an agent with the Strands harness. You will test its efficiency against a plain loop using token counts from your own runs.

What You'll Build

Your finished demo ends with a side-by-side token table comparing the agent run against your plain loop.

By the end of this project, you'll have:

A visible custom tool trace that proves your agent called a local function.
A context-dependent follow-up reply that proves the agent's memory carried information across turns.
A side-by-side token table showing your measured harness count beside the count from a plain loop.
Secret Mission: An optional challenge to push your agent engineering skills further.

What do I need for this project?

You need Python with pip installed.

You also need a key for a model provider.

Before We Start

The Strands harness runs on Python 3.10 or newer. Its model provider reads credentials from your terminal environment.

A known runtime gives every later run the same starting point. A protected credential keeps your key out of the scripts you compare.

In this step, get ready to:

Confirm that your Python version supports the harness.
Store an OpenAI API key in an environment variable.
Create the local directory for your agent comparison.

Check your Python version

The harness requires Python 3.10 or newer. A version check tells you whether your current runtime can load it.

Press Cmd+Space on macOS or the Windows key on Windows to open your search bar.
Type Terminal on macOS or PowerShell on Windows.
Press Enter to open the terminal.
Check your installed Python version using the command for your platform:

macOS

python3 --version

What does this command do?

The --version option prints the Python release attached to python3. This is the runtime that runs your project commands.

You should see output beginning with Python followed by a version number.

Windows

py --version

What does this command do?

The py launcher finds your installed Python runtime. The --version option prints its release number.

You should see output beginning with Python followed by a version number.

✔️ I see a supported version

Your Python runtime meets the harness requirement. That removes the first compatibility risk from your agent setup.

ⓧ I see an older version

Your terminal found Python. The installed release is below the required 3.10 version.

Open the official Python downloads page.
Download the current stable release for your operating system.
Run the downloaded installer.
Approve the operating system installation prompt if it appears.
Keep the standard installation options selected.
Close your current terminal after the installation finishes.
Open a fresh terminal through your operating system search bar.
Repeat the version check from the platform tab above.

Still seeing an older version?

Your terminal may still be resolving an earlier Python installation. On macOS, use the Python installer from the official downloads page without modifying the Apple-controlled system installation.

On Windows, confirm that the new runtime is available through the Python launcher.

Help me find why my terminal still uses an older Python version.

ⓧ Command not found

Your terminal cannot find a Python installation. Installing a current release adds the runtime you need for the harness.

Open the official Python downloads page.
Download the current stable release for your operating system.
Run the downloaded installer.
Approve the operating system installation prompt if it appears.
Keep the standard installation options selected.
Close your current terminal after the installation finishes.
Open a fresh terminal through your operating system search bar.
Repeat the version check from the platform tab above.

Python still unavailable?

A fresh terminal must load the updated command configuration. Restart your computer if the newly installed runtime still cannot be found.

Help me make Python available in my terminal.

Store the model provider key

OpenAI is a supported model provider for the Strands harness. The harness can read its credential from the OPENAI_API_KEY environment variable.

This credential deserves the same care as a password. The setup check reports only whether the key exists.

Open the OpenAI API key page.
Sign in to your OpenAI account.
Create a new secret API key on the API key page.
Copy the key when OpenAI reveals it.
Store the copied key in your password manager.
Load the key into your current terminal session using the instructions for your platform:

macOS

Replace your-api-key with the key you copied.
Set the environment variable and check its status by running:

export OPENAI_API_KEY="your-api-key"
python3 -c "print('OPENAI_API_KEY is set' if __import__('os').getenv('OPENAI_API_KEY') else 'OPENAI_API_KEY is missing')"

How is the key protected?

The first command stores the key in OPENAI_API_KEY for this terminal session. The second command checks the variable without printing its value.

You should see OPENAI_API_KEY is set in the terminal.

Seeing the missing message?

Check that you replaced the placeholder inside the quotation marks. Keep the terminal open because this environment variable belongs to the current session.

Help me set OPENAI_API_KEY safely on macOS.

Windows

Replace your-api-key with the key you copied.
Set the environment variable and check its status by running:

$env:OPENAI_API_KEY="your-api-key"
py -c "print('OPENAI_API_KEY is set' if __import__('os').getenv('OPENAI_API_KEY') else 'OPENAI_API_KEY is missing')"

How is the key protected?

The first command stores the key in OPENAI_API_KEY for this PowerShell session. The second command checks the variable without printing its value.

You should see OPENAI_API_KEY is set in PowerShell.

Seeing the missing message?

Check that you replaced the placeholder inside the quotation marks. Keep PowerShell open because this environment variable belongs to the current session.

Help me set OPENAI_API_KEY safely in PowerShell.

Create the project directory

A dedicated directory keeps every project artifact in one place. The same terminal carries your API key into the commands you run later.

Create the strands-agent-comparison directory on your Desktop using the commands for your platform:

macOS

cd ~/Desktop
mkdir strands-agent-comparison
cd strands-agent-comparison

What do these commands do?

The first command moves your terminal to the Desktop.
The second command creates the strands-agent-comparison directory.
The final command makes that directory your current location.

Windows

Set-Location -Path "$HOME\Desktop"
New-Item -Path "strands-agent-comparison" -ItemType Directory
Set-Location -Path "strands-agent-comparison"

What do these commands do?

The first command moves PowerShell to the Desktop.
The second command creates the strands-agent-comparison directory.
The final command makes that directory your current location.

Before you run the final check, do you expect the runtime, credential status, and current directory to agree with the setup you just completed?

Verify the complete local environment using the command for your platform:

macOS

python3 --version
python3 -c "print('OPENAI_API_KEY is set' if __import__('os').getenv('OPENAI_API_KEY') else 'OPENAI_API_KEY is missing')"
pwd

What does this check prove?

The first line confirms the Python runtime available to your project.
The second line confirms that the provider key exists without revealing it.
The final line prints the directory that receives your project files.

You should see Python 3.10 or newer. You should also see a key status followed by a path ending in strands-agent-comparison.

One of the checks failed?

Use the failed line to locate the gap. Repeat the matching substep before running this final check again.

Help me diagnose my macOS environment check.

Windows

py --version
py -c "print('OPENAI_API_KEY is set' if __import__('os').getenv('OPENAI_API_KEY') else 'OPENAI_API_KEY is missing')"
Get-Location

What does this check prove?

The first line confirms the Python runtime available to your project.
The second line confirms that the provider key exists without revealing it.
The final line prints the directory that receives your project files.

You should see Python 3.10 or newer. You should also see a key status followed by a path ending in strands-agent-comparison.

One of the checks failed?

Use the failed line to locate the gap. Repeat the matching substep before running this final check again.

Help me diagnose my Windows environment check.

Your local environment is ready for the first agent run. Next, you'll install the Strands harness and ask your agent its first question.

Install and Run the Harness

A working agent starts with a reliable connection to its model. This step proves that connection before you add tools or test memory.

The Strands harness assembles the agent loop, tools, memory, and context handling through create_harness(). In this walkthrough, OpenAI is the model provider because its API key is already available in your environment.

In this step, get ready to:

Install the Strands harness package in your project environment.
Create an agent that uses the configured OpenAI model.
Run one question to confirm the model returns an answer.

Install the Strands harness

A Python package makes the harness importable from your script. The existing terminal is already inside your local project directory.

Install the package in the project environment by running this command:

pip install strands-harness

What does this command do?

The pip command adds the published strands-harness package to the Python environment associated with this terminal. That package exposes create_harness() to your script.

When the installation completes, your terminal returns to its prompt without reporting a dependency failure. That setup hurdle is cleared. The harness code is now available to your project.

Harness installation failed?

Confirm that pip is attached to the Python environment used by this project.
Retry the installation after restoring network access if the package download stopped.

Help me fix the harness installation

Create and run the first agent

A provider selector tells the harness which model service to call. The openai/gpt-5.4 selector uses the key already stored under OPENAI_API_KEY in your environment.

Your secret stays in the environment. Nothing in the script stores the key.

Launch your usual code editor from your operating system's application search.
Select the local project directory already open in your terminal by using the editor's folder picker.
Create agent_comparison.py inside that directory by using the editor's file sidebar.

You should see agent_comparison.py in the editor's file sidebar.

Add the first harness agent to agent_comparison.py by pasting this code:

# Load the factory that assembles the harness
from strands_harness import create_harness

# Use OpenAI through the key already stored in the environment
agent = create_harness(model="openai/gpt-5.4")

# Ask one question and print the returned answer
answer = agent("My project codename is Atlas. Confirm it in one short sentence.")
print(answer)

What does this code do?

The create_harness() factory assembles the agent with the harness defaults.
The model value connects the agent to the selected OpenAI model.
The answer variable holds the result returned by the model.
The print(answer) call writes that result to your terminal.

Save agent_comparison.py with your editor's save control.

✔️ Awesome, I've got everything!

Your saved agent_comparison.py file is ready for its first run.

ⓧ I'd like to double check the full code

The complete file should look like this:

# Load the factory that assembles the harness
from strands_harness import create_harness

# Use OpenAI through the key already stored in the environment
agent = create_harness(model="openai/gpt-5.4")

# Ask one question and print the returned answer
answer = agent("My project codename is Atlas. Confirm it in one short sentence.")
print(answer)

This run makes one model request against your provider balance. The short prompt keeps this first check small.

Before you run the script, what kind of sentence do you expect the agent to return? Hold that prediction.

Run the saved agent script from the existing terminal by using this command:

python -u agent_comparison.py

What happens when this runs?

The python -u command runs the saved script with terminal output shown as it arrives.
The create_harness() call constructs the agent before the request begins.
The agent(...) call sends the initial question to the configured model.
The print(answer) call displays the returned response.

You should see a short sentence confirming that the project codename is Atlas. That first response proves your script can reach the model through the harness.

Agent did not return an answer?

Confirm that OPENAI_API_KEY remains available in the terminal session running the script.
Confirm that the model selector in agent_comparison.py matches openai/gpt-5.4.
Repeat the earlier package installation if Python cannot import the harness.

Help me troubleshoot the first harness run

Your harness can now reach a live model. Next, you'll add a local function as its first custom tool.

Add a Custom Tool

Your Strands Agents script already reaches your chosen model. Now you will give that agent a local capability it can call when a prompt needs a precise calculation.

A normal answer proves that the model can respond. An execution trace proves whether the agent called your code to produce that answer.

In this step, get ready to:

Define a local Python function as a custom tool.
Register the function with your existing agent.
Run a tool-dependent prompt to confirm the call in the trace.

Define a local tool

The @tool decorator turns a Python function into a function the agent can choose. Its docstring describes the capability to the model.

Return to agent_comparison.py from the previous step.
Place your cursor below the existing import section.
Add this tool definition before the existing agent construction:

from strands import tool

# Turn a deterministic Python function into an agent tool
@tool
def word_count(text: str) -> int:
    """Count words in text.

    This docstring is used by the LLM to understand the tool's purpose.
    """
    return len(text.split())

What does this code do?

The @tool decorator exposes word_count as a capability the agent can call.
The docstring tells the model when the function is useful.
The str and int type hints define the expected input and output.
The function splits the supplied text into words before returning the count.

Save agent_comparison.py.
Rerun agent_comparison.py with the same Python command from the previous step.

You should see the initial model answer complete successfully. That's a steady first win: your existing model path still works with the local function present.

Seeing a Python error?

Check that from strands import tool sits outside the function. Confirm that @tool appears directly above word_count.

Compare the indentation inside the function with the code block above.

Help me fix my custom tool definition

Register the tool

A decorated function becomes available to the model after the agent receives it in its tool list. The existing model configuration stays responsible for provider access.

This one-line change can feel fiddly because your constructor already contains provider-specific settings. You will leave those settings untouched.

In agent_comparison.py, locate the existing Agent(...) construction that uses your configured model.
Add tools=[word_count] as a keyword argument inside that constructor.
Separate the new argument from the existing model argument with a comma.
Keep every existing model-provider argument unchanged.
Save agent_comparison.py.
Rerun the script with the same Python command from the previous step.

You should see the initial model answer complete successfully. You kept your provider setup intact while giving the agent a callable tool.

Does the agent fail during startup?

Confirm that word_count is defined before the Agent(...) construction. Check that tools=[word_count] sits inside the constructor's parentheses.

Help me check my tool registration

Run and inspect the trace

The model chooses whether a prompt needs a registered tool. A word-counting question gives it a clear reason to call word_count.

Move to the line below the existing initial question and answer output in agent_comparison.py.
Add the tool-dependent prompt and trace output with this code:

# Ask a question whose answer requires the custom tool
tool_result = agent("How many words are in this sentence?")

# Print the answer and the local execution trace
print(f"\nTool answer: {tool_result}")
print("\nTool trace:")
print(tool_result.metrics.get_summary())

What happens during this run?

The prompt asks for a deterministic result that word_count can calculate.
The returned result contains the model answer plus execution metrics.
The get_summary() call exposes the cycles and tool usage recorded during the run.

Save agent_comparison.py.

✔️ Awesome, I've got everything!

Your local function is defined before the agent. The agent now receives that function through its tool list.

ⓧ I'd like to double check the full code

Confirm that agent_comparison.py contains these sections in order:

Keep the existing provider imports and model configuration unchanged.
Place from strands import tool with the imports.
Define the decorated word_count function before creating the agent.
Keep the configured model in Agent(...) with tools=[word_count] added.
Keep the initial question from the previous step before the new tool-dependent prompt.
Print tool_result before printing its metrics summary.

Before you rerun the script, do you think the agent will answer directly or call word_count first?

Rerun agent_comparison.py with the same Python command from the previous step.

You should see Tool #1: word_count in the streamed output. The tool answer should report seven words.

The summary should also include word_count under tool_usage. That's the tool path working: your terminal now proves that the agent called your local function.

Missing word_count from the trace?

Confirm that the agent's tool list contains word_count. Check that the prompt exactly asks for a word count.

Make sure you print the metrics from tool_result. Printing metrics from the initial question shows the wrong run.

Help me trace the missing tool call

Your agent can now choose a local function and expose evidence of that call. Next up, you will test whether the same agent remembers context across turns.

Test Memory Across Turns

Your agent built with the Strands Agents harness can already call a local custom tool when a prompt needs it. Now you'll test whether that same agent carries context into a later turn.

A useful memory check leaves a key detail out of the follow-up. The reply must recover that detail from the earlier exchange.

In this step, get ready to:

Choose an earlier detail for your memory test.
Send a context-dependent follow-up to the same agent instance.
Run the script to confirm that the reply retains context.

Choose a detail to test

The follow-up needs information from an earlier turn to prove that the conversation carried forward. Choose a detail that the agent stated clearly in its initial reply.

Return to the terminal output from the earlier run.
Choose one concrete detail from the initial reply.
Form a follow-up question that relies on that detail without repeating it.

Why omit the detail?

A follow-up that repeats the detail gives the agent everything it needs in the current prompt. Omitting that detail makes the earlier exchange necessary.

Send the follow-up through the same agent

The existing agent instance already holds the conversation you want to test. The follow-up must pass through that instance to stay on the same conversational path.

In agent_comparison.py, locate the statement that sends the tool-dependent prompt through the existing agent instance.
Append a new question-and-print pattern below that statement with your checkpoint follow-up as its prompt.
Save agent_comparison.py.

✔️ Awesome, I've got everything!

Your follow-up now uses the existing agent instance. Double check that you saved agent_comparison.py.

ⓧ I'd like to double check the full code

Compare your complete agent_comparison.py file with this final structure.

The script imports the Strands harness.
One configured agent instance handles every prompt.
The initial question sends through that instance before its answer is printed.
The local custom tool remains registered with the agent.
The tool-dependent prompt still produces trace output confirming the tool call.
The context-dependent follow-up sends through the same instance before its reply is printed.

Before you run the script, do you think the follow-up can recover the missing detail from the earlier turn?

Switch back to the terminal from earlier.
Rerun agent_comparison.py with the same terminal command you used in the previous step.

You'll see the earlier answer before the tool call trace.

The new follow-up reply appears last. It should use your chosen detail even though the follow-up omitted it.

That is a meaningful result. Your single agent instance carried context into a later turn.

Follow-up ignores the earlier detail?

Check that the follow-up call uses the same agent instance as the initial call.
Confirm that the initial reply states your chosen detail explicitly.
Strengthen the follow-up so its answer cannot be guessed from the current prompt alone.

Ask for help with the test using help me debug my agent memory test.

Your agent can now call a tool while carrying context across turns. Next, you'll print its token usage for a measured comparison.

Measure Both Token Counts

Your Strands Agents harness can now call the local tool. It also remembers the context behind a follow-up question.

Now you need evidence from its token usage. A fair comparison keeps the task identical while changing only the orchestration layer.

In this step, get ready to:

Read the harness usage from the completed run.
Run the same task through a plain model-call loop.
Confirm that the terminal prints both token totals.

Capture the harness usage

The harness returns usage information after the agent finishes its task. Your report turns that information into one labeled total that you can compare.

Add a harness usage report to agent_comparison.py after the existing tool-dependent run.
Save agent_comparison.py.

Run agent_comparison.py again using the same Python 3 command from earlier.

You should see a labeled harness token total after the existing trace output. Good. Your harness run now produces a measurement from your own task.

What does the harness total represent?

The total comes from the usage information attached to the completed harness run. It captures the model activity required to finish that task.

Keep this value tied to the exact task prompt. Changing the prompt creates a different experiment.

Harness usage missing?

Confirm that the report reads the result returned by the completed agent call. Confirm that the report runs after the call finishes.

Check that the report uses the usage information from the tool-dependent run. An earlier question measures a different task.

Help me trace the missing harness usage

Build the plain comparison loop

A plain loop makes the orchestration visible. Your code owns the message history plus each model call.

What makes the baseline comparable?

The baseline starts with a fresh message history.
The baseline submits the exact task prompt used by the harness.
The baseline uses the same configured model.
The baseline passes requests to the existing local tool function.
The baseline returns each tool result to the model through its message history.
The baseline total includes usage from every direct model call in the loop.

Implement the plain model-call loop in agent_comparison.py using these comparison rules.
Save agent_comparison.py.

Before you run the comparison, do you expect manually managing the tool turn to increase or decrease the baseline total?

Run agent_comparison.py again using the same Python 3 command from earlier.

You should see the existing agent output followed by a harness total plus a baseline total. The relationship between those numbers comes from your run.

Baseline loop stops early?

Check that the loop adds the local tool result to its message history. The model needs that result before it can produce the final answer.

If the baseline count looks incomplete, confirm that your total includes usage from every direct model call. A tool task can require more than one call.

Help me debug the plain comparison loop

✔️ I have both measurements

Your comparison script now prints one harness token total plus one baseline token total from the same task.

ⓧ I'd like to double check the full code

The complete agent_comparison.py has this structure:

It imports the Strands harness.
It creates one agent instance with the configured model.
It sends the initial prompt to that agent instance.
It registers the existing local custom tool function.
It runs the existing tool-dependent prompt.
It prints the trace plus the model reply.
It sends the context-dependent follow-up prompt to the same agent instance.
It reads the harness usage from the completed run.
It prints the harness token total.
It runs the same task through a plain locally written model-call loop.
It prints the baseline token total.

Verify both totals

The final check proves that one script can reproduce both measurements. Each side needs a fresh history so earlier conversations cannot inflate either result.

Confirm that the harness measurement uses a fresh agent run.
Confirm that the baseline measurement uses a fresh message history.

Before you run the final check, which token count do you expect to be larger for this exact task?

Run agent_comparison.py one final time using the same Python 3 command from earlier.

You should see the harness trace plus its reply. Below that output, you should see one labeled harness token total plus one labeled baseline token total.

That is the measurement complete. You now have two counts produced by the same prompt on the same configured model.

Both measurements now come from your own controlled run. Next, you'll place them in a table and identify what created the gap.

Compare the Results

You proved that the same task can run through the Strands Agents harness. Your plain loop now prints a second token count for comparison.

The final piece is a durable record that you can revisit after the framework changes. You'll preserve both measurements in a comparison table.

Two numbers alone cannot explain the gap. Your written note connects the result to the work performed by each path.

In this step, get ready to:

Capture both measured token counts from your terminal output.
Build a comparison table in token_comparison.md.
Explain the observed difference using evidence from your run.

Capture the measured counts

A fair comparison needs measurements from the same task. Your script already produced both results from matched work.

Switch back to the terminal from the previous step.
Find the line that reports the harness run's token usage.
Record the printed value here: your measured harness token count.
Find the line that reports the baseline token count.
Record the printed value here: your measured plain-loop token count.

That's the measurement work complete. Both values now come from matched work in your own script.

Build the comparison table

A Markdown table keeps the evidence readable without tying it to the script's internal structure. Saving it beside the script keeps the result with the experiment that produced it.

Return to the editor you used for agent_comparison.py.
Create token_comparison.md inside the same local project directory by using the editor's file creation control.

You'll see token_comparison.md beside agent_comparison.py in the editor's file browser.

Add Token Comparison as the document heading.
Create a three-column Markdown table for the run name, measured token count, and run scope.
Use your editor's Markdown preview to render the file.

You'll see the document heading above an empty three-column table.

Add a Strands harness row that describes its framework-managed tool, memory, context, and prompt handling.
Enter your measured harness token count as the row's measured value.
Refresh the Markdown preview.

You'll see the harness row with the count produced by your own run.

Add a Plain loop row that describes the same task running through your local loop.
Enter your measured plain-loop token count as the row's measured value.
Refresh the Markdown preview.

You'll see both measured counts aligned in the same table. The side-by-side layout makes the direction of the difference visible.

Explain and verify the difference

The table records what happened. The note captures your interpretation of why it happened.

How should you explain the gap?

The direction comes first. A higher harness count can reflect framework-managed tool information, agent memory, model context, or prompt overhead.

A lower count can reflect less repeated prompt material in this run. An equal count suggests the extra cost balanced with any savings for this task.

A complete note reports the direction in its first sentence. Its second sentence identifies the most plausible source shown by your trace.

Add the two-sentence comparison note beneath the table.
Save token_comparison.md.

Before you preview the finished file, which run do you expect to have the larger token count?

Render token_comparison.md with your editor's Markdown preview.

You'll see a table with one row for each run. You'll also see your explanation directly beneath it.

Compare the harness table cell with your measured harness token count.
Compare the plain-loop table cell with your measured plain-loop token count.
Confirm that the note states whether the harness count is higher, lower, or equal.
Confirm that the note identifies a plausible source of the observed difference.

✔️ Awesome, I've got everything!

Your saved comparison contains both measured counts. It also explains the observed difference using evidence from your run.

ⓧ I'd like to double check the full comparison

The finished file should match this structure.

Confirm that token_comparison.md sits beside agent_comparison.py.
Confirm that the table has one row for the harness count.
Confirm that the table has one row for the plain-loop count.
Confirm that the note states the direction of the difference.
Confirm that the note identifies framework-managed tool, memory, context, or prompt overhead as applicable to your run.

Does the table look broken?

Check that every table row has three columns.
Place the separator row directly beneath the table's header row.
Save token_comparison.md before refreshing the preview.

Ask for help with the table structure: Help me fix my Markdown comparison table

You turned a framework claim into evidence from your own task. Your script and saved table now show exactly what you measured.

Secret mission

Normalize Your Token Comparison

Turn your two raw token counts into a signed percentage that shows the harness result relative to the plain loop. Add the result to your comparison report with a clear interpretation and a task-specific caveat.

Clean Up Your Resources

Your comparison files live only in the local project directory, so they create no ongoing cost while idle. Choose whether to keep them ready, pause your experiments, or delete the files entirely.

Resources you used:

The local agent_comparison.py script that compares the harness run with the plain model-call loop.
The local token_comparison.md table that records both token counts and the source of the observed difference.

Keep everything running

No action is needed. Choose this if you want to continue testing prompts or model configurations.

Keep agent_comparison.py available for future harness experiments.
Keep token_comparison.md as the evidence from your measured comparison.
Review your provider's pricing before making more model calls.

Pause - I'll come back to this later

No agent service stays running after the comparison script exits. Pausing means leaving the files untouched without making more model calls.

Leave agent_comparison.py in the current local project directory.
Leave token_comparison.md in the same directory.
Return to the files when you are ready to compare another task.

Delete - I don't want to use this again

Remove the local comparison artifacts if you no longer need the script or its measured results.

Deleting these two files is permanent. Your existing Python installation and model-provider configuration remain untouched.

Return to the terminal that is already open in your local project directory.
Choose the operating-system tab that matches your terminal.

macOS

Delete both comparison files by running this command:

rm agent_comparison.py token_comparison.md

The command removes agent_comparison.py and token_comparison.md from the current directory.

Check the remaining contents by running this command:

ls

You should no longer see agent_comparison.py or token_comparison.md in the directory listing.

Windows

Delete both comparison files by running these commands:

Remove-Item agent_comparison.py
Remove-Item token_comparison.md

The commands remove agent_comparison.py and token_comparison.md from the current directory.

Check the remaining contents by running this command:

ls

You should no longer see agent_comparison.py or token_comparison.md in the directory listing.

Still See a Comparison File?

If the delete command cannot find a file, confirm that the terminal is still in the local project directory. A missing file may already have been removed.

Help me work out why my local comparison files were not deleted.

Nice Work!

You did it! You built a working agent with the Strands Agents harness. You measured its token usage against a plain loop using the same task.

You've learned how to:

Create a working agent with a configured model. Run an initial prompt to see the model's answer in your terminal.
Register a custom local tool with your agent. Confirm its use through the trace output.
Prove memory across turns with a context-dependent follow-up. Record both measured counts in a token comparison table that explains the observed difference.
Secret Mission: Complete the optional project extension to push your agent engineering skills further.

Ready to quiz yourself?