Why deterministic

Scrydon is positioned as an Enterprise Data & AI platform, not as an agentic-loop framework. Workflow execution is a deterministic DAG; agents are typed blocks invoked inside that graph; tool calls are typed APIs, not an MCP discovery protocol. This page explains the contrast and the reasoning.

Two shapes of "agentic"

Modern agent platforms cluster around two designs:

• Agentic loop (Crewai, Langgraph, MCP-driven runtimes) — the LLM is the orchestrator. On each step the model inspects state, picks the next tool, chooses arguments, observes the result, and decides again. The runtime is a while (not done) { reason; act; } loop. Powerful for exploration; non-deterministic by construction.
• Deterministic DAG with agents inside (Scrydon, and conceptually N8N / Node-Red / UiPath enriched with LLMs) — the execution graph is fixed at design time. The LLM is invoked inside an Agent block when language work needs to happen, but it does not decide which block runs next. Condition and Router blocks prune branches based on typed inputs.

Agents where language is the bottleneck; everything else stays deterministic.

Why deterministic-first for enterprise

The enterprise constraints — auditability, reproducibility, change management, RBAC, compliance evidence — pull hard toward the DAG side:

• Reproducibility. The same trigger payload on the same workflow version runs the same blocks in the same order. Runs are explainable from the trace alone; reviewers don't have to reason about why the LLM picked a different path on Tuesday.
• Authorisation is a graph property, not a turn-by-turn negotiation. Each block's permissions are declared. The policy decision point evaluates them at workflow start and issues a short-lived execution grant — the runtime never trusts identity decisions made by the model mid-loop.
• Failure modes are local. A failed block stops a known sub-graph. There is no "the agent went off on a tangent and called 14 tools" failure mode to triage.
• Cost is predictable. Blocks declare their LLM usage; you cost a workflow before you run it. Loop-driven agents make cost a function of model reasoning depth, which moves week to week.
• Compliance evidence is the trace. ISO 42001 / EU AI Act / SOC 2 controls map to "what ran, who triggered it, what data it touched". A DAG run produces that evidence by construction.

The trade-off: less open-ended exploration. Scrydon is not the right tool for "give the agent a goal and watch what happens." It is the right tool for "wire AI into a process my auditor signs off on."

Tools are typed APIs, not MCP servers

A consequence of the deterministic stance: when an Agent block needs to call out, it calls a typed tool declared by an installed vendor integration. There is no MCP server in the middle, no runtime tool discovery, no model-driven schema rewriting. Tool input and output are Zod schemas frozen at build time; the platform validates both ends.

What this buys you:

• Static analysis. The set of tools a workflow can call is enumerable from its definition. Review tooling can list it; policy can constrain it.
• No tool-schema drift. The tool catalog the model sees at inference time is the same one the platform validates against. You cannot get a runtime mismatch between what the LLM expected and what the integration accepts.
• Per-tool authorisation. Allowlists, capability scopes, and DLP wrapping attach to the typed tool, not to a transport-level protocol negotiation.

If you do want an open-ended exploration agent for one specific sub-task, build it as an Automation (Automations) — a single agent with a constrained tool list and a clear input/output contract. The DAG outside still stays deterministic; the agentic loop is a leaf, not the root.

Related

• Architecture → Agentic — the workflow engine and runtime model.
• Integrations → Capabilities — how the typed capability surface is declared.
• Security → Authorization — execution grants and the policy decision point.
• Automations — single-agent jobs, the right place for loop-shaped behaviour.