**This is a working direction, not a released product.** ReactorJet and Biro do
not currently offer a product called AI operations IME. The term describes an
interaction model being explored, not a capability claim or delivery promise.

IME means input method editor in this concept. A conventional IME sits between
keystrokes and committed text. It helps a person compose an intended result,
shows candidates when the input is ambiguous, and waits for a selection before
committing.

An AI operations IME applies that interaction pattern to operational intent. It
would sit between what an operator means and the durable work objects a control
plane can govern. Its job would be to help compose intent, expose assumptions,
and preview consequences before work is committed.

The analogy has limits. An operations IME would not be an operating-system text
input method. It would also not have authority simply because it produced a
plausible interpretation.

## Why this direction is useful

Most agent interfaces begin with a blank chat box. The user types a request, the
system interprets it, and execution may begin before the user can see what the
request became.

That interaction hides several operational questions:

- Which goal does this request serve?
- Is it a question, a draft, a task, or approval to act?
- Which systems and records may change?
- What budget and deadline apply?
- Which assumptions did the model make?
- What evidence will count as done?
- Which step needs a person or separate authority?

A chat transcript can contain answers to all of these, but it is a poor place to
enforce them. Operational intent should become durable state that can be
inspected, changed, approved, and compared with what actually happened.

## A possible interaction

Consider the request: "Reduce the support backlog without breaching our refund
policy."

An ordinary assistant might return a plan or start calling tools. An operations
IME would first compose a candidate operational object. Conceptually, the flow
could be:

1. **Input.** Capture the operator's sentence and the current work context.
2. **Candidates.** Offer distinct interpretations, such as prioritizing old
   tickets, drafting replies, or changing assignment rules.
3. **Preview.** Show the proposed scope, affected systems, budget, assumptions,
   approval points, and completion evidence.
4. **Commit.** Turn the selected interpretation into durable goals, tasks,
   policies, or approvals in the control plane.
5. **Observe.** Attach execution events and outcome evidence to those objects so
   the operator can compare intent with result.

This example describes the proposed interaction model. It does not state that
ReactorJet or Biro implements this sequence today.

## The composition must be inspectable

The useful output is not a better prompt. It is a proposed change to operational
state.

Before commitment, the operator should be able to inspect a diff that answers:

- what new work will exist;
- which existing goal or policy it belongs to;
- who or what may execute it;
- what permissions and budget it receives;
- what completion rule will judge it;
- what remains ambiguous or unapproved.

The system may help fill these fields, but generated confidence does not settle
them. Ambiguity should remain visible until a policy or person resolves it.

## Relationship to the control plane

An operations IME is not the control plane. It is a possible composition layer
above one.

The IME would translate human intent into candidate control-plane changes. The
control plane would remain responsible for durable identity, policy, assignment,
budgets, approvals, and status. The work plane would still execute bounded
assignments through its own tools and credentials.

This separation matters because language is permissive. A sentence can imply a
broad action without naming its blast radius. The control plane should reject or
hold a candidate that lacks the required scope, authority, or evidence rule.

## ReactorJet and Biro direction

For ReactorJet, the idea is an interaction model for evidence-backed software
and agent operations. It fits the broader practice of making intent, boundaries,
and verdicts visible before increasing autonomy.

For Biro, the idea could provide a way to compose company-level intent into
goals, work, budgets, and approval requests without turning the product into a
general chat surface. Biro's control-plane objects would remain the governed
record. The IME would be one possible way to propose changes to that record.

These are design directions. They do not announce a roadmap, release date,
integration, or implemented feature.

## What it should not become

The IME framing is useful only if it preserves operational boundaries.

- It should not become a chat wrapper that executes ambiguous requests.
- It should not replace the control plane or source systems with a transcript.
- It should not treat generated plans as approval.
- It should not hide permissions, cost, or affected records behind a friendly
  summary.
- It should not report work as complete without evidence from the work plane or
  a separate evaluator.
- It should not promise one natural-language command that can safely operate
  every system.

The interface should make uncertainty easier to inspect, not make uncertainty
look certain.

## What would make the direction credible

Before calling this more than a concept, an implementation would need to prove
several properties:

1. The same committed intent produces a durable, versioned operational change.
2. Candidate interpretations expose material differences before selection.
3. Permissions and budgets come from policy, not from generated text.
4. Execution occurs through bounded work-plane contracts.
5. Evidence attaches to the committed intent and identifies the relevant run.
6. Missing evidence, lost execution, and policy conflicts have visible states.
7. High-consequence actions stop at named approval boundaries.

Those tests are more important than how fluent the interface feels. The concept
becomes useful when it gives operators a clearer way to control work, not when it
merely makes requests easier to type.

## Related reading

- [Control plane versus work plane](/guides/concept/control-plane-versus-work-plane)
- [Evidence before confidence](/guides/concept/evidence-before-confidence)
- [What makes software autonomic](/guides/concept/what-makes-software-autonomic)
- [The two-plane loop](/reference/two-plane-loop)