What Happens When You Let a Claude Code Agent Loose on AWS

The demo that should reset your sense of what an agent can do

Someone wired Claude Code to a Chrome automation tool, pointed it at the Amazon Web Services console, and walked away while it built a live website, launched a server, and shipped a working app. No human moved the mouse. The agent read the pages, clicked the buttons, and finished three tasks that got harder each time. I am Madhuranjan Kumar, and I want to take this run apart slowly, because underneath the novelty there is a lesson about how machine competence actually forms, and it changes how you should think about handing work to software.

The AWS console was not chosen because it is easy. It was chosen because it is one of the most punishing control panels in all of software, a wall of nested menus, cryptic settings, and permission toggles that trip up experienced engineers. If an agent can navigate that without a person guiding every click, the harder question is no longer whether it can operate your booking system or your ad manager. It obviously can. The interesting question becomes why it succeeds, and what that tells you about where to spend your effort.

Competence is not in the model, it is in the tooling around it

The first thing this run proves is that raw model intelligence was never the missing piece. The same Claude that answers questions in a chat box became dramatically more useful the moment it was given a real tool. The Chrome automation layer talks to the browser through the Chrome developer protocol, the same low level channel a debugger uses. That connection lets the agent see the actual page and act on it, rather than guessing about a screen it cannot touch.

This is the facet most people miss. When a business owner is disappointed by an AI, the instinct is to blame the model and wait for a smarter one. But the gap is almost never intelligence. It is access. A brilliant assistant locked in a text box can only give you advice. The same assistant with a hand on the controls can do the job. Everything impressive in this AWS run traces back to that single decision to hand the agent a genuine tool instead of asking it to describe what it would do.

You can feel the same principle in ordinary marketing work. A model that can only suggest ad copy is a consultant. A model connected to your account, watching what happens to the cost per lead on Facebook and Instagram ad campaigns and adjusting the creative in response, is an operator. The intelligence is identical. The wiring is everything.

The behavior that separates a real agent from a script

The single most important moment in the whole run was not a success. It was a failure the agent refused to repeat. On the first task, building a storage bucket, uploading an image, and hosting a simple web page, the agent had to change a policy setting so the page would load for the public. It even worked out on its own that it needed to uncheck the block public access setting, which is not obvious. But editing that policy inside the menu kept failing.

A dumb script hits that wall and either stops or bangs on the same broken button forever. This agent did something different. It abandoned the menu, opened the built in command shell, and finished the job with a single command line instruction. That pivot, trying a genuinely different path when one route stalls, is the exact behavior that separates an agent from an automation macro. A macro follows a fixed sequence. An agent has a goal and will find another road to it.

This matters more than any benchmark, because real work is full of moved buttons, changed menus, and small surprises. A system that only works when the screen looks exactly like it did yesterday is fragile. A system that treats an obstacle as a puzzle to route around is the thing you can actually leave running. When you evaluate any agent for your business, this is the property to test for. Break its expected path on purpose and watch whether it adapts or collapses.

Skills are how an agent stops paying the beginner tax twice

The first task took about forty minutes, which is slow. All that time went into learning the console, figuring out where things live and how the settings interact. Here is the clever part. The agent was told to write down everything it had learned and save it as a reusable skill, a compact note capturing the route it had just discovered.

On the next two tasks, launching a live Linux server and opening a video in its browser, then building a small video upload app, the agent read that skill first. It did not relearn the console from scratch. The third task, a working app where you upload a clip and get a shareable playback link, finished in roughly five to ten minutes. The same kind of work that once cost forty minutes now cost a fraction of that.

This is the facet with the biggest business consequences, because it changes the economics of the second run. Most software costs the same every time you use it. An agent that saves its learnings gets cheaper the more it works, because it stops paying the beginner tax on every repeat. The first time it navigates your supplier portal or your ad dashboard is expensive. Every time after that is fast, because it reads its own notes instead of exploring blindly.

That compounding is the quiet engine of the whole story. It means the right way to deploy an agent is not one big perfect task. It is a small task, a saved skill, then a slightly bigger task that reuses the skill, over and over, until the agent has a library of routes through your systems that no competitor's fresh agent can match.

A worked example: reclaiming a store owner's mornings

Let me make this concrete with numbers, framed as an illustration rather than a guaranteed result. Picture a shop owner who spends an hour every morning inside a store dashboard. They update prices, mark items out of stock, fix a few product photos, and export yesterday's orders into a spreadsheet for the bookkeeper. That is roughly five hours a week, or about 250 hours a year, spent on careful clicking that needs zero creativity.

I would start the agent on one slice of that, say pulling the new orders, flagging anything that looks like fraud, and dropping a clean summary into a shared sheet. The first run might take twenty minutes while it learns the layout. Then it saves that route as a skill. The next morning it reads the skill and finishes the same job in three minutes. Over a month, that one workflow moves from roughly ten hours of owner time to under two.

From there the skills stack. A second skill syncs inventory between the store and a marketplace listing. A third refreshes a homepage banner when a sale starts. A fourth pulls the weekly numbers into a report. Each new skill reuses what the earlier ones learned about logging in and moving around the dashboard, so each one is cheaper to add than the last. And when a path breaks, because a button moved or a menu failed, the agent does what it did on AWS and finds another way, the same pivot to a command shell that saved the first task. The owner is not building an unbreakable machine. They are building a worker that recovers on its own.

The output of all this is not just saved hours. Clean order data flowing reliably into one place is exactly the kind of foundation your CRM and website stack needs to make follow up automation actually work, and a store that runs its back office this smoothly has more attention left for the front of the house.

Where it cheated, and why that is the real headline

On the harder tasks the agent leaned on the command shell instead of pure browser clicking, which the person running the experiment called cheating but allowed. It is worth sitting with that, because it is not a flaw. It is the entire point. When you give an agent more tools, it reaches for whichever one finishes the job fastest. It has no attachment to doing things the hard way.

That is a feature to design around, not a bug to suppress. If you want an agent to solve problems efficiently, give it several real tools and let it choose. If you constrain it to one narrow method, you get slower, more brittle results. The businesses that win with this will not be the ones with the cleverest single prompt. They will be the ones that connect their agent to the real systems where work happens and let it save what it learns, so the second run is cheaper than the first and the tenth is nearly free.

There is also a discipline baked quietly into the story. The run was never trusted until it was tested end to end with a real file, and even a two hundred megabyte upload was verified to play back from a public link before anyone called it done. That is the correct posture for any business. You let the agent do the work, then you check the result before you rely on it. Automation without verification is just faster mistakes.

The limits worth naming before you get excited

An honest account has to include what did not go perfectly, because that is where the practical guardrails come from. On the second challenge, opening a video inside the browser, the page rendered only partway before it was counted as a pass. That is a useful reminder that these agents produce results that are often good enough rather than pixel perfect, and you have to decide up front what good enough means for each task. For an internal report, partial is fine. For a customer facing checkout, it is not. The person driving the task, not the agent, sets that bar.

The forty minute first run is the other limit worth sitting with. Agentic work is not instant magic on the first attempt. The first pass through any unfamiliar system is slow and sometimes clumsy, and if you judge the whole approach by that first run you will wrongly conclude it is not worth it. The value lives in the second, fifth, and tenth runs, once the skills have accumulated and the route is known. This is exactly backwards from how most software feels, where the first use is the easiest and complexity creeps in later. With an agent, the first use is the hardest and it gets easier from there. Understanding that curve is what keeps you from quitting one run too early, right before the payoff.

There is also a spend dimension. Driving a complex console through many small steps consumes tokens, and a forty minute exploratory run is not free. That is another reason the skill saving behavior matters so much, because it converts an expensive one time exploration into a cheap repeatable route. Treat the first run as an investment with a known cost and a clear return, not as the normal cost of every run, and the economics make sense.

The move to make this week

If this run changed anything in your head, let it be the order of operations. Do not wait for a smarter model. Take one painful, repeatable task your team clicks through every day, connect an agent to a browser automation tool, and let it do that single job while you watch. When it succeeds, have it save the steps as a skill so the next run is faster. Then add a second task, and a third, letting the saved skills compound the way they did across those three AWS challenges.

The same instinct that makes a browser agent valuable applies to your whole marketing engine, where connecting the model to your real accounts is what turns advice into results, whether that is tuning Google Ads bids against live conversion data or keeping your content foundation fresh for SEO and organic search. The pattern is identical. Intelligence plus access plus saved skills equals a worker that gets better and cheaper over time.

You can absolutely build this yourself, one low risk task at a time, and I would encourage anyone curious to try it. If you would rather have someone map your real workflows, connect the agent to your actual systems safely, and build the skills so it runs reliably without babysitting, that is exactly the kind of setup I do for clients, and you can bring me in to handle it for you.