A useful agentic workflow has a closed feedback loop, complete context, and enough observability to debug individual components and the whole system.
2
Teams should measure loop completion time, time to detection, component error rates, human override rates, accuracy drift, context completeness, and observability.
3
Visual workflow tools become harder to maintain as node count, branching, integrations, and data transformations increase, so teams may need a formal language such as Python.
Summary
Tudor explains feedback loops through examples from BTO, where users built workflows with as many as hundreds of manually connected nodes. A good loop sends outcomes back into inputs, includes the context the system needs, and makes its behavior visible enough to debug. He applies these ideas to agents, which can repeat mistakes when loops are open, act blindly when context is missing, and become impossible to fix when they are black boxes. He recommends measuring speed, quality, and system health, then describes common failures such as unattended agents, one agent assigned too many jobs, indiscriminate feedback, and reinforcement learning without explicit rewards. The talk also introduces the experimental CLAD framework, which estimates when a visual workflow should become a formal program by considering nodes, control flow, API integrations, and data requirements.
A feedback loop improves a system by sending outputs back into its inputs
Tudor defines a feedback loop as a cycle where a system's output is used to improve its inputs and the system itself. The system can be an application, a service, or a whole business. Inputs include third-party APIs, datasets, MCPs, LLMs, and other relevant data sources. He uses reinforcement learning as an example because it has inputs, execution, and a reward that supports iterative exploration. His central claim is that tighter feedback loops produce better systems.
Good agentic loops are closed, contextual, and observable
Tudor gives three properties of a good feedback loop. Its output returns to the input so the system can improve continuously. It has complete context, meaning the relevant data sources are available. It is observable, so the team can see whether node A works, whether A and B work together, and where the system fails when node C is added. When these properties are missing, teams end up hunting for leaks instead of reasoning about the system.
Agent quality depends on measuring the loop rather than leaving it unattended
Tudor groups the health measures into speed, quality, and system health. Loop completion time shows whether the system iterates quickly enough, while time to detection shows how long failures remain unnoticed. Component error rates reveal weak links, and human override rates show whether people keep rejecting the agent's suggestions. Accuracy can drift even when the system has not changed because the surrounding world changes. He also asks whether the agent has complete context and whether its full reasoning chain can be inspected.
Several common agent designs fail because their feedback is poorly controlled
Tudor warns against deploying an agent and forgetting it, assigning one agent every kind of task, feeding every log and intermediate result back into the agent, and assuming reinforcement learning will discover the right objective on its own. His remedies are production monitoring with alerts, specialised agents, an explicit feedback schema, and defined rewards and success criteria. He gives customer satisfaction scores and error logs as examples of feedback worth retaining, rather than passing back every output.
A visual workflow should give way to a formal language when its structure becomes too large
Tudor argues that node-and-edge diagrams become verbose beyond a tipping point. A formal language such as Python can express the same workflow more concisely, with frameworks such as Airflow, Prefect, or LangChain when appropriate. The decision depends on the workflow's size and structure rather than on a fixed node count. He presents simple data synchronisation as a good fit for a visual workflow, while an advanced pricing engine with many branches, providers, and transformations belongs in formal code.
The CLAD framework estimates the tipping point across four dimensions
Tudor introduces CLAD as a work-in-progress way to assess workflow complexity. C measures the number of nodes. Logic measures conditional statements, forks, and fan-in or fan-out. API integrations count external providers, including model providers. Data requirements cover the amount of data moving through the flow and the transformations needed, such as schema changes, merging, and extraction. A matrix then maps combinations of these dimensions to increasingly complex workflow designs.
The slides themselves demonstrate a workflow that can collect feedback
Tudor says the presentation was implemented as a plain Python file using the Marimo notebook format. He describes the material as a feedback loop that can improve as he collects comments from other people. The notebook includes MCP endpoints by default without extra coding. He closes by connecting agent workflows to their compute environment, whether an on-premises cluster or someone else's cloud, and asks whether compute access is actually blocking teams.
