What CI runs when agent integrations change in git

A platform engineer merges a pull request that adds one method to the agent allowlist. The diff is twelve lines. Production starts sending refunds that afternoon because the new method was a write, the policy tests were never run, and nobody dry-ran the call. The unit tests were green. They do not know about the catalog.

This post is the check set that belongs on every commit when the integration surface is an allowlist and a policy file, not application code you wrote by hand.

What actually changes in git

An agent integration change is usually one of three files. tooling.json says which methods may run. .swytchcode/integrations/policies.json says what happens to a call before it leaves the machine. The manifest that swy get downloaded describes the provider. A prompt edit in the agent repo is a fourth change, and it can alter which of those methods the model picks. CI that only compiles the service will miss all four.

Treat the allowlist like a public API. Adding a method is a release. Removing a method is a rollback. A policy test that fails is a broken build. Policy as code is the review habit. The job below is how you stop the review from depending on someone remembering to run it.

Name the method and the argument that must fail. If a write is on the list, the test should block the argument you will not accept, such as an amount over the cap you chose. The policy overview tells you to write those tests and run swy policy validate in CI. A green unit-test suite does not run that command. The pipeline has to.

The two commands that belong on the pull request

Install the CLI in the job, then run the checks. Use one of these installs.

npm install -g swytchcode

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

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

Confirm the binary, then validate the policy file. swy policy validate checks the schema and runs the tests written in the file. The policies.json reference is the schema those tests sit on.

swy --version
swy policy validate

A failing test means the pull request does not merge. Do not treat a warning as success if the test expected a block and the file now allows the call.

Dry-run the methods the diff enabled. A dry run validates the call and does not send it. It does not count as a live command. The ID has to come from swy list methods after swy get. Do not invent one in the workflow file.

swy get <name from swy search>
swy list methods
swy exec <canonical_id from swy list methods> --dry-run

If swy get cannot download the bundle in CI because the registry name is wrong, fail the job. A green build with a missing bundle is how the method appears only on a laptop.

What you keep out of the job

Do not call the provider from CI. A live command is a request that actually went out. Refunds, emails, and ticket updates will run if the job is allowed to send them. Dry runs and swy policy validate are the commit checks. The first real send happens after merge, in an environment whose mode was set at swy init and stored in tooling.json. Read the call log after that send.

Mode is chosen once, at swy init, and written into tooling.json. Do not pass it in from a workflow variable. A pull request that changes the mode is a production change. Review it with the same care as a new method.

There is no .env file in this project. Swytchcode keeps credentials in its own local store and reads them when a call runs. A CI runner should not receive a copy of ~/.swytchcode/credentials.db. If the dry run needs a shape and not a secret, keep it that way. Provider login stays on a machine a person controls.

Approval is not a CI feature. Holding a call for Slack or Telegram starts on Business and Enterprise. If nobody answers within 48 hours, the call does not run. That wait is for production writes. It will stall a pull request if you point the job at a live approval rule. Validate the rule. Do not wait on a human inside the runner.

A job you can paste

The shape is a normal workflow. Pin the CLI version when you care about repeatability. The angle brackets are the command shape, not a real method ID.

name: agent-integrations
on: [pull_request]
jobs:
  policy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm install -g swytchcode
      - run: swy policy validate
      # Download the bundle first. Angle brackets are the command shape, not a real ID.
      - run: swy get <name from swy search>
      - run: swy exec <canonical_id from swy list methods> --dry-run

Review the diff of tooling.json the way you review a new route. If the added ID is a write, the policy tests in the same pull request should show a block, a modify, or an approval. A write with no test is an incomplete change.

Run swy policy validate on the pull request, and dry-run only the methods that diff added. Merge after both pass. Send the first live call after the merge, where a person can read the result.

Related reading

• API governance tools for AI agents. The allowlist is the surface this job guards.
• Human approval for a tool call. Where a held write belongs after the merge.
• API compliance for agent integrations. What a reviewer expects to see in the same pull request.
• API observability for AI agents. What to watch once the merged method is actually sending.

FAQ

Should the pipeline send a real provider request to prove the method works?

No. A real send can refund, email, or create a record. swy policy validate and swy exec --dry-run prove the file and the call shape. The first live call is a separate step after merge.

Where do policy tests live?

In .swytchcode/integrations/policies.json. swy policy validate checks the schema and runs those tests. A test that expected a block and now gets an allow should fail the build.

Can the runner use the same credentials as a developer laptop?

Do not copy the credential store into CI. There is no .env file in this project. Swytchcode keeps credentials in its own local store and reads them when a call runs. Dry runs should not need that store.

What if the pull request only changes the prompt?

Still run the policy check. A prompt change can make the model pick a method that was already allowed. If that method is a write, the tests you already have are what stop a bad argument. If you have no test for that method, add one in the same pull request.