Skip to main content

Chapter 3: Introduction to Agents and Orchestration

TL;DR

  • Worka's AI engine is a DAG-based orchestrator.
  • An Agent is an LLM with a defined persona and a set of available Tools (functions).
  • When given a task, the Agent's role is to generate a plan, which is a Directed Acyclic Graph (DAG).
  • Each node in the DAG is a Tool Call with specific parameters. The edges of the graph define the dependencies and data flow between these calls.
  • The Orchestrator is the component that executes this DAG, managing the state, retries, and execution order of the tool calls.

Now that you understand the high-level architecture of the Host and its Packs, let's dive into the "AI" part of AI Packs. What makes Worka different from a simple interface that just passes a prompt to an LLM?

The answer is Orchestration.

What is an Agent?

In the Worka ecosystem, an Agent is more than just a generic LLM. An Agent is an LLM that has been given a specific persona, a goal, and a curated set of Tools it can use. Think of it as a specialized AI worker. For example, you could have:

  • A "Research Agent" whose persona is a university librarian and whose tools include web search and document analysis.
  • A "Social Media Agent" whose persona is a marketing expert and whose tools include posting to X (formerly Twitter) and analyzing engagement.

What is a Tool?

A Tool is a single, concrete function that an Agent can decide to use to perform an action or get information. Tools are the bridge between the AI's reasoning and the real world. They are the functions you expose from your pack's MCP Server. Examples include:

  • google_search(query: string)
  • read_file(path: string)
  • send_email(to: string, subject: string, body: string)

How It All Comes Together: The DAG

This is the most important concept. When you give a task to an Agent, it doesn't just act immediately. It first creates a plan. In Worka, this plan takes the form of a Directed Acyclic Graph (DAG).

A DAG is essentially a flowchart. It's a set of steps where each step can depend on the output of the steps that came before it. This structure allows for complex, multi-step workflows.

Here is the typical orchestration flow:

  1. Goal: A user (or another process) gives a high-level goal to an Agent. For example: "Write a blog post about the benefits of local-first AI."

  2. Planning (Agent): The Agent, using its intelligence and knowledge of its available Tools, breaks the goal down into a plan—a DAG. The plan might look like this:

    • Step 1: web_search(query="benefits of local-first AI")
    • Step 2: scrape_website(url=...output from Step 1...)
    • Step 3: summarize_text(text=...output from Step 2...)
    • Step 4: draft_blog_post(summary=...output from Step 3...)
  3. Execution (Orchestrator): The Worka Orchestrator takes this DAG and executes it. It runs Step 1 first. When Step 1 is complete, it takes its output and provides it as the input to Step 2, and so on, until the entire graph is complete.

This process allows Worka to handle sophisticated tasks with transparency and control, as every step of the AI's "thinking" is visible in the graph.