Skip to main content

3 posts tagged with "lifecycle"

View all tags

The Recurring Task Your Agent Scheduled With Nobody To Inherit

· 9 min read
Tian Pan
Software Engineer

A user types "remind me every Tuesday to check that integration." The agent creates a cron entry, returns a polite confirmation, and the session closes. Six months later the user has changed teams. The integration was deprecated last quarter. The cron is still firing, hitting an API key that was rotated in April, into a Slack channel that was archived in May, charged to a project budget that nobody reviews. The agent did exactly what was asked. The asking is what aged badly.

This is not a bug in any particular agent. It is the shape of a category. The moment we gave agents the ability to schedule durable side effects — cron jobs, webhooks, polling loops, workflow triggers, calendar invites, recurring queries — we created a class of infrastructure that is born without a lifecycle. The create primitive is loud and easy. The delete primitive, the audit primitive, the inheritance primitive — they don't exist on equal footing, so they don't get used.

The cost is invisible until you go looking, which is exactly when nobody is looking.

Credentials Residue: The Agent You Retired Is Still Logged Into Production

· 10 min read
Tian Pan
Software Engineer

Six months after you sunset an agent, a security auditor pings the team Slack: "Why does this OAuth app still have read access to the company Google Workspace?" Nobody recognizes the app name. Someone greps the codebase — no hits. Someone checks the deploy manifests — no hits. Eventually a former PM remembers: that was the meeting-summarizer prototype, the one product killed in Q3. The user-facing surface was deleted. The OAuth grant, the service account in BigQuery, the Pinecone index, the Slack alert routing, the Datadog dashboard, the Splunk saved search, the eval dataset full of customer transcripts — all still there, all still authenticated, all still billing.

This is the credentials residue problem, and it is the dominant operational failure of the agent era. Every agent you ship provisions a halo of resources across vendors, internal services, and data systems. When you retire the agent by deleting its code, you remove maybe a fifth of what it created. The rest sits in production as ghost infrastructure, attributable to nobody, owned by nobody, and — most dangerously — still credentialed.

The AI Off-Switch That Doesn't Exist: Retiring Features After Users Co-Author the Archive

· 11 min read
Tian Pan
Software Engineer

Six months after you launched the AI writing assistant, you open the analytics dashboard and find the metric you wanted: 40% of user-generated documents on the platform now contain AI-authored prose. The board meeting calls this engagement lift. Three weeks later, the model provider raises prices, the unit economics flip, and someone asks the obvious question: can we turn it off? You go looking for the toggle and discover that it isn't a toggle. It's a migration with product, legal, and UX surfaces attached, and pulling it cleanly will take two quarters and burn political capital with three teams who didn't know they were stakeholders.

This is the part of the AI product lifecycle that nobody planned for. The launch playbook covered prompt engineering, rate limits, eval harnesses, and a kill switch for runaway costs. It did not cover what happens when users have spent half a year producing artifacts that only exist because the generator existed, and now the read path through your archive depends on a feature you want to retire. The "off switch" was conceptual: a flag in a config file. The actual decommissioning is a coordinated set of decisions about grandfathering, versioning, content provenance, and the uncomfortable conversation about whether the engagement lift was ever value or just dependency.