Building Agents with Amazon Nova Act and MCP — Du’An Lightfoot and Banjo Obayomi

Given an objective, how does a system decide which actions to take—and what should it do when those actions do not finish the job? The starting point is a loop: plan, act, evaluate. A prompt supplies the objective; the agent chooses actions and invokes tools; then it examines the results and decides whether to revise its plan or continue. Completion depends on that feedback, not simply on issuing a tool call.

Around the loop sit the components that make it useful: user input, an optional human intervention point, and a generated response. Inside are the LLM, an external knowledge base, guardrails, memory, tools, and connections to other agents or models. Guardrails can constrain actions and check whether a response agrees with retrieved information. MCP provides one way to connect additional capabilities.

Evaluation belongs around this entire system. Is the model appropriate? Are prompts consistent and accurate? Does performance meet expectations, and does the system solve the intended problem? Logging makes those questions inspectable; subject-matter experts can review outcomes and guide the next iteration. Use an agent when the required tools or sequence are uncertain. For a single predictable if/then operation, ordinary code may be the better solution.

Amazon Q supplies specialized assistants in the AWS console, IDE, and command line. Du’An Lightfoot uses the CLI for video editing, document summaries, and unfamiliar-code analysis. His debugging example is concrete: he asks Q to identify the APIs called by a demo application, compares them with API Gateway, and discovers that the deployed code references the wrong endpoints. The assistant helps expose the mismatch; the developer checks it against the actual service configuration.

The workshop places that ready-made experience beside two approaches for building your own system:

Strands Agents is the workshop’s implementation path. It can use Bedrock models or reach other providers through LiteLLM.

Strands reduces the initial agent definition to a prompt, an LLM, and tools. A weather lookup can begin as a Python function; the agent receives that function and instructions about its role. Du’An describes the framework as lightweight and recently released, and reports building a multi-agent solution in under 50 lines of code. That is a description of his example’s size, rather than a measure of reliability or runtime.

Amazon Nova Act supplies the browser capability. Introduced here as a research-preview model, it can follow instructions to research a website, find products, and perform actions such as adding an item to a cart. The Nova Act SDK exposes this capability to Python; an MCP server can make it available to an assistant as tools.

MCP also connects less elaborate personal workflows. Du’An’s Obsidian server saves and retrieves documents. His bookmark server records a title, description, date, and optional notes, so Q CLI can later retrieve bookmarks about MCP or narrow the request to those saved the previous week. The useful boundary is a reusable operation with enough structured context for an assistant to call it.

Banjo Obayomi builds the workshop in three layers: first a Nova Act call, then a Nova Act MCP server, then a Strands agent that uses the server. Attendees receive provisioned AWS accounts and a browser-accessible development environment, so the session does not require local installation or a personal AWS account. The companion sample repository contains the workshop examples.

The recording’s setup proceeds as follows:

1. Enter the supplied account. Use the workshop’s Open AWS Console button rather than creating or signing into a personal account.
2. Request Bedrock model access. Bedrock provides serverless foundation-model access alongside capabilities such as knowledge bases and guardrails. Banjo selects Amazon models and Claude 3.7, Claude 3.5 Haiku, and Claude 3.5 Sonnet.
3. Open the preconfigured VS Code server. Use the supplied address and password.
4. Optionally sign into Amazon Q. Banjo uses a Builder ID, described as free and independent of an AWS account or credit card.

These are the provisioned workshop’s setup steps, not a requirement that every Strands application use AWS.

For the reusable instructions, Banjo points attendees to the AWS Workshops catalog and a search for Nova Act. The remaining credential is separate: generate a Nova Act API key through the Nova site using an Amazon retail account, then export it before running the script. That site also presents Nova’s chat and media capabilities. With venue Wi-Fi slowing setup, he continues into the first example.

The first script opens Amazon, searches for a coffee maker, selects the first result, and extracts the product title. Instead of inspecting the page for a particular div, h1, or p selector, the developer describes the intended interaction. The same sequence can be expressed in Python with a starting page supplied as a command-line argument:

import sys
from nova_act import NovaAct

with NovaAct(starting_page=sys.argv[1]) as browser:
    browser.act("Search for a coffee maker.")
    browser.act("Select the first result.")
    result = browser.act("Return the title of this product page.")
    print(result.response)

The developer still defines the sequence. Nova Act handles the page-level interpretation needed to carry out each instruction.

The first run fails before completing the search. The Linux development environment lacks the graphical display needed by this browser invocation. Restarting through Xvfb, a virtual X11 framebuffer, supplies that display:

xvfb-run -a python3 coffee.py "$STARTING_PAGE"

The problem is the browser’s display environment, not the coffee-maker instruction. A development editor running inside a browser does not itself provide an X11 display to the browser process launched by Python.

The restarted run narrates its progress: Amazon homepage, search box, search results, product page, title extraction. It returns a BLACK+DECKER coffee-maker title and ends the session. The useful output extends beyond that answer: screenshots and an HTML log capture intermediate actions, and a WebM recording makes the interaction replayable. Those artifacts help explain why a run reached a particular product.

Asked whether the model reasons over pixels or HTML, Banjo describes visual page understanding: it recognizes a search box and decides where to click rather than requiring the developer to name an H1 tag. The replay shows typing, searching, and selecting a result amid advertisements. But visual navigation does not remove access controls. When an attendee asks about Cloudflare blocking and CAPTCHA challenges on servers, Banjo explicitly says Nova Act does not bypass CAPTCHA.

Human participation requires a surrounding workflow. Banjo suggests using Python to wait for a response, ask a question, or make an API call, and contrasts the cloud execution with a visible Chrome window on his MacBook. The presenters discuss manual password or CAPTCHA entry followed by continuation, and reuse of a browser session that is already authenticated, including one previously verified with two-factor authentication. No coordinated approval or pause/resume implementation is shown at this point.

The next example searches a predefined list of monitors for price, rating, and size. Because each lookup is independent, Banjo starts three threads rather than waiting for one product search to finish before beginning another. This example explicitly uses headless mode, avoiding the framebuffer command used for the first run. Progress logs show the separate searches, including a Dell monitor lookup.

An attendee reports that an Amazon search worked once in April but triggered CAPTCHA on later attempts, then asks whether llms.txt or robots.txt can declare an allowed automation path. Banjo points to the working live run and the SDK repository; the repeat-run blocking question and protocol question remain unresolved. The workflow is nevertheless useful where browser access works and no native API exists—for example, collecting material for a daily news report.

A more ambiguous request would be to return broken sunglasses: start with Google, find the company, locate support, and open a ticket. Banjo explains that general website conventions can help the model find a support button, while unusual steps—such as a site-specific find-an-expert path—need explicit instructions. Failure recognition is imperfect: he has seen the model keep scrolling without knowing when to stop.

Deceptive pages raise a separate problem. An attendee asks whether the model can distinguish a real download control from a misleading advertisement. Banjo invokes built-in safeguards and points to the Amazon example skipping an ad, but does not demonstrate the deceptive-download case. Meanwhile, the monitor searches finish and return size, rating, and price-range information. The completed parallel lookup and the unresolved adversarial-navigation question are different kinds of evidence.

Act is specifically the browser-automation member of the Nova family. The other models named are Nova Pro, Nova Premier, Nova Lite, and Nova Micro for understanding tasks, Nova Canvas for images, and Nova Sonic for speech. The video model is Nova Reel, its official name, although Banjo calls it Nova Video. He offers no commitment about extending Act to non-browser Slack or IDE interactions. He also describes the recording’s preview as US-only.

Browser state can explain different shopping results. The presenters suggest inspecting the session recording when attendees get different Amazon pages. By default, the browser starts fresh; a custom Chromium profile can instead preserve cookies and authenticated state. That choice affects what the agent sees before it takes its first action.

Module two wraps Nova Act in a custom MCP server. Banjo asks Amazon Q to explain the implementation, which exposes operations for opening browser sessions, performing actions, running parallel tasks, taking screenshots, closing browsers, and listing results. An assistant in Claude Desktop, Cursor, or Q CLI can consume those operations. A request for a coffee maker or a comparison of three monitors can therefore drive tool calls without a new hand-written task script.

The custom client uses Claude 3.5 Sonnet through Bedrock to interpret the request and select tools. Nova Act remains responsible for browser interaction. The editor view shows the Bedrock conversation configured with a model, messages, and tools; Banjo then launches the Python client. MCP supplies the interface between the planner and browser capability; it does not itself supply the planning model.

The audience chooses a new task: find a website that explains how to fix Wi-Fi, using headless mode. The client plans to open Google, search for a troubleshooting guide, and return website titles and descriptions. It reaches the search box and types the query—then encounters reCAPTCHA.

The agent repeatedly sees the challenge, including an attempt to use a skip button, without making progress. Banjo closes the session. This is a visible failure of the complete workflow: a plausible plan and working browser tools do not guarantee access to the requested information. He returns to the prepared Amazon query for a coffee maker under $50. Banjo again proposes manual intervention in a local visible browser, while noting that the current cloud headless environment does not offer that interaction. The Amazon query then returns search results.

The subsequent account-dependent scenarios remain proposals:

• Purchases: Banjo describes an explicitly authorized order using his own already logged-in browser session; no purchase is completed.
• Credential entry: He says the model can identify username and password fields and discusses environment variables. Storing a secret in an environment variable alone does not keep it out of a prompt or visible page content; SDK guidance recommends direct browser automation for secret entry and warns about sensitive information in screenshots.
• Two-factor authentication: Retrieving a code from Gmail receives a conditional answer, dependent on access and the absence of a blocking challenge.
• Flight alerts: Asked about booking below a price threshold, he proposes a daily flight-price check and an email alert instead. A scheduled Python invocation, potentially triggered through Lambda, would provide the recurrence.

At the time of the workshop, Banjo describes Nova Act access as free during the preview. The practical application he emphasizes is interacting with sites that lack native APIs.

Nova Act access is separate from the planning model’s Bedrock access. The Nova Act API key authorizes the browser capability; the Bedrock model ID selects Claude 3.5 Sonnet for the custom client’s planning and tool selection. A host such as Claude Desktop supplies its own LLM instead of requiring this particular Bedrock client. LastPass integration through a custom browser is explicitly untested, and the presenters identify authenticator-based two-factor checks and CAPTCHA as obstacles.

An audience member sketches a coordinator built in LangChain or LangGraph that delegates web research and receives text back through a message queue. Nova Act fits that arrangement as a Python tool or API-backed capability. Strands offers another coordinator implementation: a model-first approach that delegates more action selection to the LLM than the scaffolding built around older models such as Llama 2. For installation, use pip install strands-agents; the spoken pip install strands is shorthand with the wrong package name. The Python import namespace is strands.

The next agent combines two servers from AWS Labs MCP: AWS documentation and AWS diagrams. The catalog also includes capabilities for cost analysis, Nova Canvas, and CloudFormation. Banjo gives the agent a solutions-architect role, a Claude Haiku model through Bedrock, and the tools exposed by those two servers. LiteLLM and Ollama are alternatives when another provider or a local model is appropriate. The request is to retrieve AWS Lambda documentation and create a diagram of a website that uses Lambda.

On execution, uv installs and starts the MCP servers locally. Banjo mentions Lambda as another possible hosting location, but this run uses local processes. The agent searches the documentation, retrieves the Lambda welcome material, generates a diagram, and provides its saved location. Banjo opens the generated artifact and reports that the two-server example takes about 40 lines of code. The important composition is visible: documentation retrieval provides current reference material, and a separate tool produces the diagram.

Strands does not make Bedrock Agents obsolete. The choice is about development and runtime control:

The presenters name Anthropic, OpenAI, LiteLLM, and Ollama as provider options. An application using an alternative provider need not use AWS at all. The documentation view reinforces that separation by showing OpenAI support alongside other providers.

A text-to-SQL developer asks how an agent with 15 existing tools can choose the correct tools and sequence. Banjo starts with the mechanics of exposing a function: decorate it with @tool, then include it in the agent’s tools. His weather example combines the standard HTTP request tool with a custom word counter. He changes the location from Seattle to San Francisco and asks for the forecast first, followed by the number of words in the response. The weather service used in the example requires no API key.

The word-count portion is small enough to make the contract explicit:

from strands import Agent, tool
from strands_tools import http_request

@tool
def word_count(text: str) -> int:
    """Count whitespace-separated words in the supplied text."""
    return len(text.split())

agent = Agent(tools=[http_request, word_count])
agent(
    "Use the National Weather Service API to find the forecast "
    "for San Francisco. Write a forecast summary first, then call "
    "word_count with that exact summary and report the count separately."
)

The prompt supplies the dependency: the text must exist before it can be counted. The model chooses the tool calls needed to satisfy it.

The attendee then reports confusion with larger tool sets and asks whether model-driven selection invites hallucination. Banjo recommends trying Claude Sonnet 4, expressing confidence in newer models rather than presenting a measured tool-selection result. When order must be fixed, Strands also supports explicit workflows—for example, research, then analysis, then a final report. When the order is unknown, the agent can infer it from the objective and available tools.

Du’An adds Claude 4’s interleaved thinking and parallel tool calls to the discussion. These are distinct: interleaved reasoning lets a model reconsider the task between tool interactions; parallel calls let independent operations proceed together. Neither supplies a general reliable-tool-count threshold for the SQL application.

The final integration step attaches the existing Nova Act MCP server to another Strands agent with a Claude model. The browser implementation does not need to change when its host changes. In a multi-agent workflow, each agent can also receive its own system prompt, tool set, and model; the workflow invokes those separately defined agents. That provides a direct way to give a specialist only the capabilities relevant to its work.

An audience member raises the possibility that automation could enable fraud at scale, prompting sites to add more challenges and reduce the web accessible to agents. Banjo reiterates that CAPTCHA bypass is not the objective and says API keys allow monitoring and abusive use cases to be shut down. This addresses accountability, though it does not resolve the longer-term accessibility concern.

The extended Q&A also asks about connecting to an existing headless cloud browser. Banjo answers affirmatively and opens SDK examples, then mentions custom user-agent configuration. These are separate controls: a persistent profile retains browser state, remote attachment connects to a browser instance, and a user agent changes browser identification. The recording does not supply a remote-attachment configuration.

A Streamlit game-research application illustrates a failed larger workflow. It is intended to find five PlayStation games on GameFAQs and create a graph image; the displayed app has PlayStation 5 search settings, a headless-browser option, and an active progress bar. Nova Act then encounters an error navigating GameFAQs, preventing the application from completing that task.

Asked about semantic HTML and page design, Banjo returns to visible affordances: the model needs to recognize where to search and what to click. An instruction to explore a site can invite exploratory interaction, but an obscure workflow benefits from explicit steps. The SDK examples encode those steps directly; an MCP client infers them from the user’s request unless given more detail.

Banjo then hides his API key and runs the coffee-maker script on his local machine with a visible browser. It opens the page and types the search. He deliberately changes the page while the agent is working, and the run crashes. A shared browser makes human interaction possible, but unsynchronized interaction can invalidate the agent’s current state. A visible window alone is not a coordinated handoff protocol.

With the custom Nova Act tools available in Claude Desktop, an audience question about drag-and-drop leads to an improvised task: open draw.io and make a cool diagram. The run encounters tool permission approval, takes a screenshot, and attempts to continue the browser session. Switching focus interferes with the interaction. Banjo suggests a more precise instruction—click a square and drag it to the center—while the agent explores templates and new-document controls. No completed diagram appears, and the attempt does not establish drag-and-drop support. Banjo attributes the failure to Claude, but no root cause is demonstrated.

The next request is more concrete: find the top three rated coffee shops within a mile of the Marriott Marquis in San Francisco. The agent opens Google Maps, searches for the hotel, and then searches for nearby coffee shops. Candidate listings become visible, but Banjo reports that Claude Desktop has crashed before the task produces its final answer.

He switches to Cursor and issues the same kind of request against the same Nova Act MCP server. Cursor discovers and calls the tools without a server rewrite. This is a concrete portability benefit: the client and its planning behavior can change while the browser-tool implementation stays in place. It does not by itself establish why the first client failed.

While the Maps task runs, an attendee asks where Nova Act executes. Banjo distinguishes the browser on the local machine from the model in AWS: Nova Act uses API-key-authenticated cloud calls and requires an internet connection. Asked about a logged-in Gmail session, he advises caution about information passed to the endpoint and offers a no-training assurance. That assurance needs to be read alongside the later data-flow discussion, rather than treated as a complete account of data handling.

The returning Maps task makes the component roles clearer:

The client’s model constructs the plan; Nova Act executes its browser actions; returned information feeds the client’s next step. Banjo reports that Cursor obtains three coffee shops. The displayed response lists Metropolitan Coffee, Mells Cafe, and Capital One Café with ratings and addresses, but the demonstration does not establish that the one-mile boundary or exhaustive ranking was checked.

Banjo distinguishes the AWS Labs catalog from the Nova Act server he wrote, then uses Amazon Q to explain its browser-action function. The central operation passes an instruction to act.act: search, click a button, or perform another action in an existing browser session. The MCP interface gives clients the operations they need without requiring each client to implement Nova Act integration itself.

A follow-up traces the local client to the local MCP server and the Chromium instance it starts. Here Banjo says screenshots remain local and then denies that Chromium information needs to be sent to Nova Act. That conflicts with his earlier description of cloud processing. A local browser must not be treated as a local-only inference guarantee: the later AWS service card describes screenshots and prompts being sent to cloud inference, while current SDK disclosures say API-key developer-tool interactions, including screenshots, are collected for service improvement. Those documents cover different service contexts and do not establish the exact payload, retention, or training terms of the workshop’s June 2025 preview.

The server’s descriptions also act as execution guidance. Banjo includes examples such as opening the hamburger menu before visiting order history, searching for Houston hotels and sorting by customer rating, or typing coffee maker into the search box and pressing Enter. A useful tool contract explains when to use the tool, how to use it, and its inputs and outputs. Encoding that guidance once gives different MCP clients the same context for constructing actionable requests.

Results close the loop. Banjo describes logs containing the starting page, results, and an action-result ID, with JSON returned so the client can decide what to do next. For UI testing, he proposes explicitly naming the interaction and the check: go to a button, click it, and determine whether the expected behavior occurs. Natural-language instructions can replace some selector-oriented scripting, but the recording does not add a formal assertion system or demonstrate that a log entry alone proves success.

The final example moves beyond browsing into multi-agent collaboration. Banjo constructs a migration assistant with three specialists:

• Architecture agent: Maps the proposed cloud architecture using its own prompt and architecture tools.
• Cost-analysis agent: Uses documentation and cost-analysis MCP tools to estimate the proposed system’s costs.
• Presentation agent: Uses a PowerPoint MCP server to turn the material into an executive presentation.

A migration orchestrator receives these agents as tools. Each specialist has a separate prompt and capability set; the orchestrator decides when to invoke it.

The input is a fictional company, Shop Easy eCommerce, with an on-premises Java application and MySQL database. It requests a zero-downtime migration, a migration plan, and a PowerPoint presentation for executives. Zero downtime is a requirement in the brief, not an achieved result. Banjo does not prescribe which specialist runs first; he leaves that sequencing to the orchestrator.

The run downloads and starts the MCP servers locally through uvx, then chooses architecture design first. WAF appears in the proposed design, but diagram generation runs into trouble. The agent continues with a written description of what the diagram should contain. The terminal visibly acknowledges the diagram problem before presenting the architecture text: the workflow has continued, but one requested artifact is missing.

Next comes cost analysis based on the proposed architecture. The agent looks up EKS and Aurora pricing through AWS Labs tools, which Banjo describes as providing current pricing. An audience question raises regional assumptions, with us-west-2 mentioned, but the exchange does not establish a complete regional cost model. The run proceeds toward monthly-spend and savings predictions without presenting numerical outputs that can be assessed here.

Finally, the orchestrator starts the executive presentation. It downloads the PowerPoint MCP server and begins adding a title slide, placeholders, and bullet-point content. The recording ends while generation is still underway. No finished deck is opened, and no infrastructure migration is performed. The last visible state is a useful boundary for judging the system: specialists have been selected, external tools have been called, and work has continued after a diagram failure—but completing and inspecting the requested deliverable is still pending.