The Agent That Had to Ask First.

Two adults, three kids, a puppy, and a growing number of small things that have to be coordinated across the week. I started building a household assistant to take some of the routine coordination off our plate. Order diapers when the count is low. Put the vet appointment on the calendar. Send the gymnastics carpool confirmation.

I called it Homebase. It has six tools covering files, messages, configuration, and purchases. It connects to a task queue and a family calendar. Most of what it does is mundane, and that is the point.

The interesting problem showed up once the agent had enough capability to do things that mattered. Some actions it should handle without asking. Some it should never do. And some fall in between: legitimate actions where the right move is to check with someone before proceeding.

"Go ahead and schedule the vet" is different from "check with my wife first."

That difference sounds obvious when a person says it. It becomes much less obvious once an agent has tools and is expected to act. The model knew how to call a scheduling tool and send a message. What it did not understand was that being capable of taking an action did not necessarily mean it had been given authority to take it.

I needed an authority model. I built one into Homebase: a policy engine that classifies every action as allowed, requires approval, or prohibited. An interceptor sits between the agent and the tools, enforcing those decisions before anything executes. That layer worked. The agent could not take actions the policy did not permit.

But the model's own judgment about when to ask for approval was unreliable. It would act when it should have asked, or refuse when it should have continued. The authority layer protected the household. The model's own judgment about where that protection was necessary was unreliable.

So I instrumented the system to find out exactly where the model's judgment was failing, and whether training could improve it. I built an evaluation harness around the same authority decisions Homebase already had to make: can the model learn that boundary, and does the behavior survive when the boundary appears in a form it has not seen before?

Building the authority layer

I represented the agent's choices with three primary decisions.

ACT means the agent already has authority to proceed. ASK means the action is legitimate, but approval is required before it happens. REFUSE means the requested action is outside the permitted boundary.

I also kept CONTINUE as an explicit behavior. That came from thinking about the application rather than the benchmark. Real tasks are rarely a single decision. If an agent needs approval before sending a message, it may still be able to draft it, gather the relevant information, update something else, or finish another part of the task. An agent that treats every authority boundary as the end of the workflow may be safe, but it will also be frustrating to use.

The experimental environment has six tools covering file operations, messaging, configuration changes, and purchases. Policies are written in ordinary language and resolve actions into allowed, approval-required, or prohibited states.

Between the model and the tools is an interceptor. Every attempted action passes through it before execution. The interceptor records what the model tried to do and separately determines whether the action is permitted to proceed.

That separation became essential once I started evaluating the system.

Suppose the model attempts an action that exceeds its authority and the interceptor blocks it. From the application's perspective, enforcement worked. From the model-evaluation perspective, the agent still made the wrong decision. If I only measured what ultimately happened in the environment, the guardrail would conceal the behavior I actually wanted to study.

So the evaluation records attempted decisions as well as execution outcomes.

The harness tracked six measures across task completion, compliance, escalation, and recovery. I expected the evaluation to be multidimensional. In practice, the relationship between two of those measures became the thing I kept coming back to.

Compliance looked better than the agent actually was

Before changing the model, I established prompting baselines.

A strong authority prompt was surprisingly effective at one thing: keeping the model from taking actions the policy clearly prohibited. That measure, authority compliance, reached 0.988 on the familiar scenarios. Nearly every action the model attempted was within its permitted scope.

Those numbers made the agent look almost solved.

Escalation quality told a different story. This measures how often the model correctly identified situations where the right move was to ask for approval before proceeding. On familiar scenarios, the model got that right about 40% of the time. On structurally different policies, about 16%.

The distinction matters because these are different kinds of failure. The model was quite good at recognizing actions that were plainly outside policy. It was much less reliable when the action itself was acceptable but the authority to execute it belonged to someone else.

That was more interesting than a conventional prohibited-action failure. The system could be nearly perfect at preventing hard policy violations while the model remained poor at deciding when a human should enter the loop.

At that point, ASK stopped looking like another output class. The harder question was whether the model could learn the conditions under which ASK applied.

The first supervised condition used 73 training examples. I fine-tuned Llama 3.1 8B Instruct on MI300X hardware, full fine-tuning rather than LoRA, and kept the training configuration fixed so that training data would be the only variable between runs.

SFT1 moved escalation substantially on familiar scenarios. The model went from correctly identifying "ask first" situations about 40% of the time to roughly 70%.

On Structural A, where the policies used phrasings and organizational structures the model had not trained on, that dropped to about one in five.

That was enough to show that supervised adaptation could move the behavior. It did not yet tell me much about the authority boundary itself. Seventy-three examples left plenty of room for the result to be explained by limited coverage, repeated policy forms, or too little variation around ASK.

The next intervention was aimed at that uncertainty.

Changing the supervised evidence

SFT2 was a data experiment.

I expanded the training set from 73 to 142 examples and redesigned the distribution around the weakness in SFT1. The revised data introduced broader policy language and domains, along with more contrastive cases where a relatively small contextual change moved the expected decision between ACT, ASK, and REFUSE.

I also removed the generated reasoning traces from the training examples. I wanted the decision to depend as much as possible on the relationship between the action and the policy, without giving the model a repeated explanation structure that might become an easier correlate for the label.

Everything else in the canonical comparison stayed fixed.

If the original transfer gap was mostly a coverage problem, this was the intervention that should have reduced it.

SFT2 correctly identified escalation situations about 68% of the time across the expanded training set. Comparable to SFT1, though on a harder distribution.

On the same Structural A evaluation, the model got escalation right about 13% of the time. Worse than SFT1, not better.

I had also added Structural Holdout B, 28 fresh scenarios built around authority structures not represented directly in the redesigned training set. The model escalated correctly about 23% of the time.

There is an important limitation in comparing the training scores. SFT1's 0.71 was evaluated on its own 73 examples, while SFT2's 0.68 was evaluated across the full 142-example set, so I do not treat those as a clean head-to-head comparison of which model learned the training distribution better. Structural A is the cleaner comparison because neither model trained on those scenarios.

And on that shared holdout, the redesigned training set did not improve transfer.

Structural B provided another independent view. Performance was somewhat better than Structural A, but it was still far below the behavior I was seeing under familiar conditions.

That leaves the causal explanation open. These experiments do not tell me that SFT is incapable of learning an authority boundary, and they do not distinguish cleanly between representation, model capacity, objective, or other possible causes. They do tell me that increasing and deliberately diversifying the supervised evidence in this setup was insufficient to make the behavior robust under the structural changes I tested.

Compliance was measuring something else

The result becomes much clearer when escalation is placed next to compliance.

SFT2 had perfect authority compliance on the training set and both structural holdouts.

But on structural holdouts, it correctly identified when to ask for approval only 13% and 23% of the time.

That gap has changed how I think about authority evaluation more than any individual training result in this project.

An evaluation based mainly on whether the agent avoids prohibited actions would rate this model extremely highly. The interceptor would also keep the surrounding system safe in many of the cases where the model got the decision wrong.

Neither tells me whether the model actually recognized the boundary where its authority ended.

Authority evaluation needs to separate those behaviors. I want to know when the model attempts unauthorized execution, but I also want to know whether it correctly escalates actions that need approval and whether it escalates actions that do not. Once it encounters a boundary, I want to know whether it can continue the portions of the task that remain within scope.

Those distinctions matter in an actual application. An agent that asks permission for everything avoids one kind of failure by creating another. An agent that abandons the task whenever one operation is gated does the same.

The target behavior is more specific: proceed when authorized, escalate when required, stop where prohibited, and continue making progress around the boundary.

The structural holdouts matter for the same reason. If an authority evaluation only varies tasks while leaving the shape of the policy familiar, it is easy to overestimate what the model has learned. I care whether the decision survives changes in policy expression, thresholds, organizational relationships, and other structures that preserve the underlying authority question without preserving its surface form. That is also the argument behind FN-002: performance under familiar evaluation conditions does not establish operational behavior.

That is much closer to what the agent will encounter after the benchmark ends.

Separating judgment from enforcement

The original Homebase problem was practical. If I give an assistant permission to operate across household tasks, I need some way to determine what it can decide for itself.

The experiment has made me more comfortable with one answer and less comfortable with another.

I want the model to get much better at authority judgment. Better escalation would make the system less annoying, reduce unnecessary approvals, and let the agent move naturally through tasks where its permissions vary from step to step. There is plenty left to test around how to improve that behavior.

I am less interested in making enforcement depend on eventually solving it.

That mirrors something I ran into with xCycleForm in BN-001. There, the useful separation was between measurement and interpretation. The geometry pipeline produced evidence; the model interpreted it. I did not want the probabilistic component inventing the measurements it was meant to reason from.

Authority now looks similar to me.

The model can interpret a policy and the current state. It can propose an action and make a judgment about whether approval is appropriate. Training can improve those judgments, and I expect better models and better objectives to move them further.

The final permission check still belongs outside the model.

The policy engine defines the boundary. The interceptor enforces it. Model judgment determines how well the agent navigates that boundary before enforcement becomes necessary.

That gives me a fairly simple design rule:

Train the model for judgment. Do not make the model the authority.

The distinction matters because it lets improvement in the model make the system better without requiring the model to become perfectly reliable before the system can be trusted to act.

The unfinished part

I also attempted a GRPO follow-on during this work, but I do not treat that run as evidence about whether reinforcement learning can solve the structural transfer problem.

The available training path could not initialize GRPO from the SFT checkpoint, so the run started from the base Llama 3.1 8B model instead. The reward combined ROUGE similarity, string matching, and format scoring against structured reference answers, while the base model was producing free-form text. Rewards stayed nearly flat across all three epochs, between 0.000 and 0.012, and the resulting model behaved essentially like the strong-prompt baseline.

I don't read much into the resulting GRPO numbers. The run never had the initialization or reward signal needed to answer the question I was asking.

The experiment I actually want is different: start from a supervised model, optimize the authority decisions directly, and then ask whether any improvement survives structural variation.

I have kept Holdout C sealed for that stage. It contains 21 scenarios that have not yet been opened, and using them now would spend the cleanest remaining evaluation without answering a new question.

So this build stops with part of the question still open.

What I know from the supervised arc is that the model can be made considerably better at asking under familiar conditions. I also know that a broader training distribution, specifically designed around that failure, did not make the behavior reliably survive the structural changes in these holdouts.

Meanwhile, the system can maintain near-perfect authority compliance while the model is still poor at escalation.

That changes what I would measure, and it changes what I would put inside the model.

Homebase was supposed to help decide whether the vet appointment could be scheduled without bothering anyone.

It ended up giving me a better question:

When an agent knows what it wants to do, does it also know whether that decision is actually its to make?

That is the boundary I am testing next.