Workspace overview

Build with Autoglide

Follow a task
through the system.

Use this worked handoff to separate the company workspace, an execution runtime, and a connected tool. Each has a specific job and a clear result to report.

This is an architecture example, not an executable API. Autoglide has no published runtime SDK, installation package, or source license yet.

Example task

Prepare a release announcement.

TASK: Draft the release announcement
OWNER: Content role
INPUT: Approved release brief, version 3
OUTPUT: Draft under 70 words + source checklist
TOOLS: Read the approved brief only
REVIEWER: Release owner
STOP: Missing source, conflicting facts, or word limit
EXTERNAL ACTIONS: No publishing or sending

The workspace holds the assignment and review record. The runtime runs the agent. A connection, if needed, reads the approved source using a narrowly authorized account.

Request lifecycle

Every handoff needs an answer.

  1. Validate the assignment

    Confirm company membership, the task owner, permitted inputs, and available budget. Reject incomplete work before dispatch rather than asking the runtime to guess.

  2. Claim and start

    A durable queue gives the run one owner. Record a run identifier, its input version, and start state. A repeated delivery must not silently create a second run.

  3. Execute within the boundary

    The runner returns progress, tool results, and measured usage. Missing source access becomes a named blocker. Cancellation stops further tool dispatch and preserves completed output.

  4. Return evidence for review

    Attach the draft, its source checklist, and the final run state. The release owner checks the claims. Requested changes return to the same task with a clear reason.

  5. Close the task

    Keep the accepted artifact, reviewer decision, and usage with the assignment. Publishing would require its own authorized action and verification.

Integration worksheet

Answer these before writing an adapter.

  • Which account and exact read/write operations does the tool expose?
  • How are credentials granted, refreshed, and revoked?
  • What distinguishes accepted, running, blocked, failed, and completed work?
  • Can a retry repeat an external effect, and how is duplication prevented?
  • What happens to in-flight work after timeout, cancellation, or lost connectivity?
  • Which artifact and usage record prove what actually happened?

A useful integration proposal names one workflow, one runtime, its required operations, and a failure case. Source distribution, licensing, and supported installation remain release decisions; there is no command to install a production service today.