Agentic Workflows: A Purist Approach

We run both patterns in production. They share the same MCP tool surface, the same API integrations, and the same execution infrastructure. Different trade-offs, same harness.

The Spectrum

Traditional workflow engine — N8N, Zapier, Airflow. Define nodes, connect edges, compile a static graph. Runs the same way every time. Environment changes or an unanticipated exception? The workflow breaks. Edit the graph, redeploy.

Middle of the spectrum: workflows that embed an LLM at certain nodes. The graph is still static, but individual steps can reason. Useful. Handles variability at specific decision points without rewriting the flow.

That last one is one of the patterns we run. The other is compiled skills — deterministic Python that runs on a cron with bridged API access, schedulable, chainable, and composable without an LLM in the loop.

Wake-Up Calls (Agent-as-Workflow)

The implementation is straightforward. We call them wake-up calls.

User works through a complex, multi-step task with an assistant. Human guidance along the way — corrections, clarifications, refinements. The assistant learns which data sources matter, what format the output should take, which edge cases to watch for, who to notify and when.

Once it's working, the user says: "Run this every Monday at 8am."

One instruction. The assistant schedules a wake-up call and the live chat session becomes a recurring autonomous workflow.

Under the hood:

1. The assistant schedules a follow-up with a context memo — natural-language instructions, written by the assistant for its future self.
2. At the scheduled time, the scheduler fires and inserts the memo into the durable prompt queue — a MongoDB-backed intake that works identically whether the browser is open or closed.
3. The queue drains into a headless subagent run. Full conversation history available — every correction, every refinement, every lesson from the original session and all prior iterations.
4. Does the work. Assesses conditions. Takes actions across connected API integrations via the code execution bridge.
5. Continues the workflow or delivers a final response. Binary exit.

No DAG compiler. No node editor. The workflow lives in the conversation history and the context memo. The durable prompt queue guarantees delivery regardless of browser state — wake-ups, webhooks, and external nudges all flow through the same path.

Compiled Skills (Deterministic Automation)

The other path. No LLM in the loop at runtime.

A skill is a self-contained Python module that runs in a sandboxed container with bridged API access. The assistant helps build and test it — discovers available APIs, verifies tool signatures, iterates on the code — then compiles and publishes it as a reusable unit.

The workflow:

1. Design — skills_workflow_designer breaks a complex automation into composable skills, event sources, and wiring. Produces a structured architecture plan with HITL/AITL guidance.
2. Discover — list_api_servers finds available integrations (Gmail, Jira, Slack, GitHub, etc.). tools_search drills into specific tools. get_tool_info returns exact parameter signatures.
3. Build — skills_compile validates the code in a sandbox, checks imports against real API servers, and saves a draft. Every skill declares input parameters for composability — the compile contract.
4. Test — skill_run_now fires the skill in an isolated container with injected API keys.
5. Publish — skills_publish promotes the draft. The skill is now schedulable, chainable, and importable by other skills.
6. Schedule — skill_schedule puts it on a cron. Recurring execution, no agent, no LLM cost per run.

Every skill runs in a sandboxed container with no outbound network — only bridged APIs have connectivity. The bridge handles auth, rate limiting, and discovery. Pre-installed libraries cover the common surface: pandas, matplotlib, playwright, reportlab, openpyxl, boto3, and the major LLM SDKs (openai, anthropic, google-genai) for skills that need embedded reasoning at specific steps.

The Intelligence Is in the Workflow

For compiled skills: the intelligence was in the design. The assistant and the human collaborated on the logic, tested it, and froze it. The skill executes the same way every time — fast, cheap, deterministic. When the world changes, you iterate on the skill with the assistant and republish.

We call these intelligent workflows. Not because they use an AI model somewhere in the stack — because the intelligence is either embedded in the execution surface itself (wake-ups) or captured at design time and compiled into reliable automation (skills).

In-Context Learning as Memory

For agent-driven wake-up workflows, the conversation thread is the memory. This matters more than it seems.

Third run of a workflow — full transcript of runs one and two in context. Something went wrong on run two? Data source returned an unexpected format, notification went to the wrong channel, calculation was off? That mistake and its correction are right there in the history.

The assistant doesn't repeat mistakes visible in its own conversation. In-context learning, purest form. No fine-tuning, no external memory system, no retrieval pipeline. The history is literally in the stack. Past corrections persist in the same chat session and inform every subsequent execution.

Each iteration makes the next one better. Not through a training loop — through the simplest mechanism available: the assistant reads what happened last time and adjusts.

For Engineering Teams: Connect via MCP

The platform tools are served via a real MCP server that engineers can connect to directly — no UI required. Two transport options:

Both expose the same tool surface: subagent dispatch, scheduling, asset management, workspace operations, notifications, email, chat history search, and the full platform tool set. The code execution bridge adds sandboxed Python with bridged API access, skills lifecycle, and workflow composition.

The Trade-Offs

More expensive per run — there's an LLM reasoning through every iteration. But the savings come from redirecting human effort. The agent delivers outcomes, not summaries. That math works out for most recurring operational tasks.

Both concerns are real. The architecture doesn't force a choice — use wake-ups where adaptation matters, skills where determinism matters, and graduate from one to the other as the task stabilizes.

Because there's no compiled flow logic between the model and the work in wake-up workflows, nothing limits increasing model capability. When the model gets smarter, the workflows get smarter. Automatically. No redeployment, no graph updates, no code changes. Anything that limits intelligence — rigid graphs, compiled flow logic, hardcoded decision trees — is technical debt the moment the next model ships.

Skills vs. Wake-Up Workflows

Different tools, different jobs.

Natural progression: start with a wake-up workflow. Set it up in a single conversation. If the task stabilizes and the steps stop changing, graduate it to a compiled skill. The assistant that helped you build the wake-up workflow can help you compile it into a skill, test it, and schedule it.

When to Use Which

• The task benefits from judgment and adaptation, not just execution
• Steps may evolve based on changing conditions
• You want something running today, not after a development cycle
• Exceptions and edge cases are expected, not exceptional
• The cost of an occasional imperfect run is lower than the cost of building compiled logic

• The logic is stable and well-understood
• You need deterministic, repeatable execution
• Cost per run matters (no LLM inference)
• The task needs to chain with other skills via event sources
• You're agentifying CI/CD or internal tooling and want reliable automation

• You're an engineering team with your own agent harness
• You want to integrate platform capabilities into existing pipelines
• You need programmatic access to the skill and scheduling infrastructure
• You're building custom automation on top of the platform's API surface

Try It