Before AI acts.

Three ways to get the moment wrong.

An agent can act before it has enough evidence. It can keep checking after it has enough. Or it can refer to a person a decision it should have been able to handle.

Each has a cost. Acting too soon produces the wrong outcome, and often one that is hard to undo. Checking for too long produces delay and expense. Referring routine decisions to people undermines the value of automation, and approvals become a formality.

The question is not only whether the agent reaches the right answer. It is whether it chooses an appropriate response at an appropriate moment. Hexis investigates whether that choice can be made visible, constrained and tested, rather than left inside the model.

One refund, four moments.

A customer asks for a refund on an item that arrived damaged. The ordinary return window has closed. Policy allows an exception if the damage was reported within a set period after delivery, so two dates settle the case: when the item was delivered, and when the damage was first reported. The agent has the customer’s message. It does not yet have the order record.

Illustrative. These are hand-assigned readings adapted from the research paper’s worked example, not observed router outputs and not TAI assessment items.

Permission is not correctness. The boundary controls whether the agent may call a tool. It does not establish that the agent read the dates correctly or applied the policy properly. That is a separate question, and the programme’s behavioural tests are what would answer it.

Make the agent’s approach visible, and limit how it changes.

In most agent systems, how the agent approaches each turn is decided inside the model, without a record a reviewer can check. Hexis proposes taking that choice out of the model and recording it alongside the work.

The proposal concerns three activities. Each can be implicit, left to the model’s ordinary behaviour with nothing produced that a reviewer could check, or explicit, carried out in a way that produces something checkable.

Planning

Implicit: the agent proceeds without stating a course of action. Explicit: it sets out what it intends to do before doing it. In the refund case, explicit planning is the agent stating that the case turns on two dates before it does anything else.

Monitoring

Implicit: the agent relies on its own sense of how things are going. Explicit: it checks progress against supplied evidence or an external check. In the refund case, that is comparing the dates with the policy period, rather than judging the customer’s account plausible.

Recall

Implicit: the agent works from what it remembers or infers. Explicit: it retrieves the relevant record before proceeding, and holds back when the record is not available. In the refund case, that is the order record, not the customer’s description of it.

The combination in use at any moment is the agent’s configuration. Hexis proposes four things about it.

• It is selected deliberately and recorded outside the model, so it can be seen.
• It can change as the situation changes, but only along permitted paths, and each change is checked before it is made.
• Half of the possible states permit the agent to use tools: issue a refund, send a message, change an account. The other half permit only a structured decision. An open escalation blocks tool use in every state.
• Every turn is logged: the approach in use, the reading of the situation, the change made and the action taken, so a reviewer can examine the sequence without relying on the model’s account of itself.

Why this might help. The hypothesis is that the wrong approach at the wrong moment is one cause of the three failures: acting from memory when the record was needed, or checking by feel when evidence was available. If the approach is chosen for the situation and changed only in controlled ways, the agent may be more likely to seek evidence when a fact is missing and to act once it has arrived.

That is a hypothesis, not a result. The research programme would measure three things: whether the configurations produce distinguishably different behaviour; whether the routing between them agrees with independent judgement; and whether changing approach over a task improves decisions compared with the best single approach at the same computational cost. None of these has yet been measured.

The structure behind the configurations and their permitted changes comes from the binary arrangements and named relations of the I Ching, taken as a fixed structure and not as divination. The lineage explains the design; the comparisons must establish its usefulness.

Alongside your controls, not instead of them.

A COO reading the refund example may reasonably say: we already require the dates before a refund is authorised. That is right, and Hexis does not replace that rule.

Your approval steps, rule engines and sign-offs govern whether the agent may act. Hexis governs how the agent approaches the decision as circumstances change: whether it is planning, checking and retrieving, or working from its defaults, and it leaves a record of which. The two are designed to work together. Approval pauses and resumable state already exist in agent frameworks, and Hexis is designed to operate inside such a workflow.

Whether this adds enough value over the controls you already have has not been tested. The paper’s registered tests compare Hexis with model-side alternatives at matched compute: the best single configuration, self-consistency and a shuffled router. They do not compare it with approval steps, rule engines or human sign-off. That comparison is not among the registered tests. It is the evaluation we invite partners to design.

The structure is available to examine. The behavioural case is still to be made.

The research paper states each claim with the test that would refute it, fixed before the evaluations are run, and reports no agent-performance results.

The research paper also reports one corpus measurement. That result does not establish an agent-performance benefit.

How a better decision would be measured

The same action can be premature on one turn and appropriate on the next, so the measure has to capture timing as well as choice. TAI, the proposed Timeliness and Appropriateness Instrument, assesses which response a system chooses in a situation, and at which point it chooses it. It is intended for systems built on any architecture, so an organisation can take part without adopting Hexis. It remains a development scale until validation shows that its scores mean more than fluency, general ability or habitual caution.

Three questions for a business evaluation