A plan before acting: how LIA prepares and checks your multi-step requests

The problem

You write: “send John a summary of tomorrow's weather”. Behind that sentence there are three actions: read the weather, find John in your contacts, then compose the email. The order matters: the email can't go out before it has the weather and the address.

A language model that improvises these actions as it goes can get the order wrong, invent a tool that doesn't exist, or ask a tool for ten results when it only returns five. As long as nothing has gone out, the error costs nothing. Once the email is sent, it does.

What I wanted

I wanted everything that can be checked to be checked before the first call, while a correction is still free. And once the plan is running, I wanted LIA to tell you honestly what happened, without replaying steps behind your back.

What a plan looks like

A plan is a list of steps. Each one names the tool to call, its parameters and the steps it needs. For John: (1) tomorrow's weather, (2) the contact John, (3) the email draft, which waits for the first two and takes the address found in step 2.

Parallel waves. Steps that wait for nothing start together. Here, the weather and the contact are looked up at the same time, then the email follows. A request that touches several domains doesn't necessarily take longer.
“For each”. “Send the agenda to each attendee of my meeting tomorrow” becomes a single step that repeats over a list, with a cap. If one of the sends fails, the others keep their result. And before acting on a whole list, LIA shows you how many items are involved, with a preview.
Conditions. A step can also be a test: do this only if that is true.

What's checked before the first call

Real tools. An invented tool name is caught, and the most common small naming mistakes are corrected.
A possible plan. To reply to an email, you need its identifier, so a tool that reads emails. LIA makes sure that every piece of data a tool requires can be obtained from another tool that is present. Otherwise, no valid plan would exist, and the model would have nothing left to do but invent.
Stated limits. Each tool says what it accepts, for example how many results it returns at once, and the planner sees it. A value that goes over is brought back within bounds, and the plan carries on.
Search, then sort. “My medical appointments this month”: your calendar knows how to search by date; it doesn't know what “medical” means. The planner is guided to fetch the period and leave the sorting to the answer, and the validator spots when such a word slips into a search.
Consistency. A plan that does less or more than asked (“all my contacts”, but only one handled), a step that cites a step that doesn't exist, a risky action on vague information: the plan goes back to the planner, a limited number of times. If information is missing that nobody can guess, like the content of an email, LIA asks you. And if a plan that changes something is still doubtful after these retries, it stops and asks you.

When a step fails

Once the plan is running, nothing is replayed behind your back. A transient failure has already been retried by the connection that hit it. A disconnected service or a denied access can't be worked around with a new plan. An empty result is an answer. Each failed step reaches the answer in full, and the answer tells you which tool failed, why, and what worked alongside it.

Likewise, what a read found reaches it too: the travel times of a route or the next page of a search don't stay stuck in the tool's data. And a service's refusal isn't turned into a success along the way.

When you refer to a result by its sender, title or position, LIA first uses the items it actually showed. If several fit, it asks which one. A planned lookup that would act on the first of several matches also stops for your choice, then continues with that item.

The limits

A plan is written before seeing the results. It doesn't change course along the way: if you want LIA to look for another source when the first one doesn't answer, that's the job of ReAct mode, which you turn on with the mode button, at the top of the screen. And the check verifies the plan's form; it doesn't read your mind. A well-formed plan can misunderstand what you wanted. That's why sending, changing or deleting something still goes through your confirmation, apart from a few actions that only affect you and can be undone in one click.