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.

What is A2A?​

As the sophistication of AI systems grows, so has the ability to automate tasks. However, scaling multi-agent systems has been a major bottleneck for many engineers. Frameworks like LangGraph seek to solve this problem, but the framework is not very scalable and the api's don't always fit the needs of developers, can become outdated, and may introduce breaking changes...hence the need for custom agents, and modularity. A2A is an effort by Google to standardize inter-agent communication and allow developers to integrate the capabilities of various frameworks.

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.

LittleHorse Enterprises is a workflow engine company. But what is a workflow engine?

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.