AgentDock: A Node-Based TypeScript Framework for Agents with Configurable Determinism

The Problem AgentDock Targets: Unpredictable Tool Execution in LLM Agents

The README frames the problem in one phrase: sophisticated agents that deliver complex tasks with configurable determinism. That is a response to a specific failure mode. An AgentNode, as the README defines it, is inherently non-deterministic because the LLM may generate a different response each time. If your agent's only structure is a prompt and a tool list, the order in which tools fire and the conditions under which they fire are decided at generation time, which makes the system hard to reason about after the fact. AgentDock's answer is to let you decide which parts of the system use LLM inference at all. Workflows can be made more deterministic through defined tool execution paths, and the README states that the overall system behavior remains predictable through structured tool interactions even when LLM components are present. The audience is TypeScript developers building backend agent services who want to keep the LLM in the loop for the parts that need judgement and take it out of the loop for the parts that do not. The README also states that AgentDock is framework-agnostic and provider-independent, which matters if you have already chosen a model provider and do not want the agent layer to dictate it. Note what the README does not do: it never states which providers are supported, or how provider selection is configured.

Nodes All the Way Down: The Architecture the README Describes

The design principles list is short and consistent. All capabilities are implemented as nodes. Tools are a specialized form of node. Types are TypeScript throughout. That gives the framework a single extension point: to add a capability, you add a node, and a tool is the same thing with a different role. The practical consequence is that a tool call and a workflow step are not two different abstractions you have to learn separately. The README's deterministic workflow example is a mermaid diagram with four boxes: Input, Process, Database, Output, with Process feeding both the database and the output. It is a generic pipeline sketch rather than a description of AgentDock's own runtime, and the README does not explain how that diagram maps onto node definitions. That is the central gap in the material. The architecture is described at the level of principles and not at the level of interfaces. The demos give a better sense of scale than the principles do. Cognitive Reasoner orchestrates seven named tools (search, think, reflect, compare, critique, brainstorm, debate) in configurable workflows, and Dr. Gregory House orchestrates search, deep_research and pubmed in a multi-stage workflow. Those tool names are the most concrete architectural evidence in the README: they show that a node's job is narrow and that composition happens at the workflow level.

Two Components, One Repository: Core and the Next.js Client

AgentDock ships as two things in one repository. AgentDock Core is the backend-first framework. The open source client is a complete Next.js application that acts as both a reference implementation and a consumer of Core, and it is the same code running at hub.agentdock.ai. Splitting them this way is a deliberate signal: Core is meant to be embedded in your own backend, and the Next.js app is meant to be read. If you are evaluating AgentDock, the client is the fastest way to see how Core is called in practice, because the README does not provide that itself. The repository layout reinforces the split. There is an agents directory holding per-agent folders such as agents/dr-house, agents/cognitive-reasoner, agents/history-mentor and agents/calorie-vision, and there is a public directory holding static assets like the logo referenced at the top of the README. The primary language listed for the repository is MDX, which is worth reading carefully. It means the largest share of tracked text is documentation and content, not framework code. For a project whose value proposition is a backend framework, that is a signal to check the TypeScript surface directly rather than trusting the documentation volume.

Getting It Running: What the README Actually Gives You

The README does not include an install command, an environment variable list, or a configuration example. It links to documentation at hub.agentdock.ai/docs and to the hosted client at hub.agentdock.ai, and it points at per-agent directories under agents/ as worked examples. That is the whole of the getting-started material in the supplied text. Anyone writing a setup guide from this README would be inventing it, so the honest statement is that the entry path runs through the docs site and the agent directories, not through the README. What you can infer from the repository layout is that each agent lives in its own folder under agents/ with the agent's definition and its tool wiring, and that the Next.js client is the runnable surface. The README does not state the package name to install, whether Core is published to a registry, or what a minimal agent definition looks like. Treat those as unknowns to resolve before you plan an integration. The one configuration concept the README does name is the level of determinism: you control which parts of the system use LLM inference. How that control is expressed, whether through a config key, a workflow definition or code, is not stated.

Configurable Determinism Is a Spectrum, Not a Switch

The README is careful about this and the care is warranted. It does not claim that AgentDock makes agents deterministic. It claims that workflows can be made more deterministic through defined tool execution paths, and that developers control the level of determinism by configuring which parts of the system use LLM inference. Read that as a spectrum. At one end, a pipeline like the mermaid example runs Input to Process to Database to Output with no model call, and behaves like any conventional workflow. At the other end, an AgentNode decides for itself what to do next, and two runs of the same input can diverge. Most real agents sit in between, and the design bet is that pinning down the tool execution path while leaving the reasoning to the model produces something that is predictable in structure even when it is variable in content. Whether that bet pays off depends on how much of your agent's value lives in the path and how much lives in the generation. For a retrieval-and-summarise agent, the path carries most of the weight and the framework's framing is a good fit. For an open-ended research agent, the path is thin and the determinism claim does less work than it appears to.

Where AgentDock Is the Wrong Tool

The README labels the project Beta. No releases were retrieved for this repository, which means there is no published version history to read for stability signals. Combined with an API surface that the README does not document, that puts AgentDock in the category of a project you evaluate against source, not against a changelog. If you need a frozen interface with a deprecation policy, this is not it yet. A second case: if your workflow is fully deterministic and has no reasoning step, the node and tool abstraction buys you nothing over a plain pipeline, and you are paying the cost of a TypeScript agent framework for a job a few functions would do. A third: if you are not working in TypeScript, the framework's type safety principle and its node definitions are not portable, and the README gives no indication of a non-TypeScript binding. Finally, the README's own framing of determinism is a limitation as much as a feature. It tells you the LLM parts stay non-deterministic. If your requirement is reproducible output for the same input, no amount of tool-path configuration gets you there while a model is in the loop, and the README says so.

The Alternative: A Conventional Workflow Engine

The obvious alternative is a general-purpose workflow engine where every step is a declared task and the LLM, if present at all, is one task among many. The difference in approach is where the non-determinism lives. In a conventional engine, the graph is the system and the model is a leaf node inside it; you cannot accidentally get a different graph from the same input. In AgentDock, the node is the system and the model can be the thing deciding which node runs next, with configurable determinism as the dial that limits how often that happens. The trade is real in both directions. A conventional engine gives you a graph you can inspect, replay and diff, and it gives you very little when the correct next step depends on the content of a previous response. AgentDock gives you that adaptability by default and asks you to narrow it deliberately. If your agent's control flow is known in advance, a workflow engine expresses it more directly. If your agent's control flow depends on what the model finds, AgentDock's node model is the more natural fit, and the determinism configuration is how you keep the parts you do know from drifting.

Maintenance, Licence and What to Verify First

The licence is MIT, which permits commercial use and modification with the licence and copyright notice retained. That is a permissive position and it is the least complicated part of adopting AgentDock; it is not legal advice, and if you are embedding the framework in a product you should read the LICENSE file in the repository yourself. On maintenance, the only dates available are structural: the repository is not archived, and the last push recorded is 2026-07-14. No releases were retrieved, so there is no version cadence to measure against, and the README's Beta badge is the project's own statement about maturity. The README also advertises an AgentDock Pro cloud platform as coming soon, with a signup for early access. That is a forward-looking product claim in the README, not a description of the open source framework, and it is worth separating the two when you assess what you are actually adopting. Before you commit, read the docs at hub.agentdock.ai/docs for the node and tool definitions, and read agents/cognitive-reasoner and agents/dr-house as the two most detailed worked examples in the README. Those directories are where the framework's real interfaces will be visible, because the README does not show them.

Editorial conclusion

Adopt AgentDock if you are building TypeScript agents and the node model plus configurable determinism matches how you already reason about tool execution. Do not adopt it if you need a stable API surface today: the project labels itself Beta, ships no retrieved releases, and the README does not document the node or tool APIs you would build against. Before committing, read the docs at hub.agentdock.ai/docs and the agents/dr-house and agents/cognitive-reasoner directories, and confirm the exact node definition and workflow configuration syntax against the source, since none of it appears in the README.

Official sources

1. AgentDock/AgentDock on GitHub
2. Issues
3. License: MIT
4. Project website
5. README