An Agent Builds an Agent: A Method for Verifiable Automation

A profession as a hidden language

Two similar commands can sit next to each other on an automotive diagnostic tablet. One reads fault data; the other clears it, starts a service procedure, or changes the state of an electronic unit. An experienced technician understands the diagnostic stage, what has already been checked, and the consequence of the next step.

For a naïve AI system, there are only labels and rectangles. Recordings can produce a convincing next-click demonstration, but not a production agent: they do not prove that a model distinguishes a safe action from a harmful one, recognises a state change, knows the boundary of its evidence, or can stop.

This case studies a different route. Agent systems help build another agent system: observation and telemetry come first; a separate layer turns observations into structured data; later roles extract recurring decisions, design contracts, and try to break the construction. A runtime agent obtains permission to act only after review—first in simulation, then observation mode, then within a bounded execution loop.

From recording to meaning

Most professional knowledge is absent from manuals. A procedure may describe connecting an instrument, running a scan, opening a problematic unit, and preparing a report. It rarely records the micro-decisions: whether a screen has stabilised, whether a list continues below the fold, whether identical labels belong to different modules, or whether a report proves completeness.

A video preserves an image of a process, not its inspectable structure. Tap coordinates break after scrolling, a new application version, or another screen state. Each step therefore needs an evidence trace: what the specialist saw, the physical action, intermediate states, the stable screen after it, the expected change, and what remains uncertain. Visible text, the physical touch, the professional meaning of an action, and the reason it was selected must not be conflated.

An agent factory, not a self-improving model

“An agent builds an agent” does not mean one model rewrites its own code, examines itself, and declares itself ready. It means separation of work and authority. Roles may use the same or different models, but each has its own input, permissions, and acceptance criterion.

Developer and observer agents

Coding agents can help inspect a system, write safe probes and recorders, define data schemas, validators, tests, and reproducible run instructions. The first boundary is decisive: this layer observes an operator; it does not control the diagnostic application. A multimodal observer then describes screens: type, active layer, visible text, controls, modals, and uncertainty. Its task is not “what should be clicked?” but “what is currently observed?”

Curator, analyst, architect, and testing agents

The curator verifies archive integrity, connects events over time, normalises action names, finds gaps, and produces technical reports. The analyst extracts the grammar beyond coordinates: which state precedes an action, what justifies a transition, what confirms completion, and when to ask a person or refuse to continue. Multiple traces become a graph of states and decisions, not a macro.

The architect can prepare typed inputs and outputs, a bounded vocabulary of intentions, progress memory, and completion rules. Consequential actions remain in a deterministic host layer. An independent testing role searches for missing branches, unsupported transitions, unstable screens, excessive authority, and cases where confidence is not evidence. Negative results enter the corpus rather than being hidden.

Transfer the rule, not the route

High-quality sessions are useful when they cover states, exceptions, and reasons for decisions. The unit of value is an inspectable trajectory: state, permitted goal, step, result, confirmation, and boundary of applicability. Instead of “press coordinate X”, the rule becomes: if this module is selected, it contains this fault, the screen is stable, and the previous branch is closed, an action from a restricted set may be proposed. If a sign is not established, the system asks a person or stops safely. This is close to grounding: a model may propose an intention, but it does not become action until matched with the available state and an allowed skill.^saycan

The model predicts; the system permits

A model is useful when it recognises a situation, proposes alternatives, or signals uncertainty. An action with consequences must be authorised by code and current state. This is least privilege in practice: an executor may understand the task broadly but receives only the one necessary, evidenced operation. The permission layer checks freshness of observation, a single match between intention and action, the allowed operation, absence of competing conditions, and post-action confirmation. Where evidence is insufficient, the correct result is ask human or safe stop, not a guess.

When an agent checks an agent

Conventional testing asks whether code meets predefined requirements. LLM systems need more: a model can be right for the wrong reason, use a future screen, confuse context, or declare a task complete while an important branch remains below the fold. Historical sessions should be replayed causally: at every step the agent sees only what existed then. Its proposal is compared with the workflow goal, safety rules, and evidence of completion—not only the human touch.

Evaluation includes delayed screens, unexpected modals, similar labels, failed retries, missing physical confirmation, and contradictory data. The point is not to claim that every error disappears, but to make an error visible before a consequential action.

What the system can and cannot replace

Automation may augment repeatable questioning, work-sequence preparation, completeness checks, report collection, trace comparison, or deviation detection. It does not automatically acquire authority for physical confirmation, disputed diagnosis, state change in a unit, or a responsibility decision. A person defines the goal, approves boundaries, resolves exceptions, checks disputed labels, and decides whether autonomy can expand.

Automotive diagnostics is a useful example because it combines physical equipment, a closed application, many states, repeatable workflows, and a visible cost of error. The method can also apply to laboratory instruments, industrial interfaces, medical administration, legal research, document flows, and operations. The first valuable product may be a recorder, quality-control layer, or shadow agent that learns without intervening.

Law as architecture

Recording experience is data processing. An implementation must define purpose, scope, retention, access, anonymisation, and the separation of primary evidence from research references. GDPR principles such as data minimisation and privacy by design shape process recording from the start.^gdpr

The AI Act adds transparency and risk-oriented assessment. From 2 August 2026, Article 50 applies to certain transparency obligations; the European Commission discusses interactive systems, synthetic content, and public text without human editorial control.^{ai-transparency} This does not make every diagnostic AI high-risk, nor guarantee the opposite: qualification depends on intended purpose, actual function, and context.^ai-act For automotive work, Data Act guidance on vehicle data and access arrangements is sector-specific and cannot be transferred automatically to other fields.^data-act

A new unit of production

The unit of engineering work is observation, data, contract, test, and bounded action. Language and multimodal models can propose schemas, create edge cases, replay historical sessions, find errors, and support runtime systems. The more stages are entrusted to models, the more important provenance, role separation, frozen tests, deterministic boundaries, and a human readiness decision become.

An agent builds an agent. Evidence builds trust. The right to act is still created by a person—through architecture, rules, and accountability.

Limitations and status

This project remains at a research and staged-validation stage. It does not claim safety certification, conformity with a particular AI Act category, access to manufacturer data, readiness for autonomous control of vehicle functions, or verified production metrics.

AI tools assisted with structure and editorial preparation. The author checks the facts, conclusions, and published edition and takes editorial responsibility for it.

Sources

1. Brown, T. B. et al. Language Models are Few-Shot Learners, 2020.^few-shot
2. Ahn, M. et al. Do As I Can, Not As I Say: Grounding Language in Robotic Affordances, 2022.^saycan
3. Brohan, A. et al. RT-2: Vision-Language-Action Models Transfer Web Knowledge to Robotic Control, 2023.^rt2
4. Regulation (EU) 2016/679 (GDPR), Articles 5 and 25.^gdpr
5. Regulation (EU) 2024/1689 (AI Act), Articles 4 and 50.^ai-act
6. European Commission, Guidelines on transparency obligations under Article 50 of the AI Act, 2026.^{ai-transparency}
7. European Commission, Guidance on vehicle data, accompanying the Data Act, 2025.^data-act