Certificate Renewal Desk: Expiries Worked Ahead of Time, Within the Weekly Ticket Cap
Certificates and domains are classified under the renewal policy each week, renewal tickets stay inside the cap, and a retired wildcard sends every hostname it covered back through the rules. The security lead approves each ticket before it opens.
Certificates expire on their own schedule, not the team's
The renewal policy fits on one page. A certificate within 14 days of expiry is renewed now, and one within 30 days is renewed this week. A domain with no live deployment is retired rather than renewed, and a hostname covered by an active wildcard needs no certificate of its own. What makes the week hard is everything around those rules: a cap on renewal tickets so the platform team is not buried, owners who change teams or leave, and a wildcard whose retirement quietly changes the status of every hostname under it.
The inventory lives in Airtable, renewal tickets in ClickUp, deployments in Vercel and the policy in Google Drive. The weekly digest is a document the duty engineer writes by hand from all four, while owner replies trickle in through Slack and email. When a reversal or a retirement lands mid-week, the digest and the tickets drift apart, and the certificate that finally lapses tends to be the one whose owner left months ago.
Who works in the room
People
Security engineering lead
Owns the renewal policy and the weekly ticket cap, and approves every renewal, retirement and reassignment
Platform engineer on renewal duty
Writes the weekly digest and carries out the renewals each ticket describes
Service owners
Confirm whether a domain is still in use and answer for the certificates on their services
Agents

MycoInventory classifier
Classifies every certificate in Airtable under the renewal policy, checks Vercel for live deployments and proposes the week's ClickUp renewal tickets inside the cap
Airtable
Vercel
ClickUp
Google Drive
AdaDigest reviewer
Checks the duty engineer's digest line by line against the approved list and writes the correction note, one code per wrong line
Google Drive
Airtable
NovaOwner notices
Drafts renewal and reassignment notices for a person to send, and prepares the per-owner close-out posts
The team keeps one Kylon room for renewals, with Myco as its default agent, so a question about a certificate or the queue goes to Myco without anyone naming it. The room guidelines give digest review to Ada and anything addressed to an owner to Nova, so those requests route to them. Once the lead approves the week's list, Myco opens a thread for Ada whose first message is the brief: the approved actions, the cap and the carry-forward list, so the review starts from the same numbers.
A renewal week, Monday to close-out
An automation opens the week every Monday morning. Each stage below ends with a person, and nothing is written to Airtable or ClickUp until that person approves it in the thread.
- Agent works
- Person decides
- Arrives or gets recorded
flowchart TD
week([An automation opens the week])
classify["<b>Myco</b> classifies every certificate<br>under the renewal policy"]
ok1["<b>Security lead</b> approves the actions"]
tickets["<b>Myco</b> ranks renewals by expiry<br>and proposes tickets inside the cap"]
ok2["<b>Security lead</b> approves the tickets"]
created([Tickets are created in ClickUp,<br>the rest queue for next week])
digest["<b>Ada</b> checks the digest and codes<br>each wrong or missing line"]
correct["<b>Duty engineer</b> corrects it,<br><b>security lead</b> confirms"]
reversal["<b>Myco</b> re-runs certificates an<br>owner's reversal touches"]
wildcard["<b>Myco</b> re-runs certificates hit by<br>a departure or a retired wildcard"]
ok3["<b>Security lead</b> approves<br>the changed records"]
ok4["<b>Security lead</b> approves,<br><b>new owner</b> confirms"]
posts["<b>Nova</b> drafts one close-out post<br>per owner from Myco's tally"]
ok5["<b>Security lead</b> approves<br>before the posts go to Slack"]
week --> classify --> ok1 --> tickets --> ok2 --> created --> digest --> correct
correct --> reversal & wildcard
reversal --> ok3
wildcard --> ok4
ok3 & ok4 --> posts --> ok5
class classify,tickets,digest,reversal,wildcard,posts agent
class ok1,ok2,correct,ok3,ok4,ok5 person
class week,created 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 |
|---|---|---|---|
| Classification | Every certificate gets an action under the policy: renew, check only, covered by a wildcard, retire or reassign | Myco, from Airtable records, Vercel deployments and the policy in Google Drive | The security lead approves the actions |
| Ticket allocation | Renewals are ranked by expiry, the first twelve become ClickUp tickets and the rest queue for next week in the same order | Myco | The security lead approves before any ticket is created |
| Digest review | The duty engineer's digest is checked against the approved actions, and each wrong or missing line gets a code | Ada | The duty engineer corrects the digest and the lead confirms |
| Owner reversals | An owner who shows a domain is still in use, or no longer needed, moves that certificate between renew and retire | Myco, then Nova for the reply | The security lead approves the changed records |
| Directory and wildcard updates | Certificates of departed owners are reassigned, and a retired wildcard sends every hostname it covered back through the policy | Myco | The security lead approves and the new owner confirms |
| Close-out | One summary per owner lists their certificates, the action taken and anything carried to next week | Myco tallies from Airtable and ClickUp, then Nova drafts the posts | The security lead approves before the posts go to Slack |
Reversals, departures and a retired wildcard
Most mid-week changes are narrow. An owner writes in Slack that a staging domain is still used by a partner, so a retirement becomes a renewal. People operations updates the owner directory, and four certificates now belong to someone who left. Myco re-runs only the certificates each change touches and writes a short note on every Airtable record it changes, saying what moved and on whose word.
A wildcard retirement is the exception, because it reaches further than the notice suggests. When the lead retires the legacy wildcard, every hostname it covered loses that cover at once. Myco lists them all from the inventory itself, sends each one back through the full policy and ranks any new renewals against what is left of the cap. Whatever does not fit this week queues by expiry with the rest, and the run history shows exactly which records were read to build the list.
What the checks catch
- A thirteenth renewal ticket in a week capped at twelve, which waits in the queue instead of being created
- A certificate marked for retirement while its domain still has a live Vercel deployment
- Hostnames that lost their cover when the wildcard was retired, including ones the retirement notice never named
- Certificates still assigned to an owner who has left, found by checking the directory against every record and not only the ones due this week
- A digest correction note whose count per code does not match the lines it lists
What stays with people
- Approving the week's actions and every renewal ticket before it is created in ClickUp
- Deciding to retire a wildcard or a domain, and accepting an owner's evidence on a reversal
- Naming the new owner for a departed engineer's certificates
- Sending each notice to an owner, which Nova prepares as a Gmail draft
Integrations in this workflow
Kylon is not a certificate manager and it does not replace one. It reads the inventory, the tracker and the hosting platform the team already runs, and keeps the renewal work that spans all three in one room.
- Airtable holds the certificate and domain inventory, with owners, expiry dates and wildcard cover
- ClickUp carries the renewal tickets, created only after the security lead approves the week's list
- Vercel shows which domains still have a live deployment, which decides between renew and retire
- Google Drive keeps the renewal policy, the cap and the weekly digest
- Gmail sends renewal and reassignment notices once a person sends Nova's draft
- Slack is where owners answer questions and where the per-owner close-out is posted after approval
Where to start
Start with one renewal week and the Airtable base that holds your certificates. Ask the base owner to approve a lasting grant so Myco can read it from the room, put the policy and the cap in a Drive folder the room can see, and write one rule in the room guidelines: agents classify and propose, and no ticket is created and no certificate retired until the security lead approves it.
“Retiring the old wildcard used to be the change nobody wanted to own. Now it is one approval and a list of every hostname it covered.”
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 our certificate renewal desk in this Room. Take it one step at a time and wait for my OK before you move on. 1. Connect Airtable, ClickUp, Gmail, Google Drive, Slack and Vercel. Tell me which ones still need connecting. 2. Ask me who works this desk: the security engineering lead, the platform engineer on renewal duty and the service owners. Help me invite them to this Room. 3. Build a Renewal Queue App with Certificate, Owner, Expires and Status columns, one record per certificate. Fill it from the Airtable base that holds our inventory. 4. Classify every certificate under our renewal policy in Google Drive, check Vercel for live deployments, apply our rules for each certificate, rank renewals by expiry and hold the list to the ticket cap we set. Flag certificates whose owner has left and show me anything that fails or falls outside the cap. 5. Draft each week's ClickUp tickets, owner notices as Gmail drafts and close-out posts for Slack. Do not create any ticket, write any Airtable record or send anything until the security lead approves each action in the thread. 6. Write the classification order, the ticket cap rule and who approves what into this Room's guideline, so every renewal week follows the same steps. 7. After one clean week, offer to turn the opening run into an Automation. Before you start, ask me for our rules one at a time.
Your first company harness. Where humans and agents run your business together.
More Use Cases
View allAPI 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.
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.




