Agentic Patterns I: Safe Decision-Making

Just how much decision power should you give your agents in a business process? On one extreme, AI hype-artists claim that agents should stitch together all API's and "figure out your business process for you" without any orchestrator. On the other extreme, detractors claim that agents should not be allowed to make decisions without human oversight. In reality, by giving agents proper guardrails you can maximize user experience intelligence while minimizing mistakes (and even save tokens while you're at it!).

info

This is the first part in a four-part blog series about building agentic workflows with LittleHorse. This blog series will help you automate internal and customer-facing business processes with guardrails and security.

1. [This Post] Safe Agentic Decisions
2. [Coming Soon] Decision Workers
3. [Coming Soon] Verified Agents
4. [Coming Soon] Workflow Dispatch Agents

Last week's blog focused on the software development lifecycle: LittleHorse provides a governance harness for AI-written microservices to allow engineering teams to tackle larger problems with more success. In contrast, this new blog series takes a different angle: how should you architect end-user systems that involve agents at runtime (not development timme)? How can we build systems that maximize intelligence while reducing surface area for mistakes made by agents and minimizing token costs?

NOTE

While good and useful software can be produced by LLM's, I don't believe in wasting people's time by asking them to read AI slop. This blog was written entirely without the aid of LLM's.

Agents: Probably Intelligent

Software systems exist to serve people, free us from repetitive toil, and minimize human error. I do not enjoy writing simple CRUD endpoints on a REST API, nor do I enjoy pulling pieces of info out of an unstructured email and copying them into our CRM. Before the invention of LLM's, there was little hope of building systems which could automate these processes, but now we can!

We've built quite a few agentic workflows at LittleHorse, and today I wanted to share some thoughts about how we have maximized the intelligence of these systems while minimizing error.

note

I'm a big believer that automation will result in more jobs long term. Typewriters and automated elevators put an end to the jobs of scribes and elevator operators, but today we have far fewer unemployed people than we did before those two inventions.

The same will happen for copy-n-paste monkeys.

This blog series will start by examining differences between agents and classical software, then we'll analyze which use-cases are best for which pattern. Finally, we'll take a look at how to marry agents together with classical software to safely handle the most complex use-cases.

Agents Are Probabilistic and Flexible

Agents are probabilistic, whereas classical software is deterministic. At the core of an agentic application is a Large Language Model, which is simply an autoregressive neural network trained to predict the next token (roughly, token == word).

When agents do things, there is no guarantee that they will get the right answer. It's the same as asking a human to do something: sometimes they do the right thing, sometimes they make mistakes.

In contrast, the software systems we've relied on for the past 40 years always produce the same results when run with the same input. When they make a mistake, the mistakes are predictable and can be fixed (we call them "bugs" 😉).

Imperative classical software produces correct answers for predictable inputs. However, classical software systems struggle to handle dynamic inputs. For example, it's really hard to write a (non-AI) program which reads an email and decides whether to issue a refund, re-send a package, escalate to customer support, or simply respond with order information.

However, that is now possible today with agentic applications. LLM's excel at extracting structured data from natural prose and making decisions based on that data.

Agents Are Not Orchestrators

Due to their probabilistic flexibility, agents are not suitable to orchestrate business processes where you already know what steps must happen.

The process for transferring money from one account to another at a bank is well-known and unchanging. Sure, an agent could probably figure out calling the tools in the right order 99.9% of the time, but the 0.1% of the time when it forgets to check for balances or to handle import taxes are devastating.

Additionally, agents are typically just long-running software programs which are exceptionally susceptible to crashes and failures (due to their long-running nature and the amount of network calls they make). If the agent crashes during the middle of an important process, you're left with the question of how to identify and recover stuck processes.

This multi-step orchestration where you absolutely cannot tolerate failure is what classic software is for. As I've written before, it's a very difficult problem but is much simpler when you use an orchestrator like LittleHorse. In fact, whether you write the logic yourself or use agents to write your workflows and verify the result, LittleHorse makes it easier to achieve and verify correctness.

As an added benefit, it is far cheaper to decide your critical business process once than to pay Anthropic or OpenAI for tokens to make the same decision over and over again. Trust me, those bills can add up real quick.

Unifying Agents and Workflows

Agents and workflows are not substitutes but rather complements: LittleHorse provides a harness to integrate and govern agents safely. Many of our customers and open-source users have used LittleHorse with agents in creative ways; I plan to write about three of the most prominent ones in this blog series:

• Decision Workers: a LittleHorse Task Worker uses an AI Agent to decide which path of a WfSpec to take, reserving decisions for AI and actions for the workflow orchestrator.
• Verified Agents: LittleHorse asks two separate agents with different models to make a decision, and escalates to human oversight in the case of disagreement.
• Agentic Workflow Dispatcher: users expose workflows as tools to an agent who triages incoming requests and delegates work to LittleHorse.

In all three cases, Agents provide intelligence while LittleHorse shepherds processes to completion across multiple steps. The risk of "rogue agents" is mitigated because the agent itself doesn't need to be able to take much action: the agent simply decides what action to take, and LittleHorse can then take the action with rigid guardrails. Finally, these patterns allow our users to limit the size of the task given to the agents to be as small as possible.

Wrapping Up

This is an exciting time for builders everywhere. At small startups and large enterprises alike, agents have given builders the tools to builid much more powerful apps than ever before.

LittleHorse already powers many agentic applications by providing a harness for these distributed processes. However, I'm even more excited about our upcoming Agent Builder products in our Saddle Command Center which will make it even safer and easier to build agents. Stay tuned!

[If This Blog Were Written By an LLM]

Agents are not substitues for workflow 🤷‍♂️. They're complements 🔥. It's a paradigm shift, you're absolutely right! 🚀 💪