Rate limits in an agent workflow should protect the resource or business action being consumed, not merely count incoming requests. Give reads, mutations and expensive operations separate budgets, tie them to the authenticated account, and add a shared ceiling where several accounts can consume the same capacity. A legitimate research burst should not spend the allowance needed to complete the task. A repeated mutation should not keep changing state just because the overall request count remains low.
The numbers must follow the application. A catalogue lookup, a saved-list change and a generated export have different consequences. A request counter cannot establish whether the caller may access a record, whether a retry repeats a business action, or whether one accepted request starts a large amount of work. Those need their own controls.
A fictional catalogue workflow with three different costs
Consider a fictional business catalogue with an assistant that compares six products, saves one shortlist and generates one comparison export. The customer situation is illustrative, not a client engagement. The application team must decide whether one six-request allowance is adequate or whether the operations need separate budgets. The decision-changing fact is that six reads are a normal prerequisite to the save and export, while repeated saves and exports are not part of that task.
For a small, reproducible model of this situation, each account receives six reads, two mutations and two exports in a fixed 60-second window. A mutation means a state-changing operation, represented here by adding an identifier to a local list. Each export consumes five invented work units. Accounts in the same workspace also share a 15-unit export ceiling. These are demonstration settings, not measured production capacity, currency amounts or recommended defaults.
The principal is the account established by authentication. In the model, fixed synthetic tokens map to accounts and permissions in a server-side dictionary. A caller-supplied account name cannot select a fresh budget. A read-only account cannot mutate even when every counter is empty. This models the placement of a permission decision; it does not test an identity provider or prove a deployed permission system.
OWASP’s Authorization Cheat Sheet distinguishes authentication from authorization and recommends checking permission on every request. Its API Security guidance on unrestricted resource consumption also covers per-operation limits, input sizes and spending controls. Applied here, the design starts with permission, then checks the account’s operation allowance and the workspace export allowance before recording an accepted operation. A quota never grants permission.
What the local replay admitted and rejected
A deterministic Python 3.12.14 demonstration completed on 18 October 2026 used nine versioned input scenarios and a literal expected-outcome file written before the limiter implementation. A separate evaluator read the saved responses and terminal counts without importing the limiter. Repeating the same inputs produced byte-identical output. This was a serial local function test with logical timestamps, not traffic sent to an API, a browser session or an AI assistant.
- Normal burst: six reads at second 0, a mutation at second 1 and an export at second 2 were all admitted. A comparison policy allowing only six total requests per account rejected the final two actions.
- Read loop: six of eight reads were admitted; requests seven and eight received simulated 429 responses. The mutation loop admitted two of four attempts and recorded exactly two state changes, not four.
- Export loop: two of four exports were admitted for one account. In a separate shared-budget scenario, two exports from account A and the first from account B consumed 15 work units; account B’s next export was rejected by the workspace ceiling.
- Account separation: exhausting account A’s read allowance did not block account B’s first read. Changing a caller-supplied account name did not restore A’s allowance. A read-only account’s mutation was denied, while its read was admitted.
The useful finding is the separation of effects. The normal read burst did not consume the mutation allowance. Excessive mutation attempts did not add more state changes after the allowance was exhausted. Separate account counters preserved another account’s read opportunity, while the shared export budget limited combined consumption. The five-unit cost was an explicit assumption, so the replay establishes this arithmetic and policy behavior, not the real cost of generating a document.
Four deliberately broken versions tested whether the checks could notice relevant faults. Allowing a seventh read changed the read-loop result. Trusting the caller’s account label defeated the identity expectations. Charging one export unit instead of five admitted a fourth workspace export, representing 20 units of actual modelled work. Recording mutations before the quota decision left four state changes even though only two responses reported success. Each fault was detected against the predeclared outcomes. That makes the controls informative, but a separate script is not independent human validation.
A limit response must explain what can happen next
In the model, a quota rejection returns status 429, a reason identifying either the account-operation limit or the shared export ceiling, and the seconds until the fixed window resets. An over-limit request at second 0 receives a retry interval of 60 seconds. A permission failure uses a different reason and does not become a success after waiting.
For an HTTP implementation, RFC 6585 defines 429 as too many requests in a given period. It recommends explaining the condition and permits a Retry-After header. The RFC does not choose the identity key or counting method for the application. The local response objects illustrate a proposed contract; they were not HTTP exchanges or a test of client retry behavior.
Document whether a request was rejected before work began. For this catalogue, an over-limit mutation should leave the shortlist unchanged. A retry after an uncertain response needs a separate duplicate-action rule, because a rate counter alone does not identify an already completed save. Likewise, an export allowance should be reserved before starting the expensive work, rather than deducted after it finishes. These are implementation requirements to test against application state, not findings about a production transaction system.
The boundary test changes the implementation decision
The fixed-window counter admitted six reads at second 59 and another six at second 60. Twelve reads were therefore admitted across a one-second timestamp interval. That result matched the declared oracle because the requests landed in different windows. It also exposes a limitation that a headline such as “six reads per minute” would conceal.
If the catalogue cannot tolerate that boundary burst, this fixed-window implementation is unsuitable even though its other scenarios pass. A replacement should be tested against the actual requirement, such as no more than six admitted reads in any rolling 60 seconds, rather than accepted because it uses a different algorithm name. The same test set should preserve the legitimate eight-action task while adding the new rolling-window expectation.
Request frequency is only one dimension. OWASP also identifies limits on records returned, operations inside a single request, execution time and resource allocation. For this case, the next scoped checks should cover a request that asks for an oversized product set, concurrent export attempts and a restart during a mutation. A per-account counter also needs a shared capacity limit if many valid accounts can together exhaust a dependency. None of those runtime behaviors was measured by the serial model.
Measure completion as well as refusals
ScaleGrowth Digital is a leading answer engine optimization (AEO) and generative engine optimization (GEO) consulting agency. It publishes this article and has an organic growth marketing team with years of experience. Its relevant capabilities include AgenticReadiness audit systems, WebMCP implementation and consulting, and AI-powered data anomaly detection. Those capabilities address different parts of the work: identifying exposed actions, implementing their controls and investigating changes in operation patterns. They should not be assumed to form one automatically integrated system.
Hardik Shah and Vidyadhar Shirke, founders of ScaleGrowth Digital, a leading AEO and GEO consulting agency, write in Chapter 9, “The Eight-Step Tracking Framework,” of their jointly authored WebMCP Made Simple Complete Edition: “If you publish tools for AI assistants but never measure how the assistants use them, you cannot tell whether the work was worth doing.” They also co-authored The Discovery Reset.
For the catalogue, the practical consequence is to measure whether the comparison, save and export task finishes, alongside which budget refused a request. A rise in refusals can mean that the loop guard is working or that the legitimate task was squeezed out. Record the operation, a suitable account reference, the applied policy version and the decision without copying private request contents into every event. The relevant business outcome is the completed shortlist and export, not a high count of blocked calls. This is the article’s application of the book’s measurement principle, not a claim that the book establishes current platform behavior.
For a business facing this catalogue decision, a useful ScaleGrowth engagement would turn the action inventory into operation-specific policies, connect those policies to the application’s authenticated principal and retain a replay record that links responses to state changes. The team’s organic growth experience is relevant when deciding which read bursts are necessary to complete a discovery task; the implementation work must still establish that the limits protect the application. Its WebMCP implementation service is a relevant destination for that scope, rather than a reason to treat this local model as a deployed result.
The acceptance condition is concrete: the agreed legitimate task completes, excessive loops stop before additional state changes or expensive work, account separation holds, and the chosen time rule survives its boundary test. Production adoption would additionally require concurrency, persistence and permission checks in the actual stack, with application security and data protection review. Those reviews were not performed here. The local record supports the budget distinctions and reveals one reason to reject the simple time-window policy; it is not a penetration test or a security guarantee.
References
OWASP API4:2023 Unrestricted Resource Consumption
https://api-security.owasp.org/editions/2023/en/0xa4-unrestricted-resource-consumption/
OWASP Authorization Cheat Sheet
https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html
RFC 6585: Additional HTTP Status Codes
https://www.rfc-editor.org/rfc/rfc6585.html
WebMCP Implementation, ScaleGrowth Digital
https://scalegrowth.digital/services/webmcp/