AgentGrid
AgentGrid is the Slab5 workspace for governed agent work. It lets teams define repeatable workflows, attach agents and tools, pause for human review, schedule recurring work, and inspect what happened after every run.
Use AgentGrid when a team needs more than a one-off chat answer. A workflow can create drafts, summarize records, prepare decisions, update workspace data, or coordinate multiple steps while preserving run state, approval state, logs, cost records, and request context.
What AgentGrid does
AgentGrid turns agent automation into an observable operating loop:
- Start from an outcome, template, or workflow definition.
- Attach approved tools and reusable agents.
- Run manually with Run Now or schedule the workflow.
- Pause at approval gates before sensitive side effects.
- Approve, reject, or ask the agent to redo work.
- Inspect workflow history, step status, logs, outputs, tool calls, retrieval hits, and cost events.
The key difference from a chat tool is durability. AgentGrid stores workflow definitions, run records, step records, approval decisions, and execution traces so builders and operators can understand what happened and safely repeat it.
Console map
The AgentGrid navigation is organized around the work a user is trying to do.
| Screen | Use it for |
|---|---|
| Overview | Understand the AgentGrid lifecycle and follow the guided first-run path. |
| Dashboard | See active runs, outstanding approvals, tool health, recent signals, credits, and recommended next actions. |
| Workflows | Create, import, publish, run, schedule, pause, resume, archive, and inspect workflow definitions. |
| Run Logs | Search and inspect raw AgentGrid run traces, including tool calls, retrieval hits, outputs, errors, and cost records. |
| Approvals | Review pending human decisions and approve, reject, or redo workflow work. |
| Tools | Connect workspace MCP tool sources, discover capabilities, and review tool approval policy. |
| Agents | Manage reusable agent roles, instructions, tool access, and publishable agent definitions. |
| Settings | Configure Slab5 managed AI or BYOK execution, default models, budgets, and deterministic-only mode. |
Templates are available from the Overview and Workflows starting paths. The primary navigation focuses on workflow creation, execution, approvals, monitoring, tools, agents, and settings.
Mental model
AgentGrid has three layers:
| Layer | Meaning |
|---|---|
| Definition | The saved workflow, agent, tool source, schedule, or template. Definitions describe what should happen. |
| Run | One execution of a workflow or agent path. Runs describe what happened this time. |
| Trace | Step logs, tool calls, retrieval hits, cost events, request IDs, input, output, and errors. Traces explain why a run behaved the way it did. |
This distinction matters when debugging. A workflow can be published and healthy while one run fails. A run can finish while a specific step records an error. A workflow can intentionally stop at an approval gate and wait for a human decision before continuing.
Workflow lifecycle
An AgentGrid workflow normally moves through this path:
- Create or import: Build a workflow in the console, start from a template, or paste a markdown workflow definition.
- Publish: Save a runnable version.
- Run Now: Queue an immediate run for testing.
- Execute: A managed worker runs the workflow steps and records durable step state.
- Approve if needed: Approval gates create queue items and pause the workflow.
- Continue or stop: Approval continues the workflow; rejection cancels the run; redo queues a revision path.
- Review history: Workflow details show recent runs, step dots, duration bars, logs, and run details.
- Schedule: Once the workflow behaves correctly, schedule recurring runs.
Common states:
| State | Meaning |
|---|---|
| Draft | The workflow is being edited or has no published runnable version. |
| Active | The workflow can be run or scheduled. |
| Queued | A manual run, schedule, retry, redo task, or approval continuation is waiting to be dispatched. |
| Running | A worker is executing the workflow. |
| Waiting for approval | An approval gate created a queue item and paused execution. |
| Completed | The workflow finished all required steps. |
| Failed | The workflow stopped with an error. |
| Canceled | The workflow was rejected, manually stopped, or canceled by policy. |
Workflows
The Workflows screen is the main management surface. Use it to create workflows, import markdown definitions, run a workflow immediately, schedule recurring work, and open the workflow detail page.
Workflow patterns
AgentGrid supports several workflow patterns. Pick the pattern based on how predictable the work is, how many agents need to participate, and whether the run should happen once, on demand, or on a cadence.
| Pattern | What it is | Pick it when |
|---|---|---|
| Step-by-step | A predictable sequence of fixed steps. Steps run in order and can include transforms, tool calls, retries, and approval gates. | The business process is known ahead of time, the order matters, and operators need a clear step-by-step run history. Good examples include content review, customer brief creation, onboarding checklists, and launch readiness flows. |
| Manager + Specialists | A lead manager agent coordinates one or more reusable specialist agents, gathers their work, and produces one audited result. | The work benefits from multiple expert roles, such as researcher, writer, reviewer, analyst, or support specialist, but the user still wants one coordinated outcome. Good examples include X post creation, campaign planning, support theme synthesis, and account research. |
| Triage | A routing workflow that classifies an intake item and sends it to the right branch, owner, specialist, or next action. | The first decision is "what kind of request is this?" or "who should handle this?" Good examples include support routing, lead qualification, incident classification, task assignment, and content intake review. |
| Scheduled workflow | A workflow that has already been tested manually and is then run on a recurring cadence, such as hourly, daily, weekly, or monthly. Scheduling is a trigger/cadence choice, not a separate runtime style. | The same work should repeat without a human clicking Run Now each time. Good examples include weekly founder briefs, daily support summaries, recurring insight refreshes, campaign monitoring, and periodic CRM follow-up planning. |
| Conversational handoff | A preview long-running assistant session where responsibility can move between agents over multiple turns. | Use only for exploratory scenarios where a conversational workflow is more important than a fixed step contract. For production workflows, prefer Step-by-step, Manager + Specialists, or Triage until conversational handoff is generally available. |
In practice, most teams should start with Step-by-step when they know the process, Manager + Specialists when they need multiple expert roles, and Triage when the workflow needs to choose the right path from an incoming request. Add a schedule only after Run Now has produced the expected output and approval behavior.
Workflow details show:
- workflow metadata and recent run summary
- a fixed step list with a horizontally scrollable run grid
- recent run columns with status dots and duration bars
- a Logs tab for selected step details
- a Details tab for workflow-level metadata, previous run state, first run, last run, and average duration
- links back to Builder and the workflow list
The run grid is intentionally compact. The latest runs appear on the right side so an operator can quickly compare the current run with prior runs.
Markdown workflow import
Workflows can also be created from a markdown definition. This is useful when a builder wants to draft a workflow with an LLM, review it as text, and paste it into Slab5.
Use markdown import as an accelerator, not as the primary authoring model. The console builder should remain the clearest place to inspect steps, approval gates, tool requirements, schedules, and run history.
Agents and tools
Agents are reusable specialists. A workflow step can use an agent when the work needs judgment, synthesis, language generation, or tool-assisted reasoning.
An agent definition should make these decisions clear:
- role and responsibility
- instructions and output expectations
- tool sources it can use
- tool allowlist and risk level
- whether it can write records or must request approval first
- whether it is ready for workflow use
Tools are workspace MCP tool sources. The Tools screen lets owners add a tool source, discover capabilities, and inspect available tools in a details modal. Read tools can be available by default; write, critical, destructive, and external side-effect tools should remain explicitly approved.
External MCP entries can be registered as metadata. OAuth or external credential exchange still needs a secure connection flow or secret reference controlled by the workspace owner.
Model providers and guardrails
AgentGrid Settings controls how workflow agents use models. The page has three responsibilities:
- Choose whether workflow execution uses Slab5 managed AI or Bring your own key (BYOK).
- Store workspace provider keys and select default models.
- Set guardrails so teams can test workflows safely and control spend.
AI execution mode
| Mode | Provider key | Billing behavior | Use it when |
|---|---|---|---|
| Slab5 managed AI | Slab5 provides the OpenAI key. | Slab5 managed AI token usage is recorded against Slab5 usage balance. | The team wants the simplest setup and does not want to manage provider accounts. |
| Bring your own key (BYOK) | The workspace provides an OpenAI or Claude key. | Slab5 records approximate BYOK token telemetry separately. Provider token charges are paid directly to the provider. Platform usage still applies. | The team wants provider control, existing provider contracts, or separation between Slab5 platform spend and model-provider spend. |
The execution mode switch is authoritative. Stored BYOK keys are ignored while Slab5 managed AI mode is selected. BYOK keys are used only when BYOK mode is enabled and a BYOK provider is selected.
Model defaults
AgentGrid Settings lets a workspace choose:
- the default provider
- the default agent model
- the coding or builder model
- the image generation model when the selected provider supports image-producing workflow steps
Reusable agents can then use the workspace defaults or choose a more specific model for their role. For example, a workflow can use a lower-cost default model for routine extraction, a coding/builder model for implementation-oriented agents, and an image model for image-producing steps.
Current supported model catalog
The current Slab5 model catalog is:
| Provider mode | Model | Best use |
|---|---|---|
| Slab5 managed AI and BYOK OpenAI | GPT-5.4 mini (gpt-5.4-mini) | General workflow agents, high-volume agent work, tools, and subagents. |
| Slab5 managed AI and BYOK OpenAI | GPT-5.4 (gpt-5.4) | Complex professional work, coding, and deeper reasoning. |
| Slab5 managed AI and BYOK OpenAI | GPT-5.3 Codex (gpt-5.3-codex) | Coding agents, builders, workflow definitions, and implementation plans. |
| Slab5 managed AI and BYOK OpenAI | GPT-5.5 (gpt-5.5) | Complex reasoning and long-horizon coding. |
| Slab5 managed AI and BYOK OpenAI | GPT-5.4 nano (gpt-5.4-nano) | Classification, extraction, ranking, and simple subagents. |
| Slab5 managed AI and BYOK OpenAI | GPT Image 2 (gpt-image-2) | Image generation and image editing workflow steps. |
| BYOK Claude | Claude Sonnet 4.6 (claude-sonnet-4-6) | Balanced speed and intelligence for agent workflows. |
| BYOK Claude | Claude Opus 4.8 (claude-opus-4-8) | Complex reasoning and agentic coding. |
| BYOK Claude | Claude Haiku 4.5 (claude-haiku-4-5) | Lower-latency workflow steps and lower-cost subagents. |
Claude providers do not currently expose a Slab5 image model default in AgentGrid Settings.
Guardrails
Guardrails help teams separate workflow design from model spend:
| Guardrail | What it does |
|---|---|
| Deterministic-only mode | Converts LLM-backed workflow modes to deterministic equivalents. Use this to test workflow structure, approvals, schedules, logs, and UI behavior without spending model credits. |
| Per-run AI budget | Sets an optional per-run budget so individual runs do not spend unexpectedly. |
| Monthly Slab5 managed AI budget | Sets an optional workspace budget for Slab5 managed AI usage. BYOK token telemetry is observed separately. |
Deterministic-only mode is useful during workflow design, QA, demos, and incident response. It does not remove workflow steps, approvals, schedules, or run logs; it changes how LLM-backed steps are executed.
Human approvals
Approval gates are workflow steps that stop execution until a human reviews the work.
Use approvals before actions such as:
- publishing content
- sending customer-facing messages
- updating CRM or support records
- making recommendations visible to a customer
- running high-impact external side effects
Approval decisions:
| Decision | Result |
|---|---|
| Approve | Marks the approval approved and queues workflow continuation after the approval step. |
| Reject | Marks the approval rejected, cancels remaining steps, and cancels the workflow run. |
| Redo task | Queues a continuation or revision run so the agent can produce a different outcome before approval. |
The Approvals screen should show enough context for the reviewer to understand what they are deciding. Instead of sending users to an app-specific draft page, the approval should summarize the work performed, the output that needs review, and the next action that will happen if approved.
Run logs
Run Logs is the raw execution trace surface. Use it when a builder or operator needs to understand what a run did at a lower level than the workflow detail grid.
Run Logs includes:
- run title, assistant type, workflow key, status, model, and provider
- input and output payloads
- workflow step records when the run is workflow-backed
- tool calls and request IDs
- retrieval hits
- token and cost events
- retry and fail actions for workflow runner runs
- mark-complete action for workflow conversation runs
Use Workflow details to understand workflow progress. Use Run Logs to inspect execution evidence.
Templates and markdown import
Templates help users start from a business outcome instead of a blank workflow. Good templates explain what they do, what tools they need, where approvals happen, and what a successful run produces.
Useful starter patterns include:
| Pattern | Outcome |
|---|---|
| X Posts Creator | Drafts social posts, pauses for approval, and continues after review. |
| Founder Brief | Summarizes workspace activity and recommended next actions on a cadence. |
| Support Insights Review | Reviews support activity and prepares themes or recommendations. |
| CRM Follow-up Planner | Reviews customer records and creates follow-up tasks. |
| Launch Checklist | Coordinates launch content, tasks, approvals, and publishing readiness. |
Markdown import complements templates. A user can copy a sample markdown workflow, ask an LLM to adapt it, then paste it into Slab5 and finish setup in the builder.
Scheduling and retries
Once a workflow has been tested with Run Now, users can add a schedule. Schedules support recurring workflow execution such as hourly, daily, weekly, and monthly refreshes, depending on the enabled cadence options.
Operational expectations:
- Scheduled runs create normal workflow runs.
- Manual Run Now creates normal workflow runs.
- Approval continuation creates a queued continuation after the approval gate.
- Redo task creates a queued revision or continuation run.
- Failed workflow runner runs can be retried from Run Logs.
- Rejected approval gates cancel the run and remaining steps.
For monthly schedules, use explicit day-of-month behavior where possible. If a team needs "last day of month", represent that as a clear schedule option instead of asking users to choose a day that may not exist in every month.
Operational guidance
- Start new users with the Overview path and a template, not a blank workflow.
- Use Workflows for definition management and workflow detail history.
- Use Run Logs for raw traces, request IDs, costs, tool calls, retrieval, input, and output.
- Use Approvals when a workflow is intentionally paused for human judgment.
- Keep approval gates before side effects, not after them.
- Prefer deterministic steps for fixed transformations and agent steps for judgment or synthesis.
- Keep step outputs structured so runs can be inspected, retried, and continued.
- Use compact step names. Operators should understand the run grid without opening every log.
- Test with Run Now before scheduling.
- Keep tool permissions narrow and workspace-scoped.
- Use request IDs to connect workflow runs to API calls, MCP calls, audit logs, usage events, and generated workspace records.
