Before adding another agent, give the existing ones a skill

The agent count was not the achievement

The work on 28 July accelerated research-backed skill packages and specialist capabilities. The recorded concern was that agent count and skill research could outpace tested deployment.

My next step was to improve the existing agents before creating new ones, and to require acceptance tests.

That is a useful constraint in an environment where a new agent can be described almost instantly. A role, a name and a paragraph of instructions can make the organisation feel larger. The ability to complete useful work does not necessarily grow at the same speed.

Today’s direction was to strengthen what was already there. A specialist should be useful because it can perform a defined task under clear conditions, not simply because it has a more specific title than the previous specialist.

The work moved towards research-backed instructions and testable capabilities. It did not establish that every researched skill had already become a dependable deployed behaviour.

A skill is a way of doing work

A useful skill gives a system more than background information. It describes how to approach a class of task, what inputs are needed, what constraints apply and how to recognise an acceptable result.

That makes it different from a personality description. “Be a careful analyst” may influence tone. A task-specific procedure can identify which evidence to inspect and what to do when the necessary information is missing.

Consider a hypothetical skill for checking a research brief. It might require verifying that major claims have relevant sources, that the summary preserves qualifications, and that unsupported conclusions are marked for revision. Those instructions are more actionable than asking the reviewer to be thorough.

The example is illustrative, not a package claimed as completed on 28 July. It explains the value of the day’s skill work. The aim was to make specialist behaviour more repeatable and less dependent on the founder rewriting the same expectations in every request.

Research should change the instructions

A research-backed skill should have a visible relationship to what the research taught. Otherwise “research-backed” becomes a label attached to an ordinary prompt.

The useful question is which part of the procedure changed because of the evidence. Did the research identify a failure mode? Clarify a prerequisite? Suggest a better way to assess the output? Reveal a limit that the skill should preserve?

Not every source needs to become an instruction. Some information may be background context, some may be uncertain, and some may not apply to the intended task. The skill needs judgement about relevance as well as a collection of material.

For UBIKITOS, this matters because a library can grow rapidly without producing better execution. A useful package should help an existing agent do a particular job more reliably. The acceptance test then asks whether that intended change is observable.

The day’s work was moving in that direction, with tested deployment still the standard to earn.

The test should be able to disappoint you

An acceptance test is valuable because it can show that the skill does not yet meet its purpose.

If the test merely checks that the agent produced an output with the expected headings, it may reward presentation while missing the task’s substance. A review skill could fill every section and still fail to identify an unsupported claim.

A better test is connected to the intended behaviour. It should include cases that make the requirement matter, including awkward or incomplete inputs where appropriate.

For a hypothetical source-checking skill, that might mean a brief with a citation that does not support the claim beside it. The agent should recognise the mismatch rather than being reassured by the presence of a link.

These are examples of test design, not results reported for the day. They explain why acceptance tests belonged in the next action. The project needed a way to distinguish a well-written skill package from a capability that actually helped the work.

Existing agents are a useful baseline

Improving an existing agent provides a practical comparison point. What could it do before the change, and what can it do afterward under comparable conditions?

Adding a new agent can make that comparison harder because several things may change at once: the role description, the tools, the context and the workflow around it.

That does not mean new agents are never useful. It means the reason for adding one should be clearer than the availability of another attractive name.

The recorded instruction to upgrade existing agents first was a way to control that expansion. It asked the project to demonstrate a better capability before multiplying the organisational structure around it.

A founder benefits from that discipline because every additional component carries maintenance and coordination work. The system should earn its complexity by making a useful difference, not simply by distributing the same uncertainty among more roles.

A library also needs to know when a skill applies

Even a good procedure can be unhelpful when used in the wrong context. A skill needs a recognisable scope.

What kind of task is it intended for? Which inputs does it assume? What should the system do if those assumptions do not hold? Can a user override an ordinary preference while preserving an important safety boundary?

Those questions help prevent a library from becoming a collection of rules applied mechanically to every request. A procedure for one kind of report may be inappropriate for a quick answer. A checklist intended for a consequential action may be unnecessary for a harmless draft.

The 28 July record does not establish a complete skill-selection system. It records capability research and the need for tested deployment. Scope is part of what the resulting packages would have to make clear.

The goal is a library that helps the agent recognise useful guidance at the right moment, rather than a library whose size becomes another thing to celebrate.

The next improvement needed to show up in the work

The day advanced skill research and specialist capability development. The next action was to strengthen existing agents and require acceptance evidence before expanding further.

That gave the project a concrete standard: a new package should change something observable about a real task. It should help the system use better information, follow a clearer process or produce a more acceptable result.

If it did not, the package might still contain useful research, but it had not yet earned a deployment claim.

For the diary, the interesting part is the decision to slow organisational growth in favour of capability. A larger cast of agents would have looked impressive in a diagram. A smaller set of agents that could do their jobs better would be more useful at the workbench.

The next specialist did not need a name yet. The existing ones needed a test they could pass for a reason.