The enterprise harness: putting business logic to work

Key takeaways

• The enterprise harness makes company knowledge usable. Models can change while the business retains authority over the rules that govern its operations.
• Policies can become executable business rules. Aletyx AI Assistant helps translate PDFs, documents, and spreadsheets into logic the company reviews, tests, and approves before use.
• Shared decisions simplify integration and review. Applications and agents can reuse approved logic, while linked records make the evidence behind decisions easier to follow.
• Business logic expresses outcomes and obligations. A model can determine an eligible amount, require a disclosure, or restrict who participates in a decision.
• Skills guide agents; gates enforce prerequisites. We publish Decision Skills for approved rules and are implementing Verified Decision Gates that check evidence before an action is committed.
• An approval and a completed action are different facts. Accountability requires records that connect the policy, inputs, decision, fulfilled obligations, and actual outcome.

Intelligence is becoming abundant and cheap to rent. Companies can choose among powerful frontier and open-source models, then revisit those choices as the technology improves.

I find that extraordinary. It also brings me back to a question I care deeply about: how do we connect all that intelligence to the way a company actually works?

When I look at how a company treats a customer in hardship, handles an exception, or decides who can approve an action, I see years of accumulated judgment. Those choices are part of what makes that company itself.

Much of that knowledge lives in PDFs, documents, spreadsheets, existing rules and systems, and the experience of employees. A model can help people find and interpret it. Making it part of a reliable business process takes further work.

As intelligence becomes more accessible, I believe an enduring source of value will be a company’s ability to make its own operating knowledge usable, keep authority over it, and carry it forward as models evolve.

This is the conviction behind Aletyx. I want enterprises to be able to adopt new intelligence without having to reconstruct their way of doing business each time the technology changes.

An enterprise harness connects intelligence to how a company actually works. It provides the context, identity, access, and operational controls agents need. In regulated industries, one fundamental piece is company-owned executable business logic: rules that people can review, test, approve, and use to understand the decisions made in their name.

Accountability also reaches beyond the decision itself. The company needs to know which policy applied, what facts were used, who had authority, which obligations were fulfilled, and what action actually happened. Those details are how an organization can learn from a result and take responsibility for it.

Bringing experience into a new era

I have spent nearly 20 years in enterprise decision technology. My cofounders and I helped build and lead open-source business rules technology that now sees 8M+ downloads a month, and led its enterprise portfolio at Red Hat and IBM.

AI has given us new ways to approach that work, and it has also given us plenty to learn. We were demonstrating native MCP integration in spring 2025, and included it in our public launch. At QCon AI Boston in June 2026, I presented decision models as capabilities within agentic architectures.

In that session, I demonstrated a path from a spreadsheet to an executable DMN model, generated tests, and an agent invoking the model through a published Skill. The recording and transcript on InfoQ show that work, including the execution traces behind the results.

As we explored what agents could do, we stepped back to revisit and rebuild the entire enterprise decision automation experience from first principles for the age of AI. We reconsidered how knowledge is captured, how business people review it, how approved logic is published and executed, and how a decision connects to an action. Today, the Aletyx Platform brings that work together.

From company knowledge to an approved model

Aletyx AI Assistant helps translate policies from PDFs, documents, spreadsheets, and existing rules into executable business rules. We start with the material a company already uses, so the model is grounded in its way of doing business.

The company reviews the interpretation, resolves ambiguities, tests the logic against expected cases, and approves it before agents or systems use it. What matters to me is that the people responsible for the policy have a meaningful opportunity to examine what will run.

Business notation such as DMN gives that conversation an explicit model. Business people and technical teams can inspect and test the decision together, and the same executable model can be used by systems and agents. The surrounding translation, testing, approval, and operational workflow is what we are building in Aletyx.

Simpler integration, clearer audit evidence

The practical benefit is shared business logic and a trace people can follow. Teams can review and approve business rules in one place, then reuse them across applications and agents.

In our forbearance example, a customer portal, an internal workflow, and an agent can all call the same approved decision service. Teams integrate with that service and handle the result. When a policy changes, they can review and test a new version in one place, then make it available to compatible callers.

The same approach can simplify audit preparation. A linked record connects the policy version, the facts, and the decision; the gates we are implementing extend that trace to the action taken. A reviewer can follow how the $18,400 deferral was authorized and applied. That gives teams a common basis for answering questions and investigating exceptions.

Four patterns for the enterprise harness

We use four complementary patterns for the enterprise harness: two ways to express business logic, and two ways to connect approved logic to agents and actions. They can work together in the same process.

Business Decision Models: making an outcome explicit

A Business Decision Model applies approved logic to the facts of a case to determine an outcome, such as eligibility, an amount, or the terms a company can offer. These are decisions I’ve spent much of my career working on.

Our forbearance demo begins with Policy.pdf, Matrix.xlsx, and existing rules. The policy calls for verified hardship, three or more missed payments, and a deferral cap of $25,000. In the demo, the company reviews the interpretation, confirms that all 38 tests pass, and approves version 4.2.

For account 48213, the agent gathers the relevant facts, including $18,400 past due, and invokes the approved logic. The result is an approved deferral of $18,400 under policy v4.2, with an audit record of the execution.

I like this example because the numbers tell us something useful. The $25,000 cap is part of the policy. The $18,400 deferral is the result for this account. A system applying the deferral needs the decision for the case, along with the policy and facts behind it.

Policy Obligation Models: making responsibilities usable

A Policy Obligation Model determines permissions, restrictions, and required steps, including who can participate in a process and what must happen first. I find this especially useful for policies in employee handbooks and codes of conduct.

Consider a hypothetical supplier policy. It requires employees to disclose personal or financial connections to a supplier. A financial interest or immediate-family relationship requires recusal from scoring and awarding the supplier’s business. Other personal connections require independent review before participation.

Suppose an employee’s sibling owns the supplier. Under this example policy, the result calls for disclosure and recusal. For another personal connection, participation might wait for independent review. If the relevant facts are unknown, the process should seek clarification or human review.

A Policy Obligation Model can return a participation status, required steps, a reason, and a policy reference. That gives an agent useful direction and gives the people involved a way to understand it.

There is a distinction I want to preserve: a rule saying disclosure is required does not mean the disclosure has been completed. The process needs evidence of completed obligations before relying on them.

Decision Skills: helping agents use approved logic

A Decision Skill guides an agent on when and how to invoke a company’s approved business logic.

In Aletyx, every published business rule has an associated Decision Skill. The Skill guides the agent on when the capability is relevant, which inputs to provide, and how to invoke the approved logic through the execution service. The service runs the company’s rule and returns the result with an audit entry ID.

We connect the Agent Skills approach to the company’s own executable business logic.

In our implementation work, I keep coming back to the boundary between guidance and enforcement. A Skill can guide an agent toward the right call. If another path can commit an action without that call, the guidance alone cannot require it.

Verified Decision Gates: connecting evidence to action

A Verified Decision Gate checks whether recorded decision evidence permits a specific action before a tool commits it. We are implementing these gates to make that connection enforceable at the action boundary.

The action tool receives the requested action and a prior decision’s audit entry ID. It retrieves the trusted record and checks whether the result allows this action for the intended actor, case, and scope. It also checks the amount or terms, the applicable policy and facts, and whether required prerequisites have been completed.

The ID helps find the record. Its presence alone does not establish permission: a denied decision has an audit record too.

In the forbearance example, an approval for $18,400 cannot authorize a $25,000 deferral simply because both amounts are within the policy cap. In the supplier example, a required review must have actually happened, and a recused employee cannot perform the prohibited role.

These are design requirements that shape how we build the action boundary. If evidence is missing, old, or no longer applicable, the process needs review or a fresh decision. Every equivalent path that can commit the protected action needs the same enforcement. One-time effects need protection against duplicates, and changed state needs to be checked again when the action commits.

The decision record establishes the result of executing the approved logic. The action record can then show what was done with it. Together, they give the company a trace it can examine.

Extending an event-driven architecture

Durable business events can connect agent reasoning, rule execution, and committed actions across a business process. My background in enterprise middleware makes this feel like a natural continuation of event-driven architecture.

A business signal can prompt an agent to gather context and propose a next step. The agent invokes approved rules, producing a recorded decision. A gate checks the evidence at the action boundary. Once the action is committed, an outcome event can carry references to the case and the decision that preceded it.

Those references help connect the history across components. A requested action, an authorized action, and an executed action are distinct facts. Keeping them distinct matters when a workflow waits for a person, receives new information, or retries an operation.

The patterns can also work through synchronous calls. Their event-driven form comes from durable events connecting components. I see that as a strength: we can build on established ways of designing enterprise systems while giving reasoning agents a responsible role within them.

The enduring value of company knowledge

Executable decisions have a long history. The opportunity I see now is to bring that experience into an architecture where agents can use company knowledge, people retain authority over it, and actions remain connected to evidence.

I expect our approach to keep evolving. It already has. What has stayed with me through that learning is the conviction that a company’s understanding of its own business deserves a durable place in this architecture. Its people should be able to examine that knowledge, improve it, and take responsibility for how it is used.

That is why we are building Aletyx as the harness company for regulated industries.

FAQ

What is an enterprise harness for AI agents?

An enterprise harness connects intelligence to how a company actually works, providing the context, identity, access, and operational controls its agents need. In our approach, executable business logic is one fundamental part: it connects the agent’s work to rules the company has reviewed and approved.

How do company policies become executable business rules?

Aletyx AI Assistant helps translate policies from PDFs, documents, spreadsheets, and existing rules into an executable model. The company reviews the interpretation, resolves ambiguity, tests expected cases, and approves the model before use. AI assists the translation; people remain responsible for what the rules mean.

Does the language model execute the business rules?

No. In this approach, the agent gathers inputs and invokes an execution service that runs the approved business rules. The service returns the result and an audit entry ID. The agent’s reasoning and the execution of the company’s decision logic have distinct responsibilities.

Can the same decision model serve systems and agents?

Yes. A traditional application, a workflow, and an AI agent can invoke the same approved decision through an execution service. Teams can review and approve each policy version for shared use instead of duplicating its logic in every application. Updated versions still need testing, and integrations need to remain compatible.

What is the difference between a Decision Skill and a Verified Decision Gate?

A Decision Skill tells an agent when and how to invoke approved logic. A Verified Decision Gate checks the evidence before an action tool commits the requested action. We use Skills for discovery and invocation, and are implementing gates to enforce required decisions and completed prerequisites.

Is an audit entry ID enough to authorize an action?

No. An audit entry ID identifies a record; a denied decision can have one too. The gate must verify a permitted result for the relevant actor, case, action, and terms, along with current evidence and completed prerequisites. The action’s completion then needs its own linked record.