Make the Second NoInfra Agent Run Smaller Than the First

The first useful NoInfra agent run should create evidence. The second run should use that evidence to get narrower.

That can feel counterintuitive. After a hosted agent answers once, the natural impulse is to make the prompt bigger, add more sources, invite another teammate, or try a more ambitious workflow. Sometimes that is earned. More often, the first run reveals that the job still needs a smaller input boundary, a clearer output shape, or a simpler review standard.

The second run is where a hosted agent either becomes easier to operate or starts drifting into a vague automation project. NoInfra removes the provider-key and server setup work from the launch path, but it does not remove the need to learn from the first proof. The fastest way to improve a first agent is to make the next run easier to compare.

Do not scale the prompt before you scale the proof

A first run can succeed in a narrow sense and still be too weak to scale. The workspace may open correctly. The agent may respond. The output may look plausible. But a builder still has to ask a harder question: what exactly did this run prove?

If the proof was "the agent can summarize one clean document," the second run should not become "summarize every document in the folder and draft a strategy." A better second run is "summarize one messier document using the same output shape, with source links and open questions." That keeps the comparison honest.

Scaling the prompt too early hides the useful signal. When too many variables change at once, a weak result is hard to debug. Was the input unclear? Was the requested format wrong? Did the runtime fit poorly? Did the agent need a stop condition? Did the human reviewer change the standard halfway through?

The second run should answer one of those questions, not all of them.

Pick one variable to change

Start by writing down what stayed true in the first run. Name the job, input, output shape, runtime, and review standard. Then choose one variable to adjust.

Useful second-run changes include:

• Narrower input: use fewer rows, fewer sources, or a smaller account list.
• Clearer output: ask for a table, checklist, short memo, or labeled action list.
• Stronger evidence rule: require source links, quoted fields, or explicit uncertainty.
• Better stop condition: tell the agent when to pause instead of guessing.
• Different reviewer: ask the teammate who owns the work to judge the result.
• Runtime reconsideration: keep OpenClaw for a visible manual proof, or evaluate Hermes or NemoClaw only when the workload shape explains why.

Do not change all of these at once. A second run that changes one variable can teach you something. A second run that changes six variables usually creates a new first run.

Keep the workspace stable

One practical advantage of a hosted NoInfra agent is that the work happens in a place you can return to. Use that stability. Keep the same agent and workspace when the second run is meant to improve the first result, unless the first review showed that the runtime choice itself was the problem.

This matters because local demos often depend on hidden setup: the builder's terminal, browser session, credentials, environment variables, and memory of what happened five minutes ago. A hosted run gives you a more useful review surface. You can compare the first output with the second output without rebuilding the environment around the test.

If the first run was in OpenClaw and the issue was output format, stay in OpenClaw. If the issue was that the workflow is now clearly repeated, delegated, and stable, write that down before considering Hermes. If the issue was environment boundary or isolation, write that reason before considering NemoClaw. Runtime changes should follow the job shape, not the mood after the first answer.

Ready to test the second run in a stable workspace? Create a NoInfra agent, keep the job narrow, and compare one improvement against the first proof.

Make the second input more realistic, not larger

The second input should be closer to real work, but it does not need to be bigger.

For example, if the first run summarized a clean support ticket, the second run might use one messy ticket with missing context. If the first run researched three accounts, the second run might research three different accounts with weaker source material. If the first run drafted a follow-up from tidy meeting notes, the second run might use rougher notes from the same meeting type.

That gives you a better test without expanding the whole workload. You learn whether the agent can handle the shape of real inputs while keeping review cost low.

The wrong move is to add every edge case at once. A broad second run burns time and tokens before the builder knows which part of the workflow is reliable. Keep the input small enough that a human can check it in a few minutes.

Tighten the output contract

Most first agents improve when the output contract gets stricter. "Give me insights" is hard to review. "Return a table with account, evidence, likely pain, next action, and open question" is much easier.

The second run should make success visible. Use boring formats:

• A triage table with status, reason, next step, and owner.
• A short memo with summary, risks, recommendation, and open questions.
• A checklist grouped by ready, blocked, and needs review.
• A draft response plus source notes and confidence level.
• A cleaned data preview plus a list of changed fields.

The point is not to make the agent sound polished. The point is to make the result auditable. If the agent cannot follow a simple output shape, the workflow is not ready to expand.

Add a stop condition before adding scope

A useful hosted agent should know when not to continue. The second run is a good time to add that rule.

Stop conditions can be plain:

• Stop if the required source is missing.
• Stop if a row lacks enough information to classify.
• Stop if a recommendation would affect a customer, payment, production setting, or public message.
• Stop after five items and ask for review.
• Stop if the output cannot include source evidence.

Stop conditions protect the workflow from false confidence. They also make the agent easier to hand off later because a teammate knows when to trust the run and when to pause.

Write a second-run card

Before running the agent again, write a short second-run card. It should fit in a few lines:

• Keep: the same agent, workspace, and job.
• Change: request a table with source links and open questions.
• Input: use one realistic but bounded example.
• Review: accept only if every recommendation points to evidence.
• Stop: pause when the input is missing required context.
• Next: if this works twice, try a teammate-owned run.

That card keeps the iteration disciplined. It also helps later if the workflow becomes recurring. You can look back and see why the agent changed, which evidence supported the change, and what still needs review.

Know when the second run is good enough

The second run does not need to be perfect. It needs to reduce uncertainty.

Good signs:

• The workspace is easy to revisit.
• The agent uses the intended input.
• The output follows the requested shape.
• The result can be reviewed quickly.
• The agent names missing context instead of inventing it.
• The next decision is obvious.

Weak signs:

• The second run needs a long explanation to understand.
• The human has to rewrite the output before judging it.
• The agent keeps expanding beyond the requested boundary.
• The result cannot be traced back to source material.
• The next step is another broad prompt.

If the second run is good enough, the next move may be a teammate proof, a recurring workflow experiment, or a runtime change backed by evidence. If it is not good enough, the next move is another narrow run. That is still progress. You are learning where the workflow breaks before it becomes expensive to operate.

The second run should make the agent less mysterious. Keep the workspace stable, change one variable, tighten the output, and add a stop condition. That is how a first hosted proof becomes an operating loop instead of a bigger prompt.

Turn the first proof into a smaller second run. Create a NoInfra agent, run one bounded job, and compare the result before expanding the workflow.