Agents, connections and release operations

The Agent Workspace in the local Workstation turns context into an operating agent. Begin with a starter, define its behavior, connect a model, give it knowledge and capabilities, try it, test it, create a release and publish it to an environment. Its application endpoint can then serve real requests. This workflow is currently available in the desktop app and the standalone server console, not the initial cloud editor.

Agent workflow

1. Behavior: describe the agent's purpose, instructions and response contract.
2. Model: connect an installed CLI, Ollama or a supported API provider and check a real response. Rehearsal is labelled and uses no model.
3. Knowledge: write or connect material, decide which agent may use it, and preview what reaches the agent.
4. Capabilities: define typed inputs and an executor. Reads can call an API; data-changing actions require explicit review of the exact arguments. The application must enforce its own user permissions and idempotency.
5. Try it and Tests: run a real conversation, inspect the context and proposed tool actions, and test expected behavior against the saved draft.
6. Releases: evaluate the exact draft and connections, create an immutable release, publish to development, then promote or roll back deliberately. Rehearsal releases cannot be published to production.
7. Integrate: copy the HTTP, TypeScript or Python example and use a scoped application credential. An application credential may serve an agent but cannot edit or publish one.

Connecting information

The desktop app can read folders and Git repositories, HTTP/JSON feeds and MCP resources. It can also connect a Postgres database (directly or over SSH), SQLite, Google Sheets or Docs. Database lookups are read-only and parameterized. Credentials live in a local vault or environment references, not in project files or Context Builds. For every connection, choose whether the agent may look up a requested record at runtime or whether the information becomes an observed knowledge layer.

Release operations

The local Registry stores verified Builds and tests them again on registration. Context Regression compares a candidate against obligations retained from the current release. Environments have separate promotion, binding and deployment steps. A Build may be promoted without changing a running route; deployment moves that route only after a healthy runtime is proven. Rollback returns to a prior immutable Build and retains the history.

An application's POST /v1/context/resolve call returns provider-neutral messages and reasons. Reporting what it actually sent to the model is optional and distinct from the engine's rendered context. Trace investigation can connect an observed failure to a confirmed Context Test; it cannot prove that an unobserved model outcome improved.

Where to go next

• Start a browser project for the core design and Build flow.
• Set up the local app for agent, connector and runtime workflows.
• Core concepts for the vocabulary behind these steps.
• SEIF protocol reference for the separate provenance and CLI foundation.