Measure time to the first working agent integration

A vendor slide says you can connect an agent to your stack in an afternoon. Your platform team hears that as a promise. The next planning meeting asks for the number. Nobody has a stopwatch log. The figure in the slide came from a demo that was already authenticated, on a laptop that already had the bundle.

This post is a benchmark you can rerun. It defines the finish line, lists the commands, and tells you to write down the times you actually get. It does not invent a minute count.

Define the finish line before you start the clock

"First working integration" means all of these are true:

• The CLI prints a version.
• swy init has created the project files.
• swy get has downloaded one provider bundle you named.
• swy add has enabled one method ID copied from swy list methods.
• swy exec with --dry-run on that ID completes without sending the call.

A live call is a second measurement. It includes provider latency, OAuth consent, and whatever the provider does on a bad day. Mix that into the first number and you can no longer compare two laptops. Dry run does not count as a live command. That is why it is the finish line for the setup clock.

Write the definition at the top of the log before you install anything. If you change the definition mid-run, the number is a different benchmark.

Keep later work off this clock. Policy as code and a call log matter the week after the dry run passes. They are the next project. If you time them inside the first number, a long review looks like a slow install.

The commands, in order, with a blank time column

Install with one of these. Time the one you use. Do not add the other two into the total.

npm install -g swytchcode

irm https://cli.swytchcode.com/install.ps1 | iex

curl -fsSL https://cli.swytchcode.com/install.sh | sh

Then this sequence. The CLI getting started guide is the same path in prose. The command reference is the list if a flag surprises you.

swy --version
swy init
swy search <provider>
swy get <name from search>
swy list methods
swy add <canonical_id from swy list methods>
swy exec <canonical_id from swy list methods> --dry-run

Copy the ID from swy list methods. If search returns nothing, stop the clock and record "not in the registry." That result is a finding. Do not invent an ID to keep the timer moving.

There is no .env file in this project. Swytchcode keeps credentials in its own local store and reads them when a call runs. swy auth connect is outside this clock unless your finish line is a live call. If you add it, time it as its own row. Consent screens are not CLI time.

What you record

Use a table with one row per command. Wall time. Exit code. A note if you waited on a browser.

The total is the sum of the rows you included. Say which install you used and the date. A number without that note cannot be compared to next quarter's run.

Exclude time spent reading docs, arguing about which provider to pick, and fixing a corporate proxy. Those are real, and they belong in a second total labeled "calendar time." The command total is the one you can rerun tomorrow.

How to talk about the result

Say "on this machine, on this date, this provider, dry run passed in X." Do not say "Swytchcode takes X" as if the provider, the network, and the install path were irrelevant. If search missed the provider, the honest result is that the first working integration is blocked on a bundle. The timer did not fail. You stopped because the bundle was absent.

Two runs on the same day can still differ because the package cache was cold. Note that on the install row. Rerun once the cache is warm if that is the number you will quote. Keep both rows in the log.

Rerun the log when the CLI version changes or when you switch providers. Keep the old row. The point of a reproducible benchmark is the difference between runs, not a single slide number.

Run the eight commands on a clean machine, fill the table, and keep the log next to the version you printed with swy --version.

Related reading

• API governance tools for AI agents. Why the second week looks nothing like the first command.
• Human approval for a tool call. The extra wait a live write can hit on Business and Enterprise.
• API compliance for agent integrations. The review that starts once a dry run is no longer the goal.
• A security checklist before company data. What to settle before the first live read of customer fields.

FAQ

Why is the finish line a dry run and not a live call?

A live call depends on the provider and on consent. A dry run checks that the method is local and the call shape validates, and it does not send. You can compare dry runs across machines. Live calls need their own row.

What if swy search does not list the provider?

Stop. Record that. Business and Enterprise can bring your own provider, and that work is not part of this clock. Do not invent a method ID to finish the table.

Should I include OAuth consent in the number?

Only in a second total. Consent is a person and a browser. The command clock ends at a passing dry run unless you stated a different finish line before you started.

Can two teams compare their tables?

Yes, if both used the same finish line, named the provider, and printed swy --version. Different providers and different install paths are different benchmarks.