AgenticOS workflows and tables: build a first automation

AgenticOS has a visual workflow editor beside its agents. You can draw a known sequence of steps, call an agent where the task needs judgment and keep records in a Virtual Table. The pieces live in the same workspace, so a workflow can become a practical part of the team's work.

I build AgenticOS at Vstorm. This walkthrough shows how to configure the template, inspect its result and add an agent when a task needs interpretation. Drafted with AI assistance.

Start with an example you can inspect

The Public API → table template is a useful first task. It fetches a sample post from JSONPlaceholder and saves the title and body to a table. The result is concrete: a record you can open, with the workflow run behind it.

This deliberately starts with a deterministic example. You can see the workflow and the table without introducing a model's interpretation. An agent step can be added when a later task needs one.

You need an AgenticOS deployment and an account allowed to create workflows and create and edit tables. The template does not require a model-provider account, an API key for the sample source or a pre-existing table selection. It does still depend on the deployment being able to reach that external sample API.

Create the workflow from its template

Open Workflows and choose Workflow templates. Select Public API → table and complete the creation form. The server prepares the table and a configured draft together. The template starts private unless an explicit audience is chosen. That audience applies to the workflow and its table.

Check the name and who should be able to use it. Sharing is part of the example, not a detail to postpone until somebody receives a broken link. An ordinary colleague also needs the relevant permissions to see and use the resources.

The list distinguishes drafts, published workflows and archived ones. If a workflow seems to be missing, inspect the active filter before assuming it was deleted.

Read the canvas before changing it

Open the draft. Follow its connections from the starting point to the table write. Open each relevant step and inspect its configuration, input bindings and expected output fields. A binding explains where a value comes from. It should be possible to identify which response field becomes the record's title and which becomes its body.

The editor keeps Runs, Test draft and Publish visible. Use the unfinished-setup feedback when a required configuration is missing. The point of this first pass is to understand the example's data path before extending it.

A canvas can make a sequence visible, but the step configuration carries its actual behavior. Names and notes should help the next person connect the graph to the task it performs.

Test the draft and inspect the expected result

Use Test draft to try the current configuration. The expected result of the template is a sample record containing the fetched title and body. Open the run and the prepared table to check what happened in your deployment.

Look for the output rather than accepting a green-looking editor as evidence of completed work. If the fetch failed, inspect that step's error. If the fetch succeeded but no record appears, follow the values into the write step. Keep the failure visible until the result is understood.

Later runs of this template reuse the table and upsert the same example record. Repeating it is therefore a useful way to inspect its defined behavior, rather than assuming every execution should create a new row.

Use the table as a handover

Virtual Tables provide typed records with a schema, revisions and history. The console, agents, API clients and workflows can interact with those records through the platform's supported paths.

For the sample task, open the saved record and inspect its title and body. When turning the example into a team process, decide which fields the next person needs. A source reference and review status may matter more than adding another generated summary.

The current table implementation also records write provenance separately from the authorizing member. New writes can identify whether they came from a person, agent, workflow or API key. That gives the team a useful question to ask when inspecting a record: which process produced this value?

Publish deliberately

A workflow has a draft and published versions. Publishing freezes a version for execution. An edit to the draft is a proposed change to what will run, not proof that every existing execution has adopted that edit.

Review the example's inputs, audience and relevant settings before publishing. Use version history when investigating a later change. The record should let someone connect the behavior they observed to the version that produced it.

If the workflow is started by an automatic trigger, its active state matters separately. The editor exposes a way to pause that trigger. Pausing future starts is different from changing what an already-running task has done.

Add an agent for a task that needs interpretation

Once the sample data path is clear, consider a different example: an incoming request needs a suggested category and a source-linked handover. An agent can handle that interpretation inside a workflow that owns the surrounding sequence.

Give the agent step a specific responsibility. State its input and expected output, then bind those values to later steps. Use a draft test to check the example before treating the proposed automation as working.

A human decision can also be an explicit workflow step. When a process requires review, define what the reviewer sees and what happens after approval or rejection. A finished graph does not establish that the reviewer can make a useful decision from the information provided.

Choose the starting event for the actual job

AgenticOS workflows can start from several supported surfaces and triggers. The current documentation covers manual starts, chat, API calls, webhooks, schedules and table events, alongside additional integrations. Use the current trigger documentation for the one your task needs rather than relying on an old fixed count.

A good next example is a table record that begins a review process, or a webhook that starts triage. Keep the event, workflow run and resulting record connected so a colleague can follow the work.

The right follow-up is the next recognizable task, not every available node in one demonstration. Follow the input through the canvas, open its run and inspect the saved record. That connects the configuration to the result the next person will use.

Documentation: Workflows and Virtual Tables.