Colt McNealy

Among leaders and executives, there has been much recent buzz about OpenClaw in the context of enterprise automation. While Claws do give us a glimpse of what Agents can do, there are fundamental limitations to the Claw architecture when used as process orchestrators. Thankfully, there is a safer, cheaper, and more predictable way to automate processes with Agents. (And no, LittleHorse is not a competitor with Claws...as we will see in this post, LittleHorse focuses on enterprise process orchestration while Claws fit best as powerful personal assistants).

How can we mitigate issues like prompt injection, governance, and plain old integration challenges when using agents for automation? We've helped our customers overcome these problems with the Decision Workers pattern, which separates the concerns of intelligence and orchestration. In this pattern, LittleHorse WfSpecs achieve reliable and secure orchestration while Decision Workers (Agents with read-only tool access) provide the intelligence.

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!).

As I wrote last month, LittleHorse helps ensure alignment between your business goals and your software, acting as a Command Center for Business-as-Code. AI Agents are starting to unlock the production of vastly greater amounts of code than ever before, making this alignment and governance even more crucial.

The Infrastructure Software world was revolutionized by Infrastructure-as-Code, which provides observability, governance, and agility to infra teams. Analogous problems in application development are soon to be solved by a new paradigm: Business-as-Code.

Sometimes, business processes take time, and you need to wait for something to happen. It can be tricky to build backend software that reliably handles such cases; thankfully, workflow engines like LittleHorse make it a bit easier.

Retries and Dead-Letter Queues allow you to make multi-step processes reliable in the face of failure in order to avoid the Grumpy Customer Problem, but implementing them properly is quite a toil. Thankfully, LittleHorse helps keep your engineers happy by simplifying this process.

When integrating API's, we sometimes have to tie together steps that can take a long time or might not always be available. If we force the callers of our API's to wait for completion, we find ourselves with some grumpy customers. So what can we do about this?

Like the Saga Pattern, the Transactional Outbox pattern is tool for defending against data loss in your applications. In this blog we cover how it works and how to do it easier using LittleHorse.

The Saga pattern allows you to defend against data loss, dropped orders, and confused (or grumpy) customers. While useful, the Saga pattern is tricky to get right without a composer.

While they are often necessary, microservices are a headache. Fortunately, the right workflow engine (such as LittleHorse) can drastically reduce the difficulty of managing microservices.

Microservices are often necessary, but unfortunately they bring with them some baggage.

If microservices add so much complexity, why bother with the hassle?

About Helm vs Kubernetes Operators.