Reactive, Semi, and Full behavior, result-driven choices, and how finite Desire plans give robot work a verifiable end.
Published Updated 7 min read
Ainekio’s autonomy settings control when it can begin work without a new user request. MetaHuman OS, the software behind its conversation and decisions, provides three modes: Reactive, Semi, and Full.
The October 14 Robot Bible clarifies their intended role in the companion. They select how activity begins and continues; any chosen physical action must be supported by the connected body. These are distinct from MetaHuman’s cognitive modes and from physical Idle, Doze or sleep states.
Semi Auto now has a configurable inactivity interval, with a five-minute default in the prepared build. Queue bookkeeping no longer immediately triggers another Semi assessment. The latest preparation record leaves live activation and interval testing unverified; the model still chooses whether to activate an operation.
Tip/shake events use a separate one-call Fast Body Event workflow. A finite body event can finish its admitted work while preserving an unresolved objective; ending the invocation does not mean the objective succeeded. This is separate from the robot’s prepared three-minute rest setting and Body Control’s host gait learning, which uses ordinary commands without dispatching autonomous test walks.
The existing scheduler is now presented as Active Operator in the Agent Catalog, with its mode control and existing child workflows. Persona goals remain long-term directions; specific desires belong to Agency. Desire review can use actual requests, selected programs and returned evidence, revise relevance and archive obsolete intentions. Psychotherapist remains the sole autonomous persona editor.
The systems report separates catalog activation, live Desire review and workflow recovery from still-unqualified companion outcomes. Body Event Trigger remains available for interpreting physical events in Reactive mode as well as requests; Reactive does not mean ignoring the robot’s sensors.
| Mode | Expected behavior |
|---|---|
| Reactive | Respond to requests and physical events without independently choosing new activities |
| Semi | Let configured agents and triggers initiate selected functions and activities |
| Full | Choose high-level activities, pursue goals, review desires and use experience to decide what comes next |
Full autonomy is intended to connect perception, identity, personality, memory and outcomes into purposeful activity. Repeated commands or repeated no-action decisions without useful progress do not demonstrate that experience. Complete companion autonomy remains unqualified. Personality, memory and learning explain the wider context in which these modes operate.
The following sections retain the September 9 source and September 8 live-test period. Their scheduling and plan details describe that implementation, rather than redefining the October 14 intended modes or claiming current physical acceptance.
Robot Operator is the service that decides when autonomous work may start. The Work Coordinator schedules that work. A saved execution is one request with its objective and progress recorded; a saved wait keeps that request open until a needed result or input arrives.
In Full mode, an eligible saved wait can resume. If no execution is active, the Coordinator can start the Robot Autonomy Controller, a software workflow that chooses the next activity from current context.
Older documentation described Full as a rotation through Boredom Observer, Movement, and Reflection workflows. Those configured workflows remain available, but they no longer describe Full mode’s selection process.
The Autonomy Controller receives the configured persona, recent conversation including the latest user turn, internal reflections, recent robot results, and facts from connected devices. It also receives Robot Status, compact awareness of pending Desire work, and an Agent Catalog explaining the available software workers. Available camera images include their recorded identity and time; reviewing a particular action still requires evidence matched to it.
From that context it can choose to speak, assign a finite job to a specialist worker, or start a robot objective. A specialist agent is software doing one assigned job. Its task brief and returned answer stay connected to the parent request. Goal Review can choose among the available workers after a result, so continuation is no longer restricted to another robot action.
After work starts, Environment workflows choose specific actions and the body checks movement. For example, choosing to wave still results in a supported robot command with limits, an ID, and a result. The autonomy mode does not bypass that path.
A Desire is a candidate intention managed by MetaHuman’s Agency system. It may need clarification, planning, or approval before execution. The September 8 review found unresolved motivations repeatedly influencing new movement decisions without passing through that lifecycle.
The repair gives executable Desire work a finite contract:
For example, “slow down” alone has no observable finish line. A candidate such as “perform one supported slow walk and check its completion” has a bounded outcome, if that is the intended task. This illustrates the distinction; it does not report a new physical demonstration or silently turn a preference into a robot request.
Pending desires remain visible in Robot Status with their lifecycle and next required action. Their full rationale, strength, and plan are no longer general movement instructions. A record waiting for an answer remains dormant for execution. The existing reduced-inhibition policy is retained: strength and maturity can lower trust requirements, while a finite reviewed plan and outcome check remain necessary.
An unknown result is held for reconciliation instead of automatically repeating the effect. Completion stops that execution, including a recurring cycle; another phase of long-running work requires a newly reviewed plan. Existing records with incomplete contracts can be held for attention by the explicit migration, which has only been dry-run locally.
An objective describes the intended outcome. A command is one step toward it. A workflow saves the objective, sends an action, waits for its result, and runs Goal Review to decide whether to finish or continue.
A specialist returning an answer or the robot saying something does not necessarily complete the parent objective. That completion decision is recorded explicitly. For a visual goal, such as the proposed example of moving into better light, review needs a fresh image showing the result.
Robot Status displays current facts and workflow decisions. The saved execution retains the objective, evidence, and pending work for recovery. This replaces the older Task State continuation design and a proposed separate Robot Status workflow. Review continues within the same execution rather than starting a new graph for every result or relying on a separate polling loop.
Users can steer or cancel ongoing work. Mode eligibility, authorization, Sleep, scheduling, and which software process is currently allowed to control the body all constrain autonomous actions. Robot Operator remains dormant in Reactive mode and during Sleep.
Emergency stop has a direct path that does not require a model to interpret a sentence. Coordinator and adapter changes coordinate cancellation with control of the body. If a connection loss leaves a physical result unknown, the system must resolve that uncertainty before assuming it is safe to try the action again. Software cancellation tests still need physical stop measurements.
Earlier V1 runs recorded an autonomous movement reaching done, an observation
request expiring, and an invalid motion plan being rejected. Those results
belong to the previous runtime.
The September 8 live review found current workflows and adapter-reported movement results, but also stale goals and repeated influence from unresolved desires. Later controlled tests cover truthful goal projection, specialist returns, continued review, ordered Desire steps, stopping on an unsatisfied result, cancellation, and recovery. Those source repairs have not yet been verified together in a new physical run. The dated evidence is in the status report.
The next demonstration should follow one objective through scheduling, model choice, dispatch, robot result, observation, and review. It also needs repeated runs with user corrections, specialist returns, stop, Sleep, Reactive mode, disconnection, and restart. Rejections must remain rejections, and unknown outcomes must remain explicit. The same requirements apply to V1 and the planned V2 body.