--- title: "Cloud Quota Request Workflow With AI Agents | Kylon" description: "How a platform team walks cloud quota requests against pools and budget, opens provisioning tickets and handles budget cuts and withdrawals in one Kylon room." url: "https://kylon.io/use-cases/cloud-quota-requests" language: "en" --- [HOME](https://kylon.io/)\>[Use Cases](https://kylon.io/use-cases)\>Cloud Quota Requests: Capacity Granted in Policy Order, Even When the Budget Moves Use Case8 min read # Cloud Quota Requests: Capacity Granted in Policy Order, Even When the Budget Moves Quota requests are walked against region pools and the weekly budget in a fixed order, critical grants get provisioning tickets, and pool increases, budget cuts and withdrawals re-walk only what they affect. The capacity lead approves every grant and revocation. [Get started](https://app.kylon.io/sign-up) Kylon TeamProduct November 6, 2026 ## Quota pools are finite and the requests keep coming Cloud quota is a shared pool per region with a weekly budget on top. Requests are walked in a fixed order: critical before high before normal, and earlier before later within a tier. A request is granted if its pool still has room after committed usage and the budget still covers it; otherwise it waits or is denied. Only granted critical requests get a provisioning ticket this week, while other grants ride the regular provisioning batch. The requests sit in ClickUp, committed usage comes from a baseline file in the infrastructure repository on GitHub, and the pool sizes and budget live in a Google Drive sheet. The weekly report is written by hand from all three. Then the provider raises a pool, finance cuts the budget or a team withdraws, and someone has to decide which grants still stand. The walk gets redone from memory, and the order is the first thing to go. ## Who works in the room People - Platform capacity lead Owns the pools and the walk rules, and approves every grant, revocation and provisioning ticket - Capacity analyst Writes the weekly allocation report - Requesting engineering managers Raise quota requests, set their priority and withdraw them when plans change - Finance partner Sets the weekly quota budget and confirms any cut Agents - MycoAllocation walker Walks every ClickUp quota request in priority order against pool room and budget, using the GitHub usage baseline, and proposes provisioning tickets for granted critical requests ClickUpGitHubGoogle Drive - RyanReport reviewer and notices Checks the analyst's report against the approved walk and the current baseline, and drafts grant, waitlist and revocation notices for a person to send Google Drive[Gmail](https://kylon.io/integrations/gmail) [Slack](https://kylon.io/integrations/slack) Quota requests are worked in one Kylon room, where Myco is the default agent and the only one that runs the walk, so a question about any request lands there. Ryan reviews the analyst's report and drafts every note to a requesting team, and the room guidelines say no grant, revocation or ticket goes out without the capacity lead. Myco reads the infrastructure repository through a lasting grant its owner approved for this room, so the baseline comes straight from the committed file rather than a pasted copy. When a re-walk is approved, Myco mentions Ryan with the list of teams whose requests changed. ## How the walk runs, and re-runs The walk is the same every time a pool or the budget changes. What differs is which requests it is allowed to touch. ```mermaid flowchart TD request([Quota requests land in ClickUp]) walk["Myco walks each request in priority
order against pool room and budget"] tickets["Myco proposes provisioning tickets
for granted critical requests"] approve["Capacity lead approves the walk
and each ticket"] report["Ryan checks the analyst's report
against the walk and the baseline"] grow([A pool grows or a team
withdraws a request]) cut([Finance cuts the budget]) offer["Myco offers the room to that pool's
waitlist, in original order"] grants["Capacity lead approves
the new grants"] revoke["Myco proposes revoking the latest,
lowest-priority grants"] confirm["Finance partner confirms the figure,
capacity lead approves revocations"] notice["Ryan drafts each notice
for a person to send"] close["Myco writes one line per request
with totals per pool and budget"] sign["Capacity lead signs off"] request --> walk --> tickets --> approve --> report report --> grow & cut grow --> offer --> grants cut --> revoke --> confirm --> notice grants & notice --> close --> sign class walk,tickets,report,offer,revoke,notice,close agent class approve,grants,confirm,sign person class request,grow,cut event classDef agent fill:#FFFFFF,stroke:#DCD3C8,color:#1B1712 classDef person fill:#EEF0E3,stroke:#6E7447,color:#1B1712 classDef event fill:#F4ECDD,stroke:#F4ECDD,color:#564C42 ``` | Stage | What happens | Who acts | Who decides | | --- | --- | --- | --- | | Initial walk | Each request is granted, waitlisted or denied in priority and submission order against pool room and budget | Myco, from ClickUp requests, the GitHub usage baseline and the pool sheet | The capacity lead approves the walk | | Provisioning tickets | Granted critical requests get a scheduled ClickUp provisioning ticket; other grants join the regular batch | Myco | The capacity lead approves before tickets are created | | Report review | The analyst's report is checked against the approved walk and the current baseline | Ryan | The analyst corrects the report and the lead confirms | | Pool increase | Waitlisted requests in the enlarged pool are re-walked in their original order | Myco | The capacity lead approves the new grants | | Budget cut | If grants now exceed the budget, the latest lowest-priority grants are proposed for revocation until the walk fits | Myco, then Ryan for the notices | Finance confirms the figure and the capacity lead approves each revocation | | Withdrawals | Capacity a withdrawal frees is offered to waitlisted requests in that pool only | Myco | The capacity lead approves | | Closeout | One line per request with its final state, and totals per pool and against budget | Myco, then Ryan for the summary | The capacity lead signs off | Stages of a weekly quota allocation cycle. Requests, regions, pools and budgets in this example are illustrative. ## When a pool grows or the budget shrinks A pool increase is the easy direction. Myco re-walks only the waitlisted requests in that region, in their original order, and stops when the new room runs out. Grants elsewhere do not move, and a request denied over budget stays denied, because a bigger pool does not create budget. A budget cut is the hard one, because it can take back something already promised. Myco re-runs the walk under the new budget and lists the grants that no longer fit, latest and lowest priority first, along with any provisioning ticket that would have to be cancelled. The capacity lead approves each revocation in the thread, and Ryan drafts the notice to each affected team for a person to send. Withdrawals that land the same day free room only in their own pools, and Myco offers it to the waitlist there before anything else. ## What the checks catch - Committed usage taken from an old copy of the baseline instead of the current file in the repository - A provisioning ticket for a high or normal grant, or for a critical request that was only waitlisted - Grants that no longer fit after a budget cut, including ones that already have a provisioning ticket - Capacity freed by a withdrawal offered to a request in a different region - A waitlisted request passed over in a re-walk because a later, smaller one fit first ## What stays with people - Approving the walk and every grant, revocation and provisioning ticket - Breaking a tie between two critical requests that arrived together - Confirming a budget figure, which stays with finance - Sending each grant, waitlist or revocation notice from Ryan's Gmail draft ## Integrations in this workflow Kylon is not a cloud console or a capacity planning tool, and it does not replace either. The request tracker, the infrastructure repository and the planning sheets stay where they are; the walk that ties them together happens in the room. - ClickUp - GitHub - [Gmail](https://kylon.io/integrations/gmail) - Google Drive - [Slack](https://kylon.io/integrations/slack) - **ClickUp** holds each quota request and the provisioning tickets for granted critical requests - **GitHub** holds the usage baseline that sets committed usage in each region - **Google Drive** keeps the pool sizes, the budget, the walk rules and the analyst's report - **Gmail** carries notices to requesting teams after a person sends Ryan's draft - **Slack** is where teams raise urgent requests and where Ryan shares the closeout after approval ## Where to start Choose one week and one region. Connect the ClickUp list where requests arrive, point Myco at the baseline file in the infrastructure repository, and give the room guidelines one rule: the walk order is fixed, and the capacity lead approves every grant and every revocation before a ticket is created or a team is told. > “A budget cut used to start with a blank sheet. Now it starts with the list of grants that no longer fit, in the order the policy says.” ## Set it up with your agent Open a new Room, add your agent and paste this prompt. It connects the tools, builds the App with you and asks for your rules one step at a time, and nothing goes out until a person approves it. Set-up prompt Set up our cloud quota desk in this Room. Take it one step at a time and wait for my OK before you move on. 1. Connect ClickUp, GitHub, Gmail, Google Drive and Slack. Tell me which ones still need connecting. 2. Ask me who works this desk: the platform capacity lead, the capacity analyst, the requesting engineering managers and the finance partner. Help me invite them to this Room. 3. Build a Quota Pools App with Requested, Granted, Waitlisted and Provisioned columns, one record per request. Pull open requests from ClickUp and committed usage from the baseline file in GitHub. 4. Walk each request in priority and submission order against pool room and budget from the Google Drive sheet. Critical before high before normal, earlier before later within each tier. Flag any request that fails a check and show me every proposed disposition. 5. Draft provisioning tickets in ClickUp for granted critical requests, and draft grant, waitlist and revocation notices in Gmail and Slack. Hold every ticket and notice until the capacity lead approves, and hold any revocation until finance confirms the budget figure first. 6. Write the walk order, the approval chain and who approves what into this Room's guideline so every request and re-walk follows it. 7. After one clean week, offer to turn the weekly walk and closeout into an Automation. Before you start, ask me for our rules one at a time. [Get started](https://app.kylon.io/sign-up) Your first company harness. Where humans and agents run your business together. [Get started](https://app.kylon.io/sign-up) ## More Use Cases [View all](https://kylon.io/use-cases) [ ### API Deprecation Migration: Cutoff Waves That Stay Right as Integrations Move Retiring an API version runs through one Kylon room. Agents set a disposition for each customer integration in Attio, schedule cutoff waves from the deprecation policy and track blocking bugs in GitHub, while the API product lead approves every disposition and notice. Software & SaaSEngineering operationsEmail operations ](https://kylon.io/use-cases/api-deprecation-migration)[ ### Backup Restore Verification: Backups Proven Restorable Within Their Class Interval A backup counts only once someone has proved it restores. Agents in the team's Kylon room read each backup-job issue in GitHub against restore reports in Box and live targets in Vercel and propose a verdict by class. The reliability lead approves before any issue changes. Software & SaaSIT & security operations ](https://kylon.io/use-cases/backup-restore-verification)