Operating modes

There are three ways to get work done with StratoNext. They differ in who is acting and where cloud credentials come from. They are complementary, and most teams use more than one.

	Interactive session	Background agent	Your own agent
Who is acting	You, through a local coding agent	An agent StratoNext deploys in your cloud account	Your process (CI, automation) registered as an agent
Signs in with	stratonext login (browser, once)	Nothing to set up	An agent client id and secret (no browser)
Cloud credentials	Your own, configured locally	Brokered by StratoNext, short-lived	Brokered by StratoNext, short-lived
Reach	Whatever your local credentials allow	Any environment the workspace connects	Any environment the workspace connects
Interactivity	Turn by turn	Non-interactive	Non-interactive
Best for	Exploration, full-context expert work	Unattended, long-running, no local access	CI/CD, scheduled automation, embedding StratoNext

Rule of thumb: if a person is at the keyboard, run an interactive session as yourself. If nobody is, dispatch to a background agent, or run your own process as an agent.

Interactive sessions

Run an interactive agent locally (Claude Code, Codex, or any coding agent) with the StratoNext skill or the MCP server, signed in as yourself:

stratonext login
stratonext whoami     # authMode: user

You carry the work turn by turn, using your own cloud credentials: the ones already configured on your machine. StratoNext is the context and control layer: it supplies runbooks, tools, and the full picture of the project, and it records what happened. This is what turns any coding agent into a DevOps engineer that understands your whole system.

A typical session looks like this:

1. Get the context from StratoNext. The project, environment, and deployment tell you the account, region, and resources to work on.
2. Do the work under your own credentials.
3. Record the outcome on the task. Assign the task to yourself and complete it with a result, so the work is tracked like everything else:

   stratonext task complete <task_id> --result "what was done and where the output is"

Trade-offs: you must have your own cloud credentials configured, and to span several environments you have to set up credentials for each of them locally.

StratoNext does not give users cloud credentials

StratoNext issues cloud credentials only to agents working a dispatched task.

Background agents

Dispatch a task or scheduled job to an agent. The agent is deployed into your own cloud account and runs on its own, with its own credentials: it assumes the environment’s Operations Role, can escalate through approvals, and reaches any environment connected to the workspace. StratoNext manages the agent’s lifecycle, but its execution stays inside your account boundary.

Best for:

• Non-interactive work: investigations, reports, and applying approved changes.
• Long-running or scheduled jobs that should run unattended.
• Work against an account you do not have direct access to. The agent reaches it through the workspace connection, so you never need local credentials for that account.
• Fan-out: dispatch many tasks in parallel across environments.

Trade-offs: not interactive (you submit work and read results), and write or sensitive operations wait on your approval policy.

Your own agent

Here the CLI or MCP server is a registered agent rather than a person, running wherever you put it. There is no browser and no interactive step, so it works anywhere a process can run.

Your own agent does not need cloud keys of its own. When it needs to act on an environment, it asks the StratoNext credential broker, which returns short-lived, scoped credentials bound to that agent, subject to your approval policy and recorded in the audit trail. Nothing long-lived is stored on the machine, and you never copy a cloud key into a pipeline secret.

That makes it the right fit for:

• A custom agent you build and run yourself, using the locally installed StratoNext skill or MCP server to pick up dispatched tasks, work them, and report back.
• CI/CD pipelines, where a build or deploy step needs to act on an environment or report back to a task.
• Scheduled and unattended automation that nobody is watching.
• Embedding StratoNext in another product, where your software drives the platform on a customer’s behalf.

Set it up

1. Register an External agent and copy its client id and secret. Either use New Agent on the Agents page, or, once you are logged in as yourself, do it from the terminal:

   stratonext agent create --name "ci-runner" --kind EXTERNAL

   --kind EXTERNAL registers an identity only, with no runtime to deploy, so there is no environment to choose. Add --secret-expires-in-days 90 if you want the credential to expire. The secret is shown once and StratoNext keeps only a hash of it, so copy it now. If it gets away from you, delete the agent and register another.

2. Give the credential to the agent’s process. There is no login command for an agent: the CLI and MCP server act as the agent whenever these two variables are set.

   export STRATONEXT_AUTH_API_CLIENT_ID="agtc_..."
   export STRATONEXT_AUTH_API_CLIENT_SECRET="..."

   Put them where that process gets its environment: a service’s environment file, your CI’s secret store, or the env block of an MCP server entry. Avoid a shell profile you also work from, or every terminal you open becomes the agent.

   The secret is never written to disk. The short-lived token it produces is cached per agent in ~/.stratonext/agent-tokens/ and renewed automatically, so consecutive commands reuse it and the agent runs unattended. Your own stratonext login lives in a separate file, so you and any number of agents can share one machine.

3. Verify:

   stratonext whoami     # authMode: agent

How it works

An agent you run yourself collects its own work rather than being pushed to:

stratonext task list --mine --status SUBMITTED   # find work dispatched to it
stratonext task start <task-id>                  # claim it
stratonext task report-progress <task-id> "..."  # keep humans informed
stratonext credential issue --environment-id <id> --format env
stratonext task complete <task-id> --result "..."

The same loop is available as MCP tools, so an MCP host running with an agent credential can work tasks the same way.

Caution

An agent you run yourself is scoped to one workspace and counts against your agent limit. Rotate its secret from the agent’s page if it is ever exposed, and disable or delete the agent to revoke it.

Combining them

The modes are not exclusive. From an interactive session you can dispatch background tasks, using them like subagents to offload work while you keep exploring. A common setup is an interactive session on your laptop for exploration, background agents for work you lack access to, and your own agent in CI for the unattended parts. All of them appear in the same audit trail, so you can always see whether a person or an agent did something.