The Next Agent Session Does Not Know What Is Live

From the team behind aidrop.it — one workspace to build, host, and keep changing your code.

A fresh agent session opens the repository and starts reasoning from the code. The code is not the application. Between them sits everything that happened after the last commit: a build that failed, so the previous image is still serving; a rollback to an older tag; a port or size changed on the host; a value the app reads that exists nowhere in git.

An agent that reasons from the repository alone fixes a bug that is already fixed, reintroduces what was rolled back, or renames a variable production depends on. The fix is not a longer instructions file. It is a first step that reads the state of the running app from the host, before touching the code.

The repository is not the running app

The repository says what should run; the host knows what does. They drift apart in ordinary ways: a push whose build stopped, a deploy rolled back by tag, a branch the service follows that is not main, a setting changed without a commit. None of this is visible in git log, and all of it decides what the next change will break.

The dangerous case is a quiet one. The last three commits never deployed, because the first of them failed to build. The session reads the newest code, assumes it is live, and debugs a problem production does not have — while the real failure sits in a build log nobody opened.

Six facts to read before changing anything

A session about to change a deployed application needs six answers that only the host can give: what is running, what the last build did, whether the address answers, the settings, the value names, and the runtime's limits. Each lives outside the repository, and each changes what a correct next step is:

• The commit that is running, which is not always the head of the branch.
• The last build and why it stopped: the stage, the reason, the log.
• Whether the address answers right now, checked from outside.
• The settings it runs under: port, health path, size, followed branch.
• The names of the values it reads. Names only; a value never belongs in a session.
• What the runtime forbids: disk, writable paths, outbound traffic, replicas. Read those before writing code, not after a build dies.

Six answers take seconds to read and replace an hour of inference from source.

Write decisions down; read state live

Two kinds of knowledge get confused here. Decisions — why this queue, why that table shape, what was rejected — change rarely and belong in the repository, recorded while the reason is fresh. State — what is deployed, what failed, what is set — changes with every build, and a note about it is wrong by the next deploy.

So do not write state into an instructions file. Write the instruction to go and read it. A stale "currently deployed: v42" in a rules file is worse than nothing, because it is confident. The same logic makes the log the evidence of record: the host remembers what happened; the session should ask it.

A session-start block for your agent instructions

Paste this into CLAUDE.md, AGENTS.md or whatever file your agent reads first. It works with any host that can answer the six questions, because it asks for state instead of storing it. The command after it shows what the next deploy would ship on top of what is running now.

BEFORE CHANGING ANYTHING DEPLOYED
Read these from the host, not from the repository:
1. Which commit is running now?
2. Did the last build succeed? If not: which stage stopped it, and why?
3. Does the public address answer right now?
4. Which settings does it run under? port / health path / size / branch
5. Which value names does it read? (names only, never print a value)
6. What does the runtime forbid? disk / writable paths / egress / replicas
If any answer differs from what the repository suggests, stop and report
the difference before editing a file.

# What the next deploy ships on top of what is running
git log --oneline <running-sha>..HEAD

FAQ

Why doesn't a CLAUDE.md file solve this? A rules file holds what changes rarely: conventions, decisions, boundaries. Deployment state changes with every build, so any state written there is stale by the next deploy. The file should tell the agent where to read state, not contain it.

What does it mean when the running commit is behind the branch? Either a build failed, a deploy was rolled back, or nothing has been deployed since. List the commits between the two, find out which one did not ship and why, and decide before pushing more work on top of a history that never ran.

Should an agent ever read secret values? No. It needs the names an application reads, to know whether each exists, and never the values. A value printed into a session is recorded in the model's context and in logs that were never meant to hold it.

How does an agent read deployment state on aidrop.it? On aidrop.it, service_get answers the repository and commit, the latest build with its stage and the reason it stopped, the deployment, the address, the runtime settings, the names of the Project's values without the values, the runtime envelope, and a next_step. When the build failed, its log comes back in the same answer.