We open-sourced ApowerB because the runtime around an AI agent is too important to be a black box.

When an agent can call tools, store memory, query company data, run on a schedule and survive process restarts, the critical engineering questions move beyond the model. Teams need to understand where state lives, how tools are invoked, what happens after failure and which parts of the stack remain under their control.

ApowerB is our answer to that layer: an open-source agent runtime and platform for building and operating agents beyond the demo.

Why open source the runtime?

The model is often supplied by another provider. The business tools belong to the enterprise. The data belongs to the enterprise. We believe the runtime connecting those pieces should be inspectable.

Open source creates several useful properties:

• Inspectability: developers can review how execution, state and integrations are implemented.

• Self-hosting: teams can run the runtime in infrastructure they control.

• Extensibility: integrations and runtime behavior can evolve without waiting for a closed product roadmap.

• Portability: the application does not have to be inseparable from one model provider or one hosted control plane.

• Community feedback: production edge cases can be discussed in public rather than hidden behind product claims.

These ideas are visible across the current ecosystem. Microsoft has continued to open-source core agent infrastructure; newer runtimes such as OpenLoop, Run Core and A3T emphasize inspectability, self-hosting, memory and orchestration as part of the production agent layer.

The gap we were trying to solve

Agent frameworks make it increasingly easy to define tools, prompts and agent logic. The difficult part appears after the first successful demo.

Production raises questions such as:

• Where does session state live after the worker restarts?

• How are tool calls recorded?

• Can a failed run be safely replayed?

• How are credentials and permissions scoped?

• How does the system deploy to Kubernetes?

• How do operators understand cost and failures?

We documented several of those lessons publicly on DEV.to, including why an agent framework can stop at the demo, what a real Kubernetes deployment involves and how process restarts exposed problems in agent memory and replay.

Those field notes became a useful way to test our own claims against the code.

ApowerB is not “open source” as a marketing page

The useful part of open source is not the badge. It is that someone can inspect the system and disagree with us.

A developer should be able to ask:

• How are sessions persisted?

• What happens when a tool has already executed and a run fails?

• Which components are required to deploy?

• Where are model/provider choices configured?

• Which parts can be replaced?

If those questions cannot be answered by looking at the code and documentation, “open source” has limited operational value.

Why a runtime matters more as agents become more capable

A simple chatbot can often be treated like a request-response application. An agent that acts through tools cannot.

The runtime becomes responsible for the space between intention and consequence:

• execution lifecycle;

• state and memory;

• tool invocation;

• orchestration;

• retries and failure handling;

• observability;

• deployment.

Our reference guide on production-ready AI agents explains this architecture in more detail.

One production lesson: persistence is not enough

During one deployment audit, we saw roughly eight application restarts per day. Moving sessions from process memory into durable storage solved the obvious amnesia problem, but it exposed a harder question: if a run already called a tool before failing, is it safe to execute it again?

That led us to distinguish conversation memory from run state and real-world side effects. The full engineering write-up is available in our DEV.to incident report and in the expanded guide to AI agent state management.

Why self-hosting matters to some teams

Not every organization needs to self-host its agent runtime. Managed infrastructure can be the better operational choice.

Self-hosting becomes important when teams need:

• control over deployment topology;

• private networking requirements;

• specific data residency or integration constraints;

• the ability to inspect or modify runtime behavior;

• less dependency on one hosted platform.

Our Kubernetes deployment guide documents what self-hosting actually requires beyond a one-command install.

Open source and thaink² are complementary

ApowerB and thaink² solve different parts of the same problem.

ApowerB gives developers an open runtime they can inspect and operate. thaink² packages agentic data, analytics and knowledge experiences for enterprise teams and adds the surrounding product and service layer.

The open-source runtime also forces us to separate what is genuinely reusable infrastructure from what belongs to a specific product experience.

Inspect the runtime yourself

Explore ApowerB, read the architecture and follow the production issues in the open.

What we want from the open-source project

The goal is not to maximize the number of abstractions. It is to make the production path easier to inspect and improve.

That means prioritizing problems such as durable state, clear tool execution, provider flexibility, deployment, observability and safe operations—the parts that usually appear after an agent already works in a notebook.

It also means documenting limitations. Production agent infrastructure is still young, and pretending every failure mode has been solved would make the open-source model less useful, not more.