What an Agent Can Do

The whole lifecycle, from an empty project to a report you can send someone. Each section below is a real thing to ask for, what the agent does about it, and what it should ask you along the way.

Find its bearings

What can I load test here, and how much capacity do I have?

Before anything else, a well-behaved assistant establishes what it is looking at: who it is signed in as, which account is active, which projects it can reach, which test plans and data files those hold, what ran recently, and how much capacity and usage allowance you have left.

That last part matters more than it sounds. Sizing a test without knowing the fleet is how people ask for 50 machines on a 20-machine account, or blow a monthly allowance on a warm-up run.

Record a scenario

Open our staging site, sign in as the demo user, add two items to the basket and check out. Turn that into a test plan.

The agent opens a real, visible browser. It reads each page as an accessibility tree — the same structure a screen reader sees — so it clicks "Add to basket" because that button exists, not because a selector was guessed. It names each step before performing it, because those names become the rows in your results report, and Rome is a useless row title.

You can watch the whole thing and take over whenever you like. For a password, an MFA prompt, or a decision only you can make, the agent hands the window back, you do that step, and it carries on recording.

Prefer to drive yourself? Say so, and it opens a plain recording session for you to click through while it waits.

Sign in without typing a password

Export your cookies, or reuse a saved browser profile, and the recording starts already signed in — see Recording a Scenario. Never give an agent a password to type.

Turn the recording into a real test

This is the step people skip, and it is the difference between a load test and an expensive replay.

A recording is a draft: it contains exactly what you did. The agent reads the capture and works through it with you, stage by stage, asking rather than deciding:

1. Is the flow right? The steps, their names, anything missing.
2. Which recorded values should become test data? The username and password you typed. The search term. The product id that appears in three different requests. If every simulated user sends the same ones, they collide on the same session and hit the same cache — the application looks fast because it is barely working. The agent proposes a CSV, the columns, and how many rows; you say whether to generate them or supply real data. Atlas then divides those rows between machines at run time, so no two users get the same row.
3. What changes per session? Session ids, CSRF tokens, cart ids — values the server issued, which must be captured from an earlier response instead of replayed. The recorder detects these with evidence, and the agent pins anything it missed. See Dynamic values.
4. Do you need checks? A 200 that returns a login page is a pass as far as JMeter is concerned. Assertions on the responses that matter turn that into a visible failure.
5. Upload and smoke-run it.

Edit an existing plan

Add a "search by postcode" step to our existing plan, and point it at staging.

The agent downloads the stored plan first — uploading replaces a file and there is no version history — then makes the narrowest change that does the job: recording a new scenario straight into the plan as an additional thread group, or editing specific values in place.

For structural surgery it will tell you plainly that the JMeter GUI is the right tool, rather than rewriting a plan nobody has the source for.

Debug it locally, in seconds

If JMeter is installed on your machine, the agent can run a single user through the plan locally before spending any Atlas capacity — the fastest way to confirm a new step, an assertion or a data file actually works.

It knows the trick that makes this practical: recorded plans contain think time, typically ten to thirty seconds between steps, which is correct for a real load test and absurd for a debug run. The agent switches it off in a throwaway copy, so a check that would have taken two minutes takes five seconds, then restores it — your plan keeps its pauses, and nothing gets uploaded with the think time missing.

It can also prove an assertion fails when it should, which is the only way to know a check is doing anything at all.

Check before you spend

Will this plan actually run?

atlas plan check catches what otherwise surfaces as an empty dashboard an hour later:

• A data file the plan reads that the project does not have. Every user in that thread group dies before sending a request, so the group disappears from your results with no errors at all while the rest look healthy.
• A plan Atlas cannot attach its reporting to — it runs, and reports nothing.
• A broken structure, or no enabled thread group.
• Fixed user counts, meaning more machines is the only way to scale it.

Size and run it

Run it with 500 users for ten minutes, ramped up over five.

Sizing is where load tests are most often wrong, in both directions. Each machine runs the whole plan, so 100 users in the plan across 5 machines is 500 users, not 100. The agent does that arithmetic against your real fleet, explains it, and confirms with you before starting anything larger than a smoke test.

It smoke-runs first — one machine, a couple of users — and checks the result contains actual data. A smoke run that finishes in seconds with nothing in it is a broken plan, not a fast application, and catching that costs one minute instead of twenty machine-minutes.

While the run is live it can report progress, and stop the test if you ask.

Read the results

How did it go? Where did it start to break?

Numbers are the easy part. The agent reports which steps degraded and at what user count, what the errors actually say — with the real request and response, not just a code — and how the run behaved over time rather than as one average.

It is also taught to distrust a clean-looking result. A test that measured nothing looks better than one that worked: a missing thread group with zero errors, a run that ended in seconds, or fast 200s returning login pages. Those are reported as failures of the test, not as performance.

Wire it into CI

Add a nightly load test to our pipeline and fail the build if p95 goes over 800ms.

The agent writes the pipeline step, using thresholds and exit codes rather than a human reading a dashboard:

atlas run -p SHOP --jmx checkout.jmx --servers 4 \
  --gate "error_rate<1,p95<800" --junit results.xml

0 passed · 1 a threshold was breached · 2 a usage or sign-in problem · 3 the run failed or Atlas was unreachable. JUnit output drops into whatever already reports your test results. See Running in CI.

What it should always ask

• Which project, and which plan when there is more than one
• How many users, for how long, over what ramp-up
• Fixed machines or a cluster
• Confirmation before the full run
• Whether to generate test data or use yours

And what it should never do without you: start a large run, stop someone else's test, delete a file it did not just upload, or upload a plan it has not checked.

The skills behind this → · Build your own integration →