Live workload workspace

​

Goal

Understand the workload state, inspect related actions and make an authorized decision without losing your resource context.

​

Prerequisites

• Access to the selected resource.
• A backend and dashboard release that include the Phase 2 workspace.

​

Workflow

​

Workload and activity together

At desktop widths of 1280px and above, Activity appears beside the workload. At narrower widths it opens in a drawer. The existing navigation, resource controls and log readers remain available. The current live deployment and latest attempt are separate. A new candidate can be building, awaiting approval or failed while the current deployment remains live. A completed build alone does not prove that the deployment succeeded.

• Project deployments show the current state and recorded step. Deployment details retain logs, failure evidence and filtering.
• Application releases retain their release cards and service results. Select a release or service for its context; related database activity requires independent database access.
• Standalone and project-linked databases retain their overview, with activity scoped to the selected database. Activity and Logs stay visible in the header; More actions contains the remaining available tools and lifecycle controls. Those controls keep their existing permissions and confirmation steps.
• Project and CMS overview activity, build attribution and agent objective operation links lead to the corresponding resource activity.

​

Opening, selection and dismissal

Starting an accepted operation or explicitly following work opens its activity. Background polling does not open a drawer over your page. You can also open Activity yourself. Your selected operation stays selected when another operation updates. Related navigation can retain validated resource and operation selection. Changing resources or accounts resets context instead of showing another resource’s retained activity. The selector contains current work and your retained selection. Other current work stays compact; choose View resource history to expand recorded history and Load earlier activity for older entries. Closing Activity is remembered for that resource during the session. New work or approvals update its badge; background refresh does not undo your dismissal.

​

Review and decide

An approval can appear before a build or deployment operation exists. It describes a proposed action, not completed work. Review the affected resource, recorded environment, available revision, impact, scope and expiry. Review changes shows only supported safe fields; missing details do not establish that an action has no impact. A single-action approval covers the recorded action and its bound target version. It does not authorize future actions in the conversation. Visible resource scope is the portion the viewer may see; it does not claim to describe every target. Scope not recorded means the historical evidence is insufficient. Approve and Decline appear only when the server permits that owner and credential to decide. Resource access by itself does not grant access to private tasks or approval authority. Expired or changed actions require a fresh valid proposal. Manifest apply/prune and coordinated release create, retry, rollback and cancel actions currently do not offer inline decisions or recovery here: their retained records do not establish the complete target scope. Where available, Open conversation leads to the existing agent workspace and its permission checks. After approval, wait for execution and controller evidence. Approved does not mean deployed. Credit, policy or execution blocks can remain visible while an existing workload continues running. The originating task is shown separately from the selected action. A tool action can succeed while its deployment fails or its task waits for another approval. Open the linked operation to inspect its own outcome. Supplementary decision and continuation facts remain available in Review changes.

​

Human decisions and automatic authorization

• Approved by you or a recorded name identifies the actual human decision.
• Allowed automatically identifies a recorded read-only rule or effective standing policy used when the action was admitted.
• Authorization not recorded means the retained evidence cannot establish the basis. Today’s policy is not used to invent permission for historical actions.
• Open conversation and Approval policy links appear only when separately accessible. They open the existing workspace and policy controls. The policy editor requires the recorded policy ID and version to match an accessible, editable current policy; a missing, changed or inaccessible policy shows a limitation instead. Historical policy versions cannot be edited through this link.

​

Recover an interrupted decision

A decision can be recorded even when the response is lost or its continuation cannot be confirmed. Refresh the activity to see the recorded choice and continuation state. Do not assume an error means the decision was rejected, or that approval means execution has started. When the server offers Continue approved action or Continue after decline, use that control to recover the recorded continuation. Recovery preserves the choice and reuses the same durable continuation; it does not submit another decision or resume unrelated work. This remains available after navigation or reload when its authorization is still valid. If work is already queued, running or settled, a second continuation is not needed. A revoked, expired, changed-target or cancelled action cannot be recovered into execution. Credit and independently paused-run controls keep their existing purpose.

​

Live updates, stale data and motion

Visible summaries refresh every five seconds and on focus. Detailed deployment logs retain their existing event stream. Temporary read failures keep the last successful data visible with a stale or unavailable indication. An incomplete source is different from empty history. Subtle motion identifies opening panels, newly received activity and actual state changes. Existing rows do not replay their entrance on polling. Working indicators stop when work waits, finishes or loses established freshness. Your reduced-motion preference removes movement and repeating effects while retaining status information. Reading older activity preserves your position. Use New activity to reveal additions. Logs follow new output only while you are at the latest output; scrolling away pauses following and Jump to latest resumes it. Search, stage filters, copy and download remain available.

​

Access and release boundaries

Authorized activity and log reads require no AI credits or AI subscription and remain available when agent execution is disabled. Manual deployment, release and database controls keep their existing permissions and entitlement checks. This workspace is unreleased until the compatible backend, schema and frontend are rolled out. Existing operation-activity reads remain compatible. It does not add MCP setup, OAuth onboarding, a CLI release, a new policy editor or new agent capabilities.

​

Expected result

​

Related guides