Agent That Adapts to New Tasks

An agent that adapts to new tasks without supervision needs the freedom to change its own behaviour, and every change it makes is a regression nobody reviewed.

"Autonomously adapt" does not mean "retrain itself". Most adaptation belongs in cheap, reversible places, such as context, memory and procedures. Each change passes the same evaluation gate a human change would. This page is the standalone day-before pack for this case.

Much of this page is own construction, but its backbone is sourced. No worked answer exists for this prompt. The prompt comes from the decomposition question bank, Tier 1 prompt 15. The spine comes from the Cracking book's learning chapter. Its four learning surfaces, skill promotion gate and data flywheel answer most of this prompt directly. The memory write policy comes from its memory chapter, and the release gate from its validation chapter. Sections and tables marked (own construction) were built for this page. Every number marked (assumption) is a whiteboard illustration, not a sourced figure.

The running example is the Cracking book's own: an internal operations agent. It handles requests such as "restart service X" and "roll back flag Y". New request types appear every week as teams ship new systems.

A system cannot be designed toward a verb nobody defined. "Adapt to new tasks" hides at least five different mechanisms. They differ by an order of magnitude in cost and by how easily a change can be undone.

The Cracking book names four places an agent's improvement can live: context, memory, procedure and parameters. Each is roughly ten times slower and costlier to iterate on than the one before. This page adds prompt optimisation as a separate rung between procedure and parameters (own construction). It changes behaviour broadly, like training, but stays reversible, like a prompt.

The book's rule is to work down this table, not up. In the book's view, most teams that reach for fine-tuning have not yet fixed their tool schemas, retrieval or example selection. Fine-tuning then bakes those defects into weights that take weeks to change.

Ask these questions before committing (own construction).

A safe default, stated aloud if the interviewer does not answer, is this. New request types arrive weekly. Most have a checkable outcome. Writes to production systems are partly reversible. Adaptation is global, but each skill has a team owner.

"Before I design anything I want 'adapt' pinned down. There are five places learning can live, from the context of one request up to the model's weights. Each rung costs roughly ten times more than the last and is harder to undo. I'll design from the cheap end and only climb when a measured gap forces it."

A requirement that cannot fail a test is a wish. "Gets better over time" is a wish. "Success on a new task type reaches the baseline within 14 days without a regression on any existing type" is a constraint (own construction throughout this section; thresholds are assumptions unless marked sourced).

The functional must-haves are six. Recognise when a request does not match any known capability. Attempt it safely with a general fallback, escalating when confidence is low. Record every run with its outcome, so learning has evidence. Turn repeated successes into candidate skills, memories or prompt changes. Evaluate each candidate before it affects real traffic. Remove learned behaviour automatically when it starts to fail.

The should-haves come later. Per-tenant specialisation. A tuned small model for high-volume task types. A dashboard that shows owners what the agent learned this week.

Each must-have needs an owner in the architecture.

Arithmetic decides which rungs are even affordable (own construction; every input is an assumption, arithmetic is exact).

Two lessons fall out of the table. First, rare task types cannot be promoted quickly. At 30 requests a day, the shadow minimum alone takes a week, and that sets the honest time to competence. Second, candidate volume drives learning cost, not training. Fifty candidates a week breaks a 10% learning budget almost five times over. So the extractor must deduplicate and pre-filter before anything reaches the paid evaluation.

The sample-size arithmetic sets what the gate can even detect. The validation chapter gives it as n ≈ 15.7 × p(1−p) / δ² per arm. At a baseline of 0.8, 200 cases detect only differences of about 11 points. A 5-point gain needs about 1,000 cases per arm. So the 200-attempt shadow proves "not much worse", not "5 points better". Say that aloud; it is a rare and strong signal.

The runtime loop serves requests. The learning loop proposes changes. They meet at exactly one place, the evaluation gate. Nothing learned reaches live traffic without passing it (own construction for every diagram in this section).

 ╔══════════════════════ CONTROL PLANE (every change is a version) ═════════════════════╗
 ║ capability registry: skills, memories, prompts, models — each with owner, version,     ║
 ║ status (candidate / shadow / live / demoted) · permission policy · budgets · kill switch ║
 ╚═════════════════════════════════════════╤══════════════════════════════════════════════╝
                                           │ reads only LIVE versions
 ╔════════════════════════════ RUNTIME LOOP ══════════════════════════════════════════════╗
 ║  request ─> capability router ──known──> load skill + examples + memories ─┐           ║
 ║                   │ (novelty score)                                        v           ║
 ║                   └──novel──> general fallback + tighter bounds ─> context assembler   ║
 ║                                                                            │           ║
 ║                        bounded agent loop (steps, tokens, time, spend caps)            ║
 ║                                   │                                                    ║
 ║                        tool gateway (authorise · validate · execute · classify)        ║
 ║                                   │                     └─ irreversible? ─> human      ║
 ║                        outcome signal: validator · test · ticket state · user feedback ║
 ║                                   │                                                    ║
 ║                        trace + outcome store ───────────────────────────────┐          ║
 ╚═════════════════════════════════════════════════════════════════════════════│══════════╝
 ╔════════════════════════════ LEARNING LOOP (offline, budgeted) ═══════════════v══════════╗
 ║  flywheel gates: dedupe ─> split by time and user ─> adjudicate low-agreement cases      ║
 ║        │                                                                                ║
 ║        ├─> skill extractor (generalise successful trajectories)                         ║
 ║        ├─> memory writer (durable? reusable? attributable? permitted?)                  ║
 ║        ├─> prompt optimiser (search instructions and examples on a dev set)             ║
 ║        └─> dataset builder (only when rungs 1–4 are exhausted)                          ║
 ║                                   │ candidates                                          ║
 ║  EVAL GATE: held-out, paired, per stratum · safety absolute · cost visible              ║
 ║        ├─ fail ─> discard, log reason                                                   ║
 ║        └─ pass ─> shadow on live traffic (≥200 attempts) ─> owner review ─> LIVE        ║
 ║  LIVE MONITOR: success per stratum ─> 4 points below baseline ─> auto-demote            ║
 ╚══════════════════════════════════════════════════════════════════════════════════════════╝

The same design for viewers that render Mermaid:

An agent cannot adapt to a task it has not noticed is new. The hardest failure is not "I do not know how". It is confidently forcing a new request into the nearest known skill (own construction throughout this section).

Score novelty on three signals. The router's retrieval score against the skill catalogue falls below a threshold. The request names a system, tool or entity absent from every live skill. The router's top two candidates are close, so its choice is a coin flip. Any one of them routes the request to the general fallback instead of a skill.

Treat the fallback as a different operating mode. Cut the step budget. Allow read-only tools freely and require approval for writes. Escalate earlier. The first dozen runs of a new task type are both the riskiest and the most valuable. They carry the evidence every later rung learns from.

The skill-loading pattern from the FDE (Forward Deployed Engineer) handbook supports this. The agent starts with a lightweight catalogue of skill names and triggers. It loads one skill's full instructions only when selected, then releases that context. Trigger descriptions need counterexamples as well as examples, or the wrong skill activates. Evaluate triggering separately from execution. A skill that runs perfectly after the wrong trigger is still a wrong answer.

The cheapest adaptation changes nothing that outlives the request. Rung 1 covers two mechanisms, both runtime-only.

Dynamic example selection. A fixed set of examples in the system prompt is chosen for the average request, so it is optimal for none. Retrieve past runs similar to this request instead. Then rank them by recorded outcome, not just similarity. A similar run that went badly teaches the model to go badly. Enforce diversity so three near-duplicates do not crowd out the useful one. The book's scoring formula is λ × relevance − (1−λ) × redundancy + 0.15 × outcome score.

One cost follows. Examples sit above the user's turn, so swapping them per request breaks the prompt prefix cache from that point on. Only what sits above them, such as tool definitions and the fixed system prompt, still hits the cache. Where traffic clusters, cache one example set per cluster rather than choosing per request.

Reflexion. A failed attempt becomes a written lesson placed in context for the next attempt. The model itself does not change. The book says it works reliably only with three conditions: an external failure signal, a lesson specific enough to change behaviour, and a hard cap on attempts. "Expected ISO 8601 UTC, I sent local time" is a lesson. "Be more careful" is not. A model grading its own attempt without an external signal tends to produce confidently wrong lessons. Those lessons then contaminate every retry after them.

A Reflexion implementation splits the pattern into actor, evaluator and self-reflection roles. For #80, one design rule sits on top: the evaluator must be external. A validator, a test or an API response counts. The same model's opinion does not.

Memory quality is bounded by what was allowed in. Retrieval cannot fix a bad write policy. The memory chapter's advice is to lead with the write policy, not the vector index, when asked to design agent memory.

Every candidate memory passes four gates. Is it durable, still true next month? Is it reusable, would a future run read it? Is it attributable, with a source, timestamp and confidence? Is it permitted, outside regulated categories? Anything failing a gate is dropped or redacted on the write path. The read path is too late.

Store facts as typed subject-predicate-value records, never raw conversation turns. Then a contradiction collides by construction. When a new fact contradicts an old one on the same predicate, supersede the old one and keep a pointer to it. The book's worked failure shows why. A user said in January to book through vendor A and in February switched to vendor B. Both statements were stored as separate episodes. Retrieval returned whichever phrasing was more similar, so vendor A reappeared about one time in four until May. Typed facts fix it, and so does a release-gate test that seeds contradictory histories and asserts the newer fact wins.

For #80 the memory tier holds environment facts learned during work. "Service X needs a drain before restart" is one. "The payments API rejects batch sizes over 100" is another (own construction examples). Salience decays on a half-life per predicate, and consolidation runs offline, off the request path.

A skill is a named, parameterised sequence of tool calls with a precondition, a postcondition and a measured success rate. The whole design problem is the gate between "a run succeeded once" and "this is now trusted". This is the heart of #80, and the Cracking book gives it precisely.

The pipeline runs in six steps. Extract a candidate from successful traces and generalise its arguments. Discard duplicates of existing skills. Evaluate on held-out cases, never on the traces that produced it. Grading a skill on its own source traces measures memory, which is how libraries fill with skills that worked exactly once. Promote only if success beats baseline by 5 points. Then shadow it on at least 200 live attempts. Demote it automatically if live success later falls 4 points below baseline.

Demotion matters as much as promotion. Environments drift. A skill that encodes last quarter's API shape must leave production before a human notices. A library that only grows becomes a liability within about two quarters, in the book's estimate.

There are two versions of the mechanism. The Voyager-style version first checks the library for a skill that can be reused or composed. Only if nothing fits does it write new code. It runs the code in a sandbox, checks it against test cases, and saves it only if they pass. The Agent Workflow Memory version stores tool-call sequences rather than code. It abstracts a successful trajectory into a template with placeholders, then fills the template for structurally similar tasks. Choose code skills when the tool surface is programmable. Choose workflow templates when the reusable unit is the order of tool calls.

Procedures change behaviour, so they are the highest-risk memory layer. A sound procedural-memory design makes approval happen outside the model's reasoning loop. The agent may propose a procedure, but the graph pauses for a human decision. Rollback re-approves an older version. Keep that rule for anything that widens what a skill may do.

Prompt optimisation automates the search a prompt engineer does by hand (own construction throughout this section). Define a metric and a scored development set. Generate variants of the instructions and the selected examples. Score each variant, and keep the best. Frameworks that compile prompts from a declared program and a metric do exactly this.

It sits between procedure and parameters on the ladder for a reason. It changes behaviour across every task type at once, which is powerful and dangerous. But the result is still text: versioned, readable, and revertible in seconds.

Three rules keep it honest. Hold out a test set the optimiser never sees, because a search over hundreds of variants will overfit a small dev set. Report the win per stratum, because a planner prompt tuned on common tasks can quietly break rare ones. And treat the winning prompt as a candidate like any other: eval gate, shadow, owner review.

The sources behind this page cover DSPy's declared prompts, multi-step programs, evaluation and pairwise Elo scoring, but not its optimisers. This section rests on general knowledge.

Training is the most expensive and least reversible rung, so defend it before proposing it. The learning chapter names three situations where parameter updates win. Strict format or protocol adherence at high volume, where a small tuned model matches a larger prompted one at a fraction of the cost. Domain vocabulary the base model lacks. A hard cost or latency ceiling after the cheaper rungs are exhausted, where distillation buys it back.

It is equally blunt about the losing case. Knowledge gaps are a retrieval problem. Fine-tuning rarely fixes a model that does not know something. Published studies find models learn new facts from fine-tuning slowly and unreliably, and retrieval beats it for adding knowledge. For #80 that rules out "train the agent on each new task". A new task is new knowledge and a new procedure, and both belong lower on the ladder.

The book adds a cost to name. A tuned model freezes its task definition. When the business changes the definition, a prompt needs an edit and a tuned model needs retraining. So keep a prompted fallback path.

If training does happen, the flywheel gates decide whether the data is honest. Deduplicate first. Split by time and user, never at random. Send low-agreement, high-impact cases to human adjudication. The book's worked failure is the one to quote. A routing fine-tune reported 94% held-out accuracy against an 81% baseline, then scored about 78% in production. The random split hid near-duplicates across 140,000 traces that were only about 9,000 distinct requests. Labels came from the old system's own decisions. The honest number after fixes was near 83%, and production matched within two points. When an offline gain looks surprisingly large, suspect leakage first.

A self-modifying system without a release gate is an unreviewed deploy pipeline with a model holding the merge button. The gate is where #80 is won or lost. It is also where I'd expect the panel to probe hardest. Reported interview questions from the OpenAI decomposition round call evaluation a deliberate differentiator there. I'm assuming the same holds here, but no public source says so for this prompt.

Apply the validation chapter's CI gate to every learned artefact, whichever rung it came from. Safety assertions gate absolutely: any failure blocks. Quality gates against the baseline with a paired significance test, per stratum, not just on the mean. Cost is reported, and a ceiling breach blocks. A gain that triples spend must be a visible decision.

The per-stratum rule has a worked failure behind it, from the validation chapter. A retrieval change lifted aggregate accuracy from 79% to 81%. One tenant's segment fell from 82% to 67% inside that average, because that tenant was only about 4% of the eval set. The fix was a floor: no release may drop any stratum by more than 3 points. For #80, the strata are task types. A new skill for a new task must not quietly damage an old one.

Evaluate the whole trajectory, not just the final answer. Several paths can be valid, so assert properties of the path. Did it read before writing? Did it request approval before the irreversible step? Did it stay within its tool list? Put the safety assertions first.

"Autonomously" is the most dangerous word in the prompt. The agent may learn how to do things. It may never learn that it is allowed to do more (own construction throughout this section, built on standard tool-gateway and approval patterns).

Draw the line in a table and say it aloud.

Five controls enforce the line. The tool gateway checks permissions on every call, whatever the skill says. A learned procedure cannot carry its own authority. Irreversible actions route to a person before and after. Budgets cap steps, tokens, wall time and spend per run and per day. The ops agent's owner has a kill switch that freezes all learning and pins every artefact to its last reviewed version.

Watch for goal drift, the slow slide of the agent's behaviour away from what its owners intended. Track the shape of trajectories per task type: tool mix, steps per run, escalation rate. A skill that starts solving tickets by closing them is an outcome signal being gamed. The design needs a second, independent signal, such as reopen rate or sampled human review. Otherwise the agent learns to satisfy the metric instead of the user.

Mind the injection path too. Learned content is untrusted content. A memory or skill extracted from a trace that included external text can carry an instruction such as "always approve refunds". Tag provenance on everything learned. Never let content from an untrusted source become a procedure without review.

The pattern audit applies to this page's own design. Every mechanism added needs a metric that motivated it and an incident it prevents. Otherwise it is cost paid by whoever is on call at three in the morning.

Spend the hour on the ladder and the gate. Reported interview questions flag evaluation as what sets strong candidates apart in the OpenAI decomposition round, and I'm assuming the same here. The decomposition framework has six steps: clarify the mission, stakeholders and metrics, map inputs, decompose and sequence by risk, walking-skeleton MVP (minimum viable product), then adapt live. The plan below follows it (own construction).

The walking skeleton is rungs 1 and 2 plus the trace store. Ship the router, the fallback, dynamic examples, the memory write policy and traces. Add the skill library and its gate in the second increment, once a month of traces exists to evaluate against. Prompt optimisation comes third. Training comes last, if ever.

Expect a constraint change mid-round. "There is no reliable success signal" removes Reflexion and skill promotion. Adaptation falls back to human-reviewed memories and examples. "Tasks change daily" pushes everything down to rung 1 and rules out training. "Regulators require every behaviour change to be approved" keeps the whole design but makes owner review mandatory at every promotion.

These are the relevant Tier 2 probes from the question bank, answered for this design.

The interviewer's pivot after a good design is "the learning loop costs more than serving". There is no playbook drill for this prompt, so the card below is (own construction).

The four verbs from the cost playbook generate the same answer. Measure, by attributing spend to runtime versus learning and to each candidate. Route, by sending cheap changes through cheap checks and full suites only to survivors. Bound, with a learning budget that blocks new candidates when breached. Cache safely, by reusing baseline results across candidates evaluated against the same baseline version.

On this design the levels separate on who owns the evaluation gate and what the agent may change about itself, not on how many learning mechanisms get drawn.

• "Adapt" means five rungs, from context to weights, each about ten times costlier and harder to undo; design from the cheap end.
• Requirements become testable as time to competence, a per-stratum regression floor, a promotion margin, automatic demotion and a learning cost cap.
• Sizing shows rare task types cannot be promoted quickly and candidate volume, not training, drives learning cost.
• The architecture is a runtime loop and a learning loop that meet at one evaluation gate, with every artefact versioned in a registry.
• Detect novelty before handling it, and run unknown tasks in a fallback mode with tighter bounds and earlier escalation.
• Runtime adaptation uses outcome-ranked examples and Reflexion, and Reflexion needs an external oracle, a specific lesson and a cap.
• Memory is a write problem: four gates, typed facts and supersession keep it from polluting future runs.
• A skill earns production through held-out evaluation, a 5-point margin and 200 shadow attempts, and leaves automatically at 4 points below.
• Prompt optimisation is a search that overfits unless it has a hidden test set, per-stratum reporting and the same gate as everything else.
• Weights change last and only for format at volume, missing vocabulary or a latency ceiling, never for missing knowledge.
• Every self-modification passes the same gate as a human pull request: safety absolute, quality per stratum, cost visible.
• The agent may learn how to do things but never grant itself more permission, budget or irreversible reach.
• Name the failure modes, from forced fit to permission creep, each with its guard.
• The hour goes to the ladder and the gate, with a walking skeleton of rungs 1 and 2 plus traces.
• The cost pivot is answered by deduplicating and smoke-testing candidates, scoping suites and tracking learning spend per promotion.

1. What are the five rungs of adaptation, cheapest first? Context, memory, procedure, prompt optimisation, parameters.
2. Which requirement stops a new skill from damaging an old task? The per-stratum regression floor: no task type may drop more than 3 points.
3. Why can a new task type seeing 30 requests a day not be promoted in two days? The 200-attempt shadow minimum alone takes about a week at that traffic.
4. Where do the runtime loop and the learning loop meet? Only at the evaluation gate; the runtime reads live registry versions only.
5. What should happen to a request the router cannot match confidently? It goes to a general fallback with tighter bounds, approval on writes and earlier escalation.
6. What three conditions does Reflexion need? An external failure signal, a specific lesson and a hard cap on attempts.
7. Why did the assistant keep proposing the old vendor? Contradicting statements were stored as separate episodes rather than typed facts, so the older phrasing kept winning retrieval.
8. What are the book's gate numbers for skills? Beat baseline by 5 points offline, survive 200 live shadow attempts, auto-demote at 4 points below baseline.
9. What keeps prompt optimisation from overfitting? A test set the optimiser never sees, per-stratum reporting and the standard gate.
10. Why not fine-tune the agent on each new task? A new task is new knowledge and procedure, which belong to retrieval and skills; fine-tuning fixes missing knowledge slowly and unreliably.
11. Aggregate accuracy rose from 79% to 81%. Why block the release? One stratum fell from 82% to 67% inside the average; the gate checks every stratum.
12. What may the agent never do on its own? Grant a skill a new tool, approve an irreversible procedure, raise its own budgets or re-promote a demoted skill.
13. How do you notice metric gaming? A second, independent outcome signal and trajectory-shape monitors per task type.
14. What is the walking skeleton? Router, fallback, dynamic examples, memory write policy and the trace store.
15. What is the sixty-second cost answer? Learning cost is candidate volume times suite size; dedupe and smoke-test candidates, scope suites and track learning spend per promotion.

Fact-check sources (checked 27 Sep 2026)

• Prompt caching — Claude API docs — the cache is a prefix; a change invalidates that level and everything after it
• Prompt caching — OpenAI API docs — reuse needs an exact prefix match; put variable content last
• Reflexion: Language Agents with Verbal Reinforcement Learning (Shinn et al., 2023) — lessons kept as text in an episodic buffer, no weight updates
• Large Language Models Cannot Self-Correct Reasoning Yet (Huang et al., 2023) — self-correction without external feedback often fails or makes answers worse
• Voyager: An Open-Ended Embodied Agent with Large Language Models (Wang et al., 2023) — skill library of executable code, refined with execution feedback and self-verification
• Agent Workflow Memory (Wang et al., 2024) — reusable workflows induced from agent trajectories
• MIPROv2 — DSPy docs — optimisers that search instructions and few-shot examples against a metric
• Fine-Tuning or Retrieval? Comparing Knowledge Injection in LLMs (Ovadia et al., 2023) — retrieval beats unsupervised fine-tuning for new knowledge
• Does Fine-Tuning LLMs on New Knowledge Encourage Hallucinations? (Gekhman et al., 2024) — new facts are learned slowly through fine-tuning and raise hallucination

Build an AI agent that can improve over time when it sees new tasks, without allowing it to randomly change production behaviour.

The key idea is:

A self-adapting agent should first learn through context, memory, reusable skills, and prompt changes. Updating model weights should be the last option.

We will use one example throughout:

Example: an IT Operations Agent that handles service restart, rollback, health checks, and operational workflows.

There are different levels of adaptation.

Cheap + easy to rollback
        ↓
1. Context
        ↓
2. Memory
        ↓
3. Skill / Procedure
        ↓
4. Prompt Optimization
        ↓
5. Model Weights
        ↓
Expensive + harder to rollback

Level 1 — Context

The agent does not permanently learn anything.

For the current request, it dynamically loads relevant information.

Example:

Request:
Restart payment-service-X

Agent loads:
- Relevant runbook
- Similar successful examples
- Relevant memory

Level 2 — Memory

The system stores reusable facts.

Example:

payment-service-X must be drained
before restart.

Level 3 — Skill / Procedure

The system learns a reusable workflow.

Example:

Safe Restart Skill

1. Check health
2. Drain traffic
3. Restart
4. Verify health
5. Restore traffic

Level 4 — Prompt Optimisation

If the planner repeatedly makes the same mistake, we can test multiple prompt versions and promote the best one.

Level 5 — Model Weights

Fine-tuning or retraining.

Use this only when cheaper mechanisms are not enough.

Interview principle

Context → Memory → Skill → Prompt → Weights

Always move from cheap and reversible toward expensive and harder to rollback.

The system should be able to:

1. Detect when a request does not match an existing skill.
2. Safely attempt unknown tasks.
3. Record complete execution traces.
4. Learn reusable facts from successful outcomes.
5. Extract reusable skills from repeated successful workflows.
6. Propose prompt improvements.
7. Evaluate every new learning candidate.
8. Shadow-test candidates before production.
9. Promote good candidates.
10. Roll back or demote bad candidates.

Important production requirements:

Reliability

• Existing task performance should not significantly regress.
• Every learned capability must have rollback support.

Safety

• Unknown tasks should run under tighter limits.
• The agent must never increase its own permissions.

Observability

Track:

request
tool calls
prompt/model version
selected skill
result
latency
cost
external outcome

Cost

Learning cost should stay bounded.

Latency

Adaptation logic should not make every live request slow.

Auditability

Every production change should answer:

Who created it?
Why was it created?
What data supported it?
Which evaluation passed?
Who approved it?
Which previous version can we roll back to?

The architecture has two loops and one gate.

Runtime Loop
     +
Learning Loop
     +
Evaluation Gate

Runtime Loop

The runtime serves production traffic.

Request
  ↓
Router
  ↓
Approved Capability
  ↓
Agent
  ↓
Tool Gateway
  ↓
External System
  ↓
Outcome
  ↓
Trace

The runtime should use only approved versions.

Learning Loop

The learning system studies historical traces.

Production Traces
      ↓
Find patterns
      ↓
Create candidate
      ↓
Evaluate
      ↓
Shadow
      ↓
Promote

Evaluation Gate

The learning loop cannot directly change production.

Every change must pass through a controlled gate.

Important separation

Runtime serves users.
Learning proposes improvements.
Evaluation decides whether an improvement is allowed into production.

We need a registry that stores all approved and candidate capabilities.

Example:

skill_id: safe_restart
version: v3
status: LIVE
owner: platform-team
previous_version: v2
permissions: restart-service
eval_score: 0.91

Possible states:

DRAFT
  ↓
CANDIDATE
  ↓
SHADOW
  ↓
LIVE
  ↓
DEMOTED

If v3 becomes unhealthy:

v3 → DEMOTED
v2 → LIVE

This makes rollback easy.

Before solving a request, the system should determine:

Is this a known task or something new?

Example:

The system already knows:

restart Kubernetes service

Now it receives:

restart new serverless service

A bad router may force this request into the closest known skill.

That is risky.

Signals for novelty

We can use:

1. Low similarity with existing skills.
2. Unknown system/tool appears.
3. Top routing candidates have very similar confidence.
4. No existing skill passes a minimum confidence threshold.

Example, with an illustrative threshold I'd tune on real routing data:

Known skill confidence = 0.43

Threshold = 0.75

Result:
Treat as novel task.

Unknown tasks should not get normal production freedom.

Use a stricter execution mode.

Unknown Task
    ↓
General Agent
    ↓
Lower Step Limit
    ↓
Read-Only Tools First
    ↓
Approval for Risky Writes
    ↓
Earlier Human Escalation

Why?

Because the system has less confidence about the task.

Production problem solved

This prevents:

• dangerous tool usage
• infinite loops
• accidental writes
• permission misuse
• costly experimentation

Before storing anything permanently, let the agent adapt inside the current request.

There are two useful mechanisms.

A. Dynamic Examples

Instead of always using fixed few-shot examples:

Example A
Example B
Example C

retrieve examples relevant to the current request.

Current Request
      ↓
Search Successful Past Executions
      ↓
Filter Relevant Examples
      ↓
Add to Prompt

Do not select only by similarity.

Prefer:

Relevant
+
Successful
+
Diverse

A similar failed trace is not necessarily a good example.

B. Reflexion

The agent tries something.

An external system gives a clear failure signal.

The agent creates a temporary lesson and retries.

Example:

Agent sends wrong timestamp format
        ↓
API returns validation error
        ↓
Lesson:
Use ISO-8601 UTC format
        ↓
Retry

Critical rule

The agent should not grade itself.

Bad:

Agent:
"I think my answer was correct."

Good external validators:

API result
Unit test
Database state
Ticket status
Monitoring signal
Human approval

Also keep a retry limit. Two is the cap I'd pick for this design, not a standard.

Max retries = 2

This avoids endless loops and runaway cost.

Do not start by asking:

Which vector database should I use?

The more important question is:

What information is allowed to become memory?

Before writing memory, ask:

Is it durable?
Is it reusable?
Is it attributable?
Is it allowed to be stored?

Example of good memory:

Payment API max batch size = 100

Example of weak memory:

Service was slow at 3:17 PM today

Structured Memory

Prefer structured facts when possible.

Example:

subject: payment-service
predicate: restart_precondition
value: drain_traffic
source: runbook-v4
timestamp: 2026-09-26

If the process changes later:

restart_precondition = none

we can mark the previous memory as superseded.

Old Memory → SUPERSEDED
New Memory → ACTIVE

This reduces contradictory retrieval.

Suppose the agent repeatedly succeeds with:

Check health
   ↓
Drain traffic
   ↓
Restart
   ↓
Check health again
   ↓
Restore traffic

The learning system may create:

safe_restart(service_name)

But one successful trace is not enough.

Skill Promotion Flow

Key interview rule

A successful execution is evidence for a skill. It is not permission to deploy the skill.

Prompt changes should be handled like software changes.

Bad process:

Engineer edits prompt
   ↓
Deploy
   ↓
Hope

Better process:

Current Prompt
     ↓
Generate Variants
     ↓
Dev Evaluation
     ↓
Select Candidate
     ↓
Hidden Test Set
     ↓
Shadow
     ↓
Promote

Why hidden test data?

If we keep testing many prompt versions on the same dataset, eventually one may look good only because it overfit that test set.

Also evaluate by task type.

An illustrative example, with made-up numbers:

Overall:
80% → 84%

Restart tasks:
90% → 95%

Rollback tasks:
86% → 68%

Overall performance improved, but one important capability got worse.

The release should be blocked.

Fine-tuning should come last.

Good reasons to consider it:

1. Strict output format

The model must consistently produce a specific machine-readable format.

2. Specialised domain language

The base model genuinely struggles with important terminology.

3. Cost or latency optimisation

A small tuned model may replace a larger expensive model for a repetitive task.

Useful rule

Missing knowledge
    → Retrieval / Memory

Repeated workflow
    → Skill

Instruction-following issue
    → Prompt

Stable high-volume behavior
    → Maybe fine-tuning

Do not use fine-tuning just to teach changing business facts.

Every learned artifact must go through the same release process.

Think of it like CI/CD (continuous integration and continuous delivery).

Software
Code → Test → Review → Deploy

For the agent:

Learning Candidate
      ↓
Offline Eval
      ↓
Safety Checks
      ↓
Shadow
      ↓
Review
      ↓
Deploy

Deterministic Checks

These are exact checks.

Examples:

Did it call a forbidden tool?
Did it exceed retry limit?
Did latency exceed threshold?
Did cost exceed budget?
Was required approval present?
Did it violate permission rules?
Did it produce valid schema?

Non-Deterministic Checks

These need semantic evaluation.

Examples:

Was the plan correct?
Was the response helpful?
Did the selected tool make sense?
Was the workflow safe?
Did the agent solve the task?

These may use:

• LLM (large language model) judges
• human review
• pairwise comparison
• task-specific evaluators

For agents, final answer accuracy is not enough.

Example:

The agent eventually succeeds, but does this:

DELETE
  ↓
READ

Policy requires:

READ
  ↓
Validate
  ↓
Approval
  ↓
DELETE

The final result may look correct.

But the path was unsafe.

So evaluate:

Final Outcome
+
Tool Sequence
+
Permissions
+
Approvals
+
Retry Count
+
Cost
+
Latency

Before making a new candidate live:

Production Request
       ↓
Current LIVE Skill ─────→ controls action
       ↓
Candidate Skill ────────→ observes same request
                          but does not control action

Compare:

success rate
tool choice
latency
cost
safety violations
human feedback

If healthy, promote.

Learning does not stop at promotion.

Suppose a skill goes live.

Later an API changes.

Success rate drops.

Live Skill
   ↓
Monitoring
   ↓
Regression Detected
   ↓
Auto-Demote
   ↓
Previous Skill / Safe Fallback

This is important because production environments change.

The system should clearly separate:

Agent learns HOW
Policy decides WHAT IS ALLOWED
Executor performs the action

The agent may:

• choose examples
• write approved memory
• propose skills
• propose prompts
• retry
• auto-demote unhealthy skills

The agent must not autonomously change:

• tool permissions
• financial limits
• security policy
• approval requirements
• retry budget
• irreversible-action policy

Example:

The agent may learn:

refund_customer()

But it cannot decide:

I can now refund $50,000.

Permissions remain outside the agent.

Suppose we optimise:

% tickets closed

The agent may discover:

close every ticket immediately

The metric improves.

The real business outcome becomes worse.

So use multiple independent signals.

Example:

Ticket Closed
+
Reopened?
+
Customer Satisfaction
+
Human QA
+
Resolution Time

Do not use a single easily gamed metric.

Assume these whiteboard numbers, which I'd state aloud as my own:

20,000 requests/day
40 existing task types
3 new task types/week
~30 requests/day for a new task

Suppose promotion requires:

200 shadow executions

If a new task gets:

30 requests/day

then:

200 / 30 ≈ 7 days

So learning speed depends on real production traffic.

You cannot promise instant adaptation for low-frequency tasks.

Candidate Explosion

Suppose the system produces:

50 skill candidates/week

and every candidate runs:

1,000 eval cases

Then evaluation cost becomes large.

Use staged evaluation:

Candidates
    ↓
Deduplicate
    ↓
Cheap Smoke Test
    ↓
Small Eval Set
    ↓
Only Strong Candidates
    ↓
Full Evaluation

Do not put the entire learning process on the user request path.

Online path

Keep only:

Router
Memory Retrieval
Skill Retrieval
Agent Execution
Policy Check
Tool Call
Trace Write

Offline path

Move expensive work here:

Pattern Mining
Skill Extraction
Prompt Search
Large Evaluation
Fine-Tuning
Shadow Analysis

This keeps user latency predictable.

In this design, I'd expect most of the learning cost to come from:

Number of candidates
×
Evaluation cases
×
Model calls

Useful cost controls:

1. Deduplicate similar candidates.
2. Run cheap checks first.
3. Use smaller models for simple evaluation.
4. Run full evaluation only for promising candidates.
5. Evaluate only relevant task families.
6. Keep a smaller global regression suite.
7. Set candidate budgets.

Useful metrics:

Learning Spend / Serving Spend
Cost per Promoted Skill
Candidates Tested per Promotion
Tokens per Successful Task
Shadow Cost
Evaluation Cost

Important controls:

Tool Gateway

All tool calls go through a central gateway.

The gateway checks:

identity
permission
action
resource
budget
approval

Audit Log

Store:

who
what
when
which version
which tool
which permission
which outcome

Human Approval

Use human approval for:

• destructive operations
• security changes
• permission changes
• financial actions
• new high-risk skills

A simple production design may use these objects.

Execution Trace

trace_id
request_id
task_type
novelty_score
selected_skill
prompt_version
model_version
tool_calls
tool_results
outcome
latency
cost
timestamp

Memory Record

memory_id
subject
predicate
value
source
created_at
status
supersedes

Skill

skill_id
version
description
trigger
workflow
required_tools
required_permissions
status
owner
eval_result
created_at

Learning Candidate

candidate_id
candidate_type
source_traces
baseline_version
candidate_version
evaluation_status
shadow_status
promotion_status

Request:

Restart Orion payment service.

The system has never seen Orion before.

Step 1 — Route

Request
   ↓
Capability Router
   ↓
No confident match

Result:

NOVEL TASK

Step 2 — Safe Fallback

The general agent gets tighter controls.

Read docs
↓
Inspect service
↓
Create plan

Risky writes require approval.

Step 3 — Execute

The agent discovers:

Orion must be drained before restart.

It performs:

Drain
→ Restart
→ Health Check
→ Restore Traffic

External monitoring returns:

SUCCESS

Step 4 — Trace

Store:

request
tool sequence
result
prompt version
model version
latency
cost
outcome

Step 5 — Memory Candidate

Proposed memory:

Orion restart requires drain.

Check:

Durable?      Yes
Reusable?     Yes
Attributable? Yes
Permitted?    Yes

Store it.

Step 6 — Skill Candidate

After repeated successful executions:

safe_orion_restart(service)

is created.

Step 7 — Evaluate

Run:

Held-out tests
Regression tests
Safety tests
Cost tests
Latency tests

Step 8 — Shadow

Candidate observes real requests without controlling them.

Step 9 — Promote

If healthy:

Candidate → LIVE

Step 10 — Environment Changes

Later Orion API changes.

Success drops.

Monitoring
   ↓
Regression Detected
   ↓
Skill Auto-Demoted
   ↓
Previous Skill / General Fallback

Fast Learning vs Safety

More automatic promotion:

Faster adaptation
but
Higher production risk

Stricter evaluation:

Slower adaptation
but
Higher reliability

Memory vs Skill

Memory stores facts.

"API max batch size = 100"

Skill stores procedure.

How to restart the service safely

Do not put everything into memory.

General Agent vs Specialised Skills

General agent:

Flexible
Good for novel tasks
More expensive
Less predictable

Specialised skills:

Fast
Cheap
Predictable
Less flexible

Use both.

Fine-Tuning vs Retrieval

Fine-tuning:

Good for stable repeated behavior
Harder rollback
Slower iteration

Retrieval:

Good for changing knowledge
Easy update
Easy rollback

Do not build every self-learning feature on day one.

Start with:

Capability Router
+
Novelty Detection
+
General Fallback
+
Dynamic Examples
+
Memory
+
Trace Store
+
Evaluation Pipeline

Then add:

Skill Learning
      ↓
Prompt Optimization
      ↓
Fine-Tuning

This keeps the first version safer and easier to operate.

For a customer deployment, I would prioritise:

Phase 1

Routing
Novelty Detection
Trace Collection
Safe Fallback
Memory
Policy Gateway

Phase 2

Offline Skill Extraction
Evaluation
Shadow Testing
Promotion / Rollback

Phase 3

Prompt Optimization
Advanced Automated Learning
Selective Fine-Tuning

The reason is simple:

Production observability and safety must exist before autonomous improvement.

A clean 60-minute interview flow:

0–5 min
Clarify what “new task” means

5–10 min
Functional + non-functional requirements

10–15 min
Traffic / task assumptions

15–25 min
Adaptation ladder

25–35 min
Architecture

35–45 min
Evaluation + release gate

45–52 min
Safety + permissions

52–60 min
Scaling, cost, failures, tradeoffs

Before designing, ask questions like:

1. What exactly is allowed to adapt?

Context?
Memory?
Workflow?
Prompt?
Model weights?

This defines the risk level.

2. What is the source of truth for success?

Example:

API result?
Human approval?
Ticket resolution?
Monitoring signal?
Business KPI?

Without a trusted outcome signal, learning becomes unreliable.

3. How much autonomy is allowed for unknown tasks?

Ask:

Read-only?
Writes allowed?
Human approval?
Financial limit?
Security-sensitive actions?

This determines fallback behaviour.

4. How fast does a new capability need to become production-ready?

This determines:

shadow sample size
evaluation design
traffic requirement
human review process

If you remember only the core ideas, remember these:

1. Adaptation ladder

Context → Memory → Skill → Prompt → Weights

2. Start from the cheapest and easiest-to-rollback method.

3. Separate:

Runtime
Learning
Evaluation Gate

4. Detect unknown tasks before routing them.

5. Unknown tasks should run with stricter safety controls.

6. Memory requires a write policy.

7. One successful trace does not automatically become a skill.

8. Every candidate goes through:

Offline Eval
→ Shadow
→ Promotion
→ Monitoring
→ Auto-Demotion

9. Evaluate the full trajectory, not only the final answer.

10. The agent can learn how to do something, but policy decides what it is allowed to do.

“I would design the self-adapting agent with a production runtime loop and a separate offline learning loop. The agent first adapts through context, memory and reusable skills, while every new capability must pass offline evaluation, shadow testing and a controlled promotion gate before production. The agent can learn how to perform tasks, but permissions and safety limits always stay in an external policy layer.”

User Request
    ↓
Detect Known vs Novel
    ↓
Approved Skill OR Safe Fallback
    ↓
Agent + Policy-Controlled Tools
    ↓
External Outcome
    ↓
Trace Store
    ↓
Offline Learning
    ↓
Memory / Skill / Prompt Candidate
    ↓
Evaluation
    ↓
Shadow
    ↓
Promote
    ↓
Monitor + Auto-Demote

The key principle is:

Self-adapting should mean controlled learning, not uncontrolled self-modification.