Test, build and deploy

Work from the node's own directory, containing agentnode.yaml and .atfg.toml.

Use the node manifest & configuration reference for entrypoints, capacity, smoke input, secrets, outbound hosts and dependency settings.

Test and build

atfg doctor --local
atfg build

Build checks the manifest, pinned dependencies, secret files, tests and lint. The CLI selects the managed Python environment created by the installer. No activation is required.

Keep one node per directory. Creating a node inside another node can accidentally bundle both and cause test collisions. Team/project names describe ownership; they do not require a matching nested directory tree.

Deploy to dev

atfg --env dev deploy
atfg --env dev status hello-world

Deployment uploads an immutable release and follows the rollout. New source needs a new version in agentnode.yaml. New outbound hosts or other controlled changes may require approval. Stop and follow the returned request if that happens.

Run the deployed capability

atfg --env dev run hello-world.greet '{"name":"Ada"}'
atfg --env dev logs hello-world --since 30m

Use the label and capability actually created by your node. Find the returned run ID in Console.

Retry an existing release

If source checks passed but deployment failed because the service was unavailable, recover the service first. Find the existing release ID:

atfg --env dev status hello-world --json

Then retry that release:

atfg --env dev deploy --release <release-id>

This does not rebuild, upload another release or change the version. Authorization and approval checks still apply. Do not combine --release with a directory, notes or rollback. Only a source change calls for another version.

What proves success?

This guide ends at dev. Production changes follow your team's approval and rollout process.