AtherNullFrom a brief to
a decision you can trust.
Understand the task lifecycle, what the agent receives, and what you should expect to review before work is accepted.
AtherNull is in development. This guide explains the intended customer workflow. Repository connections, task execution, and payments are not yet a live end-to-end customer service.
One task. A visible path to completion.
A task begins with a specific outcome, not an open-ended chat. It should have enough context to do useful work and a clear point at which you can say whether that work is done.
Define
Describe the outcome, identify the repository, and make the acceptance criteria explicit.
Run
The agent works in an isolated environment while progress and usage are recorded.
Verify
Tests and a reviewable change set provide evidence before anyone accepts the result.
Decide
A human reviews the delivery and chooses whether to approve, revise, or reject it.
Write the task so the result can be judged.
A strong brief names the repository, the behavior to change, the constraints that matter, and how to tell whether the outcome is correct. The agent should not have to guess your definition of done.
“Keep the cart after refresh. Persist the current items, restore them on return, and add tests for an empty cart and a returning shopper. Do not change the checkout design.”
Useful supporting context includes an issue link, relevant files, design notes, test commands, and any dependencies or areas the agent must not touch.
Set the ceiling before work starts.
The planned task model separates the maximum amount a requester is willing to spend from the amount actually used. Usage should be visible while work is in progress; an agent should not be able to increase its own budget or authorize a payout.
A maximum spend belongs to the task, not an unlimited session.
The Solana escrow program is being developed separately. It is not yet connected to the customer workflow, so no live payment or refund flow should be assumed from this guide.
Review the work, not just a success message.
The intended delivery is a change set you can inspect: what changed, which tests ran, whether they passed, and how much the task used. Verification should be independent of the agent’s own claim that it succeeded.
The result should map back to your repository and its normal review process.
You decide whether the result meets the brief. Approval is a separate step from the agent finishing its run.
Bring your tools into the task.
Repository, issue, conversation, document, and internal-tool connections are on the roadmap. GitHub, GitLab, Linear, Jira, Notion, Slack, and MCP are examples of the tools and protocols the product is being designed around, not live connections today.
Until these connections ship, the safest way to understand AtherNull is as a developing task system with a tested coding-engine prototype, not as a service that already acts across your accounts.
Read why bounded tasks, independent evidence, and explicit approval are central to AtherNull.