What Happens When You Give an AI Agent an Open-Ended Goal and Just a Browser

AI agents just proved they can complete a 10-step sequence they were never explicitly taught. A Claude agent given only browser automation tools and a vague outcome, no step-by-step instructions, no pre-built skill library, no scripted fallback sequence, registered an email address from a temporary mail service, created and email-verified a Twitch account, acquired a stream key, used FFmpeg to go live, and then saved the entire completed sequence as a reusable skill for future sessions. When the next goal arrived, earn a dollar in 30 minutes, it tried survey platforms, hit region locks, encountered a 240-checkbox form, and responded by writing JavaScript in the browser console to submit the form in a single function call rather than clicking through each checkbox one at a time. It earned one cent and hit an error at the final step.

I am Madhuranjan Kumar. I want to be precise about what this experiment demonstrates and what it does not. It does not prove that AI agents can run any business process autonomously without supervision. It proves something more specific and more useful: an agent given only a browser and an outcome will build the tools it is missing, adapt to obstacles it was not briefed on, and save what it learns from each completed task. That combination of behaviors is what a useful long-running agent actually looks like in practice, and this experiment makes it visible in a way that earlier edited demos did not.

The agent improvised past every obstacle it wasn't briefed on

The experiment setup was deliberately minimal. The agent had browser automation tools and a vague goal. It did not have instructions for which email service to use, credentials for a Twitch account, a pre-configured FFmpeg command, or a guide to navigating Twitch's settings pages. Every capability it needed had to be found or built during the run itself.

The first obstacle was getting an email address. The agent navigated to a temporary email service on its own without being told which one to use. It copied the address, used it to begin the Twitch registration, and when the six-digit verification code arrived in the temporary inbox, it retrieved the code directly without waiting for a human to look it up and paste it in. That step, the email verification, was the one observers expected to create the most difficulty. It was the fastest part of the run.

Stream key retrieval required navigating Twitch's creator settings, which are not organized in a way that makes them easy to find for a first-time user. The agent explored the interface, located the stream key in the correct settings section, and passed it to the FFmpeg broadcast command. The live confirmation came back active.

The 240-checkbox form on the money challenge is where improvisation becomes most instructive. A fixed automation script encountering a 240-checkbox form would look for the expected interaction path and stall when it found no practical way through. The agent identified the constraint and chose a different path entirely: write a short JavaScript function, execute it in the browser console, submit the form in one action. The goal was form completion. The most efficient available path was writing code, not clicking through checkboxes. The agent chose code.

The result of the dollar challenge was one cent and an error before the final payout step. The agent earned less than a dollar but never abandoned the goal. When a platform blocked it with a region restriction, it found another. When that one stalled, it tried a different approach. It continued improvising alternatives until the session ended. The persistence across failures is the behavior that matters for practical deployment, not the one cent outcome.

Saving a completed task as a skill is the feature that changes how you build

The most undervalued detail in this experiment is not the Twitch registration or the survey workaround. It is what the agent did after the broadcast confirmed live. It saved the entire completed sequence as a reusable skill.

A skill, in the context of long-running agents, is a saved description of a completed workflow that can be invoked in future sessions without rebuilding the discovery process from scratch. The first time an agent completes a complex multi-step task, it has found the path through that task. Saving that path as a skill means the second session on the same category of work starts from accumulated knowledge rather than a blank state.

This is the compounding mechanism that makes long-running agents economically significant over time. The first time an agent handles a supplier registration form with an unexpected layout, it takes the full discovery time. The second time, it invokes the saved skill and works faster. The tenth time, the agent's effective capability on that category reflects the learning from all nine prior runs. Without skill saving, each session is independent and the agent makes the same discoveries repeatedly. With it, each session builds on the last.

For a business deploying an agent on a recurring task, this reframes how you think about the agent's early imperfect performance. The agent navigating an unfamiliar form layout slowly on the first run is not failing. It is building the skill that makes every subsequent run faster and more reliable. The early investment in watching and occasionally correcting the agent pays a compounding return as the skill library grows.

The practical implication for anyone deploying agents is to make skill saving an explicit part of every session workflow. End each session by reviewing what succeeded and asking the agent to save those patterns with clear names. Build the habit early. The agents that compound fastest are the ones where the operator consistently captures completed workflows rather than letting them evaporate when the session closes.

Why most agent demos hide the part that matters

Most AI agent demos are edited. They show the clean success and cut the dead ends, the blocked platforms, the partial failures, and the improvised workarounds. A demo showing a Twitch registration complete in 60 seconds flat is more watchable than a demo showing two blocked paths, a JavaScript workaround, and one cent instead of one dollar. But the edited version is not the thing you are actually deploying.

When you deploy a long-running agent on a real business task, you get both the successful path and the improvisation around the obstacles. Real web environments serve up inconsistent page structures, geographic restrictions, broken redirect chains, verification steps that change design between visits, and form states the agent was not designed around. Those are not edge cases. They are the normal texture of browser-based work.

Understanding this changes how you design the deployment. You design for the agent to complete the core goal most of the time and to flag specific failures when they occur, not to succeed at every sub-task perfectly every time. The experiment's honest result, one cent instead of one dollar, is more useful information for a deployer than a clean dollar would have been. It shows exactly where the agent's improvisation ran out, which tells you where to add human checkpoints in a production workflow.

The standard for useful agent performance in business is not perfection. It is a reliable success rate on the core task combined with clean failure reporting on exceptions. An agent that completes 85 percent of a lead enrichment batch and logs the 15 percent it could not reach is more useful than a fixed script that fails silently when the first page changes its layout. The failure reporting is part of the value, not a limitation of the approach.

This also changes how you evaluate early agent sessions. When an agent improvises around an obstacle by writing a JavaScript function or trying a third platform after two were blocked, that behavior is not a workaround you want to prevent. It is the property you are deploying the agent for. The agent that improvises intelligently is more useful than one that fails cleanly at the first deviation from the expected path.

Where persistence-first agents are ready to deploy today

The category of business task where this kind of agent is ready to deploy now is structured, variable, repetitive browser work: tasks that follow a consistent goal each time but encounter enough variation in page structure, login state, or form design that a fixed script breaks regularly.

Lead enrichment from public sources fits this description directly. An operations team that manually visits company websites, LinkedIn pages, and news sources to fill in CRM fields spends hours on a task that is structured enough to automate but variable enough that fixed automation breaks at the first unexpected layout. A persistence-first agent navigates the variation by adapting rather than stalling.

Supplier and vendor research is another ready deployment area. Checking pricing pages, requesting quotes through contact forms, compiling specifications from different catalog layouts: each vendor's site is slightly different and a fixed script handles only the one it was built around. An agent that plans and adapts handles all of them at a consistency level fixed automation cannot match.

Competitor monitoring is a similar category. Checking a set of competitor pages for pricing changes, new offerings, or announcement updates requires navigating different site structures each time and identifying relevant changes without knowing their exact location on the page in advance. The agent's ability to understand the goal and find the relevant content regardless of exact page structure is the property that makes this work where fixed scraping breaks regularly.

The tasks that are not ready for this kind of deployment yet are the ones with irreversible consequences at each step and low tolerance for partial failure. Submitting purchase orders, sending customer communications, modifying live records: these require consistent human review at the output stage rather than at the exception stage. Build trust on reversible tasks first, establish a track record, and expand to higher-consequence tasks after many successful runs.

One worked example with illustrative numbers

An operations team at a mid-size consulting firm spent roughly 12 hours per week on lead enrichment. The process was structured: pull a batch of company names from the CRM, visit each company's website, LinkedIn page, and relevant news sources, fill in missing fields in the CRM record, and flag records showing recent funding or leadership changes as high priority for outreach. The goal was consistent across every record. The pages and layouts encountered were different for each one.

The team deployed a long-running agent with browser access and CRM write permission, with the goal stated as an outcome: enrich these 50 records with website URL, LinkedIn summary, employee count estimate, and most recent notable news event, and flag high priority on funding or leadership change signals. The agent worked through the batch, handled variation in site structures by adapting rather than stopping at unfamiliar layouts, and completed 43 of 50 records in approximately 90 minutes. The remaining 7 were flagged for human review because the agent identified ambiguous or inaccessible sources it could not resolve with confidence.

Before the agent, 50 records took approximately 6 hours across the team. After, the same batch took 90 minutes of agent time plus 20 minutes of human review on the 7 flagged records. The net time recovered was roughly 4 hours per batch. At two batches per week the weekly recovery was approximately 8 hours, redirected to higher-value analysis work the same team members had been too backlogged to reach before.

The flagged-record review also turned out to be valuable in itself. The 7 records the agent could not resolve clearly often turned out to be the most ambiguous prospects anyway, and the human review surfaced that ambiguity earlier in the process than the old workflow did. The agent's inability to resolve a record became a signal about the record's qualification status, not just a limitation of the agent.

These numbers are illustrative of the efficiency pattern rather than a specific client situation, but the structure holds across most lead enrichment contexts: agent handles the bulk, human reviews the flagged exceptions, and the net time recovery is significant enough to reassign meaningful work.

What to do with this

The immediate practical move from this experiment is to identify one recurring browser-based task that follows a consistent goal but encounters variable page structures. Run the agent on it in a controlled session with logging, and review the specific points where it improvised successfully versus where it stalled. The stall points show you where to add a human checkpoint or a clarifying instruction. The improvisation points show you where to trust the agent and let it run.

Save every successful workflow as a skill before closing the session. Build the habit of naming the skills that emerge from each run so they are accessible the next time the same category of task appears. Over weeks, the agent's effective capability on the task category grows from the accumulation of saved skills, and the time invested in the early imperfect runs pays a compounding return.

Keep the first deployment on a task with reversible consequences. Checking prices and updating a record is reversible. Submitting an order or sending a customer email is not. Build trust on the lower-stakes version first and expand permissions as the agent proves consistent over many successful runs.