Why the Project Is Called Tokening

Long before software, a token was a small thing you handed over to stand for permission. A ticket stub. A brass check from a coat room. A wooden chip that let you take your turn at the well. The token didn’t say who you were. It said what you were allowed to do, once.

Tokening turns that into a verb. To token a task is to give it exactly the permission it needs and nothing more, then let the permission run out.

That’s what the software does. You start from a template, issue a grant for one job and hand the agent its secret. The agent shows the secret with each call. Tokening checks whether the call fits, spends a use if it does and writes down what happened. When the uses are gone or the clock runs out, so is the permission.

Not that kind of token

The word gets used for a lot of things now. There’s no coin here, no blockchain and nothing to trade. A Tokening grant secret is a bearer credential, like a password with a very short job description. Whoever holds it can try that one job, so it still deserves care, even though it’s narrow and short-lived.

It’s also not about the tokens a language model reads and writes. Agents use those too, but Tokening never looks inside the model. It only sees the calls the agent makes.

Why name the act

Most permission lives in config. An API key goes into an environment file and stays there for years, quietly allowed to do everything. Giving the act of handing out permission its own word is a small nudge to treat it as a step you take for each task, on purpose.

New task, new grant. That’s the habit the name is meant to carry.

Read how it works, or see it in the demo.