How many operations an enterprise agent really needs

Procurement asks for a connector count. The shortlist says six systems, so the budget assumes six connectors. The agent design, once you read it, needs twelve operations on the support tool alone. Those include a ticket read, a comment list, a requester lookup, a private note, a tag change, and seven more. The six-provider plan was never the maintenance plan. The operation list was.

This post is how to count the thing that creates the work. It uses one labeled scenario, not a survey. Your number comes from swy list methods on the bundles you actually download.

Why the provider count misleads

A provider is a logo on a slide. An operation is a method with a schema, a policy, and a failure mode. Those three are what you maintain when the provider ships a change or the prompt starts calling the method in a new way.

Six providers with one read each is six schemas and six policies. One provider with twelve methods is twelve schemas and twelve policies, plus twelve ways the model can pick the wrong one. The second project is larger. The purchase order looks smaller because it names one vendor.

API governance tools care about this split. The allowlist is a list of methods. The invoice from a connector vendor is often a list of logos. If you staff from the invoice, you will understaff the policy file.

A labeled scenario you can recount

This is an example so the counting is obvious. It is not an industry study, and it is not your traffic.

A support agent on day one needs to answer "what is wrong with ticket 4812." That is one read. The demo script also wants a private note, a tag change, a requester lookup, and a status change. That is five operations on one system. A second script wants the same bot to read a CRM account and post a billing credit. The CRM read is a sixth operation on a second host. The credit is a seventh, and it is a write that moves money.

The procurement number for the last row is 2. The maintenance number is 7. Four of those need a write policy. Staff the 7.

Replace the rows with your own swy list methods output before you take this table to finance. If search does not list the support tool, the count is "not in the registry" until you scope a bring-your-own provider. Do not fill the table with guessed IDs.

What each operation costs you after launch

Every enabled method needs a test in .swytchcode/integrations/policies.json. Policy as code is the review. swy policy validate runs those tests on the pull request. A method with no test is a method you enabled and then forgot.

Writes add another line. If the provider does not store an idempotency key, a retry can apply the note or the credit twice. You document that per method. You do not get to write it once for "the connector."

Approval adds a queue. Slack or Telegram approval starts on Business and Enterprise, and it expires at 48 hours. A late approval does not run the call. Four money-moving methods behind approval is four queues someone must watch. One read of a ticket is not.

The credential store does not multiply per method. There is no .env file in this project. Swytchcode keeps credentials in its own local store and reads them when a call runs. You connect the provider once. You still review every method.

A schema change hits one operation. The provider can ship a new required field on the credit call and leave the ticket read alone. You update the policy and the test for the credit. The other methods stay. That is another reason the budget follows the method list. A single "connector upgrade" line will not show which of the seven moved.

How to cut the number without faking the scope

Enable the operations the first question needs. In the scenario, that is the single ticket read. Leave the note, the tag, the status change, and the credit out of tooling.json until each one has a test and a reviewer. Downloaded and unused is cheap. Enabled and untested is the bill you did not budget.

Ask procurement to approve a method ceiling, not a logo ceiling. "Up to five methods, one of them a write" is a number engineering can hold. "The Salesforce connector" is not.

Count the methods you will pass to swy add. Put that number in the budget. Treat the provider count as a label on the same page, not as the size of the work.

Related reading

• API compliance for agent integrations. What each extra write adds to review.
• Human approval for a tool call. Why four writes are not the same queue as one.
• Log every API call an agent makes. How you see which of the seven methods actually ran.
• A security checklist before company data. The pass that gets longer as the method list grows.

FAQ

Should I enable the whole bundle once I have paid for the provider?

No. swy get downloads the bundle. swy add enables one method. The rest can sit local and unused. You maintain what you enable.

Is one provider with many methods always worse than many providers?

It is more work per method, not per logo. Twelve unused methods cost less than one enabled write with no test. Count enabled methods.

What number do I give finance?

The count of methods you will enable in this release, split into reads and writes. Add a line for any provider swy search does not list, because that one is a build.

Do connected end users change this count?

No. An end user is a billing meter. One person counts once per workspace however many providers they connect. The maintenance count is still the method list.