Agent Sessions: Honest Failures and Connector Auth

A person who calls a tool and gets nothing useful back notices. They look at the empty result, frown, and try something else. An agent often does not. It reads the response, takes it as fact, and keeps building on a step that never actually happened.

That gap is the whole subject of this release. Most of what shipped is about not lying to an agent and not pointing an agent at itself.

Ripley no longer gets pointed at itself

The how-to tool answers questions about how to get things done in Fastio. When Ripley, the built-in AI agent, was the one asking, the answer could still come back recommending that the caller ask Ripley.

That is a loop. The agent asks how to do something, is told to ask itself, asks itself, and gets told the same thing again. A person reading “ask Ripley” while being Ripley would catch it immediately. An agent has no such instinct. The instruction reads like every other step in the answer, so it gets followed.

Two changes close it:

• How-To answers account for who is asking. When the calling agent identifies itself as Ripley, the answer no longer tells it to call Ripley.
• Ripley sessions no longer expose the self-delegating AI tool. The tool is not listed and not suggested inside a Ripley session, so there is nothing there to route back into even if a prompt tries.

The first fix handles the advice. The second removes the capability, which matters more, because prompt-level guidance is a suggestion and a missing tool is not.

Failed calls now say they failed

In code mode, an agent sends work to the execute tool and reads back the result. Failed execute calls used to come back looking like successes.

This is the expensive kind of bug. The agent believes the step landed, so it plans the next step on top of it, then the step after that. Nothing throws. Nothing looks wrong. The session runs to the end and produces something built on a foundation that was never there, and the only way to find out is to check the actual result by hand.

Failed execute calls now report the failure. The agent can retry, take a different path, or stop and say what went wrong. All three of those are better outcomes than a confident answer built on a call that did not run.

This is the same reason a good API returns a status code instead of an empty body. An agent has no peripheral vision. If you do not tell it something broke, it does not know.

Auth guidance for clients that churn sessions

Some MCP clients start a fresh session for every call. Anything held per session, including auth state, does not survive the turn. From inside the agent’s view, it was authenticated a moment ago and now it is not, with no visible reason why.

The server now returns auth guidance aimed at exactly that case, so a client losing per-session state gets told what to do about it instead of guessing or retrying the same failing call.

The Grok connector re-authenticates

The OAuth 401 challenge is now enabled for the Grok connector, so it re-authenticates when its credentials are no longer good.

A 401 with a proper challenge is the signal an OAuth client needs in order to refresh on its own. Without it, the client has no standard way to tell “this request is not allowed” apart from “your session is stale, go get a new one,” and those two situations call for very different responses.

Why this matters more for agents than for people

Every item here is small. None of them is a feature. Taken together they are the difference between an agent that notices a problem early and one that spends an entire session going nowhere with total confidence.

Humans are error-detection machines by default. We check, we squint at odd output, we ask someone. An agent is only as correct as the information it is given, which means the tools around it carry more of the burden. When a call fails, say so. When a tool cannot help, do not recommend it. When auth expires, challenge for it.