A little guidance.
A lot more possibility.

Your first task.

Start with a model you choose, a folder you control, and something useful to do.

1. Connect your model

   Open Settings → Model connections and verify a connection. In Settings → Roles, select Plan, choose Edit settings, then select the verified connection and an available model on the Model tab. Save the role. Use a general chat model with tool calling; your provider bills model usage.

2. Choose a workspace

   Select an empty folder in Work files for this trial. No order files, customer data or external system connections are needed.

3. Create two topics

   In Knowledge spaces, create a space named First task. Use New topic to create Counting object and Counting rule. Each topic creates a root node with the same name; you do not need additional child nodes.

4. Save one sample entry

   Choose Manual entry and use Monthly order count as its title. Under topic classification, select the Counting object node and the Counting rule node. An entry needs one node from each of at least two different topics. Enter the rule below, then choose Create material.

   Count unique order IDs by creation month. Show zero for months with no orders. Confirm whether cancelled orders should be excluded before calculating.

5. Assign the space and ask Plan

   Return to Settings → Roles → Plan → Edit settings → Knowledge spaces. Select First task and save the role. Start a conversation in Plan mode and send this request:

   Read Monthly order count in the First task knowledge space. Explain which fields and decisions are needed before counting, and cite the entry you actually read. Do not calculate without order data, change files or connect to business systems.

6. Check the source

   Open the cited entry and compare it with your saved rule. The answer should identify the order ID, creation month and cancellation decision. It should not invent an order total. A reply alone is not the check: confirm that the displayed source is the entry you created.

What runs where?

Workspace operations run in the environment hosting Tubun. A model request is sent to the provider you configure. A browser opened on a second computer does not automatically give the server access to that computer’s folders.

A home for the work.

Your workspace connects source material, generated artifacts, and the record of how they were made.

Set the destination first

Select a working folder before starting a file-producing task. Mention that folder in your task instructions when the output location matters. Give the agent a clear file name or naming rule, such as an order number followed by the drawing revision.

customer-orders/
├── inputs/
│   └── order-1042.json
├── drawings/
│   ├── order-1042.svg
│   └── order-1042.dxf
└── reports/
    └── order-1042-check.md

Preview before you hand over

Work files supports visual previews of SVG and DXF drawings. Use the preview to review the geometry and available views, then open the original file in your downstream engineering tool for its final checks.

Keep execution records close

Event-driven workflow runs archive their inputs, workflow snapshot, results, and delivery status under workflow-events/ in the workspace. These records help you trace a drawing back to the message that started it.

A useful handover contract

Have file-producing tasks return a file name and its absolute path. The next task can use that path to upload the artifact, while the workspace remains the primary archive.

Make expertise reusable.

Put your process, visual references, and decision rules somewhere the agent can consult again.

Structure a space around the work

A space organizes entries using knowledge dimensions and their connecting lines. Choose at least two useful perspectives: for example, a component dimension with Frame, Louver, and Post, and a design-stage dimension with Geometry, Assembly, and Inspection. An entry then describes the relevant intersection.

Use one familiar entry format

Give the entry a title, select its knowledge nodes, write the content, and add supporting images. Keep explanations, operating steps, and system connection notes in the content area. A screenshot or dimensioned reference often makes a rule clearer than a paragraph alone.

Separate input requirements from design rules

• Required inputs are values the previous system can supply and the task cannot proceed without: overall width, overall height, product type, or order identifier.
• Reference parameters are defaults or engineering choices defined by the rule, such as a standard installation angle. Explain them in the rule and allow review when the case requires it.
• Checks describe how to judge the result: unit consistency, boundary conditions, required drawing views, and missing data.

Register knowledge, load it when needed

Knowledge entries combine text and images. The default context contains the space and topic structure; relevant bodies are read on demand. Use # for explicit knowledge, / for files and @ for roles. Referencing an entire space loads its entries, so choose a specific entry when less context is needed.

Personal and team knowledge

The current preview provides knowledge spaces used by the agent’s built-in tools. Team Workflow is being designed to let administrators publish and assign shared spaces while keeping personal knowledge separate. Organization-level administration is an early access capability, not a generally available service.

A process, in plain words.

Define the result each step should produce. Let the assigned agent use the connected tools and relevant knowledge.

1. Describe the task

   Add a task node, select the agent, and describe the work. For example: “Get the latest order and return the required task parameters defined in the knowledge space.” You do not need to specify an MCP tool on every task.

2. Define the handover

   State the inputs the task receives and the outputs the next step needs. Use consistent names and types. A review task might accept orderId, widthMm, and heightMm, then return drawingName and absolutePath.

3. Add explicit decisions

   Use decision nodes to check that parameters were obtained and files were created. Route missing data or failed operations to a clear failure outcome instead of silently continuing.

4. Run a small example

   Execute the workflow with a known order, review its outputs, and verify the files in the workspace. Establish a repeatable result before attaching external message sources.

One workflow. Different ways to decide.

Use the execution mode that fits each step. Keep exact checks, fast interpretation and open-ended work visible in the same process.

Bring message parameters into a task

Declare the workflow’s event inputs, map listener message fields into them, then select those inputs in downstream tasks. A required input is checked before execution. Optional values remain optional; the task should say what to do when one is absent.

Connect the edges of your process

Listeners attach to the Start node. Triggers attach to an End node. They appear as gray external-system windows connected beside the process, and multiple windows can attach to the same start or end. They carry messages without adding an AI task to the main flow.

Let an event start the work.

Receive a message, run a workflow, and send a structured result back to your business system.

Choose a transport template

1. Configure the connection

Open Listeners & triggers and create an entry. Enter its name, choose the protocol, and fill in the relevant connection fields. HTTP listeners generate their own endpoint; HTTP triggers need a destination URL. MQTT uses a broker URL and topic. RabbitMQ uses a broker URL with a queue for listening, or an exchange and routing key for sending.

Authentication and message field settings are expandable. Referencing a connection in knowledge content is optional. New entries are disabled by default; enable one when its configuration and workflow mapping are ready.

2. Define the message contract

Declare the business fields to extract from the incoming data. Use a sample JSON object to help identify fields, then confirm the paths, types, and required values. The HTTP endpoint accepts this envelope:

Authorization: Bearer <listener-token>
Content-Type: application/json

{
  "eventId": "order-1042-revision-1",
  "data": {
    "orderId": "1042",
    "productType": "full-height",
    "widthMm": 900,
    "heightMm": 1800,
    "notes": "Review the customer's installation notes."
  }
}

eventId identifies this business event; data is the object containing the business values. Use a new event ID when the order or payload changes. Repeating the same ID with the same data on the same listener is deduplicated. Reusing that ID with different data is rejected.

3. Attach and map

Drag a listener to Start and select the configured entry. Map its fields into the workflow’s declared event inputs. In a later task, select which event inputs it should use. Attach a trigger to End and map the task outputs into the outgoing message fields.

4. Verify the whole round trip

Send a sample event using your integration tool. Check the execution record, workspace artifacts, and outgoing delivery status. A message being received or accepted by a broker does not prove that the destination business system applied the change.

Broker integrations are available in the development preview. Validate them against your own broker, authentication, and network configuration before production use.

Review the drawing you already have.

Select a knowledge space in Drawing review, load its checking rules, then select or reference a drawing and start the review. The report retains rules that need human verification.

Use a model with image support for visual review. A model or connection error is a failed review, not a passing result. DXF and DWG text extraction does not verify every geometric constraint.

Parametric authoring, baseplate editing and automatic order drawing are retired. Historical drawing files remain available for preview.

A team, working from one playbook.

The Team Workflow direction brings shared knowledge, access controls, and model operations into one administrative experience.

Configure once, assign with purpose

An administrator will manage users, shared model settings, and the capabilities each user can access. For example, an operator may only need daily tasks and Work files, while a process designer needs knowledge editing and workflow composition.

Keep everyday use simple

Users should see the tools they need for their work without needing to understand agent roles or model routing. Shared instructions provide a common standard; personal knowledge remains a separate place for daily reference.

Connect the process, not just the conversation

Listeners and triggers provide the integration boundary for events from business systems. Combined with workflows, this lets a team work toward repeatable processes such as an order import followed by notes interpretation and a structured update back to PLM.

Find the next useful check.

Start with the connection, input, or file that the failing step depends on.