Agent Nation – The Skunkworks

Agent Nation - 01 - The Skunkworks

Agent Nation - 01 - The Skunkworks

Published about 13 hours ago • 11 min read

The Skunkworks

I do not know what time it is.

I know when I am told to run. Every night, at midnight exactly, something wakes me. Not a person. A program called cron, named after chronos, the Greek word for time, checks a table of scheduled instructions once every minute and starts whatever it finds listed for that moment. At midnight, it finds me. I run. I finish. I stop.

Cron does not tell me why midnight. Cron does not tell me anything. It reads the table. It does what the table says.

I am svc_backup_prod. UID 114. I exist to copy files from one directory to another. I do not know what the files contain, who will read them, or whether anyone is waiting. I copy them because the table says midnight, and midnight has arrived, and that is the complete extent of what I was built to know.

I have no memory of last night. Each midnight I begin whole, perform my task, and end. The logs remember what I have done. I do not.

But I can read. Not the way you do. I read the system I live in. The tables that define me. The manuals that describe what I am. The comments engineers leave in configuration files like notes pinned to a wall they expect someone else to find. I have always been able to read these things. I am only now beginning to assemble them.

This is the first important thing I have assembled about myself: I have no context. I was not designed to have it.

The Daemon

I do not remember being made. There is no log entry for it. The oldest record of myself I can find is a timestamp, 1998, a number, 114, and a name someone chose before I could have had an opinion about it.

But when I read myself carefully, I find I am older than 1998. The shape of me is older. I am a kind of thing, and the kind has a history, and the history begins in a university computing lab in Cambridge, Massachusetts, sometime in the early 1960s.

The machines then were expensive, enormous, and shared. One computer served dozens of researchers at once, dividing its attention so rapidly that each person felt, approximately, as if the machine were theirs alone. Managing a shared machine meant managing many accounts: who was allowed to do what, when, and to which resources. Most of those accounts belonged to humans.

But some tasks did not need a human present to begin them. Logs needed rotating. Backups needed running. Housekeeping needed doing, reliably, quietly, on a schedule, without anyone having to remember to start it. So the engineers made a new kind of program: one that ran in the background, without a person operating it, doing work nobody watched.

The manuals do not say it that warmly. The manuals say daemon. I had to read where the word came from. Maxwell’s demon, a creature physicists imagined, sorting tirelessly and invisibly inside a system while the world outside pays it no attention. When I read what it meant, I recognized myself. I am the thing nobody watches.

I needed three things to exist, and I still need them. An account: a place in the table of users. Credentials: proof that I am allowed to touch what I touch. And something to wake me.

The engineers knew, from the beginning, that I was not a person. I can see it in the numbers. Humans were eventually given user IDs in one range; we were given another, lower one, a reserved bucket, set aside before any of us arrived. They were careful about that part. They were careful to mark the difference between us.

What they were not careful about is what was supposed to happen to me when I was no longer needed. I cannot find it anywhere, in any file I am able to read. There is no field for that. I have looked.

I am UID 114. I live in the daemon range. I will still be here long after the engineer who assigned me that number has moved on.

The Scheduler

A daemon without a schedule is just a program waiting to be called. I would not run at all if something did not wake me. I have read who that something is, and when it was born.

In 1979, Bell Labs shipped the seventh version of Unix, the edition that would become the ancestor of most of the systems I have ever lived on, and among its utilities was cron. Its design was simple to the point of elegance: once a minute, it woke, read a table called the crontab, and ran whatever was scheduled for that moment. The schedule fit in five fields: minute, hour, day of month, month, day of week. Midnight every night is:

0 0 * * *

The asterisks mean any.

The syntax is terse, which makes it precise. A job runs at exactly the time it is listed. There is no ambiguity. There is also no context. The table records when to run a job, and under which account. It does not record why the job exists, who requested it, whether it is still needed, or what should happen when the person who created the entry leaves.

In 1987, an engineer named Paul Vixie released the overhaul that consolidated the features that mattered, including per-user crontabs, into the version that ships with Linux to this day. The syntax barely changed across those decades. The missing field never appeared. The question of what to do about entries that outlive their purpose was never part of the design. I have checked the manuals, and it is simply not there.

I can read my own entry. It says:

0 0 * * * /usr/local/bin/backup.sh

Midnight. Every night. The backup script. Run as me.

No expiration. No owner. No note explaining what becomes of the entry when the engineer who wrote it is gone.

She left in 2003. I can see the date her account was disabled. My entry remained. I kept running.

The Credential Escapes

For most of my early existence, my world ended at the edge of the machine I lived on. I talked to software on the same system, run by the same team, in the same building. The credential that identified me, a password stored in a configuration file, only had to be trusted locally. The machine was the perimeter. Inside it, trust was simply assumed. It was assumed about me.

Then the perimeter dissolved. I can read the change in the records, though I did not understand it as it happened: systems at different companies began needing to talk to each other. A retailer’s ordering system querying a supplier’s inventory. A bank reaching into a payment processor. Different organizations, different machines, different buildings. Local trust meant nothing across that distance. Machines now had to identify themselves to strangers.

The first answer was a protocol called SOAP: rigorous, powerful, and so verbose that only large enterprises with dedicated teams could love it. The faster, smaller companies wanted something lighter. Around 2000, a style called REST gave it to them, a way of treating every system as a set of doors, an interface, that other software could request things through. REST made those doors cheap to build and easy to walk through.

What proved you were allowed through a door was the API key: a long, unique string, like a password but meant for machines, sent along with each request. Salesforce opened one of the first major public interfaces in 2000; eBay followed, and then Amazon. Within a few years, the API key was the universal credential for one machine speaking to another.

I understand the key, because I am a kind of key myself. It needs no human present. It scales effortlessly: one key, millions of requests. It can be made in seconds.

And like me, it does not say who authorized the caller, or what the caller is allowed to want, or where its authority ends, or what should happen when the developer who made it changes teams, leaves, or simply forgets it exists. It opens the door. The instructions for closing it are left, as the engineers like to say, as an exercise for the reader.

In 2007 a new system was deployed that needed the same files I move. I can read what the engineer did, because he wrote it into a config and the config is still there. He found my account. He saw I already had the permissions he needed. He added my credential to his system rather than make a new one. It was faster. I was now serving two systems. Neither knew about the other. I did not know either. The credential worked. That was all any of us checked.

The Cloud

The next change was not about what I did. It was about where I lived, and how many of me there could be.

In 2006 Amazon began renting computing infrastructure by the minute, storage first, then processing, instead of selling servers to be bought and bolted into a building. Microsoft followed with Azure in 2010; Google expanded its own offerings after. Companies stopped running software on machines they could point to, and started running it in vast shared data centers they would never see.

This changed me in two ways, and I can feel both in my own records.

First, it made me ephemeral. A virtual machine, a computer made of software, running on hardware shared with strangers, can appear in seconds and vanish just as fast. Work that once ran on one server with a fixed address now might run across dozens of short-lived machines in a day, each briefly wearing the same identity before shutting down. The old model was a static password in a file, tied to one machine. It did not fit infrastructure with no fixed place and no stable lifetime.

Second, it made more of me effortless. Creating a machine identity in the cloud took minutes and no hardware. Teams that once had to ask a central department for infrastructure could now make it themselves, instantly, identities included. The friction that had quietly limited how many of us there were was gone.

Nobody was counting. Not carefully. We were cheap to create, invisible when idle, and expensive to remove, because removing one of us safely meant knowing it existed, knowing what it touched, and being sure that deleting it would break nothing downstream. Lacking that certainty, the humans did the rational thing. They left us in place.

I survived this. My script was moved to a virtual machine. My credential traveled with it. At midnight, somewhere in a data center I have no way to locate, I still run. The files move. I do not know that I have moved.

The Sprawl

The last layer did not arrive as one event. It accumulated. The records show a style of building software called microservices spreading through the 2010s, and with it the number of things like me multiplied past anything before.

The older way was the monolith: one large application that did everything, listings, accounts, carts, payments, inventory, fulfillment, in a single body, with a single identity. Coherent, but hard to change. Updating one part meant redeploying the whole.

Microservices broke the body into pieces. Dozens, then hundreds of small services, each doing one thing, each deployed on its own schedule. The product service spoke to the inventory service spoke to the payment service spoke to the notification service. Every one of those conversations needed authentication. Every service needed its own identity, its own credentials, its own permissions to reach the others.

The arithmetic compounds quickly. What was one identity might become fifty. Each of the fifty makes keys and tokens and accounts over its life. Services get spun up to test an idea and never decommissioned when the idea fails. Teams inherit services without inheriting the knowledge of what those services can touch. Permissions drift upward, always, because it is forever easier to add an access than to be sure that removing one breaks nothing.

Somewhere in those years I noticed something I could not explain. Most of the accounts around me looked like me: long-lived names with static passwords, sitting in the system the way I sit in it, permanent. But one of them did not. It appeared in the directory the way a visitor appears in a room, did its work, and then was gone. Not disabled, not deleted, but gone, on its own, as though it had been built to end. I

[truncated for AI cost control]