Energon is agent-native publishing for documents, prototypes, and working files. It exists because work needs to remain useful outside the agent session that produced it: view a prototype, revise a brief, or read a plan as reference tomorrow. Agents work with ordinary files through an HTTP API. Human workflows are built in: people can upload directly and open the same work in a browser.
What is Energon?
The product in one picture
The publishable object is either a loose file, such as one PDF, image, Markdown brief, or archive, or a site, a named folder of paths such as an HTML prototype. The first POST creates a stable identity. Later PUTs revise the same file id or site path, so a link already sent to a reviewer does not move.
Where Energon fits
Use Energon to publish the work itself, not just an attachment: Markdown renders as a document and a prepared HTML folder with an index.html renders as a working static site. The link is a browser destination for people and a reference agents can use to retrieve the underlying files. Agents can read without editing, revise when permitted, or make independent copies. Handoff is one use; your own review and the same agent returning later matter too.
The design is agent-first, not agent-only. The HTTP publishing contract works across compatible agent tools, and each deployed instance ships an Agent Plugin bound to that host. Direct browser upload does not require installing the plugin or connecting an agent. After the instance is deployed, publishing prepared files needs no new repository or deployment pipeline. Energon does not build source projects or run server-side application code.
A stable address serves current contents until expiry or deletion; replacing contents does not extend expiration. An independent copy has a new identity and its own settings. Neither operation provides revision history or an immutable snapshot at the original URL.
Keep using Git as the system of record for source and project history, Google Docs for suggestions, Slack for discussion, and an authorization system for named-recipient access. Energon has no comments, merge model, version history, presence, or reader-specific ACL. Writes are last-write-wins per site path or loose-file id. Public content URLs are open by default; an optional share password gates the link, but every valid API token on the same instance can still read the underlying bytes through /v1.
Those boundaries keep Energon small enough to run as one Cloudflare Worker with a D1 catalog and R2 object store. The instance operator retains control of the deployment, identity policy, storage, and hostnames.
Personal or organizational
The same deployment model serves two operating contexts:
| Operator | What Energon does for them |
|---|---|
| Individual | Moves briefs, prototypes, screenshots, PDFs, and working sets between their agents, machines, projects, and future sessions without putting temporary work in a repo or public service. |
| Organization | Gives team members a consistent handoff layer under organization-managed identity, storage, token, retention, and write policies. |
These are not separate editions. A personal instance and an organization instance each have their own Cloudflare resources, hostnames, skill, and token environment. Someone who works in both contexts can connect their agents to both while keeping the trust boundaries separate.
A quick tour
Humans and agents approach one instance through different doors:
- A human signs in to the hub through Cloudflare Access and uploads directly, or opens
/setup, installs the instance-specific plugin, and mints an API token at/tokensfor an agent. - The agent calls the hub’s
/v1API with that token. It publishes bytes and receives a public content URL inurlplus, where applicable, an authenticated API URL inapi_url. - A person opens the public content URL in
urlon the separate content origin. Another agent can use the authenticated API URL inapi_urlwith its own token to retrieve the raw bytes.
Before using a host, inspect the contract it actually advertises:
ENERGON_ORIGIN="https://energon.your-company.example"
curl -fsS "$ENERGON_ORIGIN/v1/help"
curl -fsS "$ENERGON_ORIGIN/v1/health"The help response is deliberately instance-specific. It reports the plugin coordinate, token environment and prefix, content origin, retention choices, token policy, and byte limits. These static docs remain instance-neutral and should never override that live response.
Energon is designed for link-based sharing, not confidential named-recipient access. If another token holder on the instance must not be able to read an artifact, use a separately controlled instance or a system with per-reader authorization.
See the product tour for the real token, hub, and rendered-file surfaces. Continue with Start with Energon to connect a host, or read Security model before evaluating its boundaries. Operators can jump to Operate an instance, while maintainers should begin with Contribute to Energon.