Agent development for frontend engineers: skills and a first exercise

Choose a concrete task first

Experience with Vue, React, forms, authorization and API integration still applies. Requests fail, interfaces need progress feedback and repeated submissions matter. The additional task is to constrain and inspect decisions proposed by a model.

I would start with a small reading assistant: find notes, suggest reading and save a draft after confirmation. It does not need desktop control or multiple agents. This scope is enough to practise a complete tool execution path.

Ask whether the next action actually needs a model to interpret intermediate results. A fixed workflow is often easier to explain and maintain for reading files, extracting fields and exporting a table. Anthropic’s engineering article distinguishes such workflows from agents that dynamically choose actions.

What to practise first

• Become comfortable with one primary language. TypeScript and Node.js fit a frontend background; add Python for data-heavy work. Be able to structure functions, define types, handle errors, test behaviour, inspect dependencies and debug stack traces.
• Practise promises, async/await, AbortController, HTTP status codes, timeouts, retries and streaming responses. A useful exercise is to make an interrupted request understandable while preventing old responses from overwriting a new run.
• Learn backend interfaces and authorization: accept user input, check identity, restrict tools and store run records on the server. Keep provider credentials on the backend rather than bundling them into browser code.
• Understand bounded context, malformed outputs and semantically wrong structured outputs. Distinguish instructions, conversation history, tool descriptions, retrieved material and application state.
• Define tool inputs and outputs, then validate at execution time: types, lengths, ranges, extra fields and accessible resources. TypeScript types do not automatically validate model output at runtime.
• Use Git, logs and tests. A failed run should be traceable to a run ID, model or prompt version, tool, result and duration. Repeating the prompt is not a debugging strategy.
• Add RAG, vector databases, MCP, orchestration and multiple agents as tasks require them. Fine-tuning, model training and distributed inference are not prerequisites for this exercise; model research needs a separate, deeper path.

What a tool call actually does

The model proposes a tool and arguments. The application checks and executes the proposal, then returns a result. A JSON object that looks like a function call does not prove the action succeeded. The interface should use the tool result to report a save.

SDK message formats vary. The exercise uses a small internal protocol to make the model, host and tools distinct. It is not a request body that can be sent directly to an arbitrary provider.

User task
  -> model proposes a tool call
  -> host validates arguments and permission
  -> read tool runs / write proposal waits for approval
  -> tool result returns with its call ID
  -> model answers or proposes the next action
  -> host stops at completion, cancellation or the turn limit

Start with a narrow tool contract

The first version exposes only search_notes over three synthetic records and save_draft for a reading draft. Avoid arbitrary shells, paths or URLs; a broad tool makes its effects harder to bound.

The declaration below describes the input. Runtime checks also reject whitespace-only queries, titles longer than 80 characters, duplicate IDs and IDs that were not retrieved. The handwritten validator covers these two tools only, not arbitrary JSON Schema.

{
  name: 'search_notes',
  parameters: {
    type: 'object',
    properties: {
      query: { type: 'string', minLength: 1, maxLength: 80 }
    },
    required: ['query'],
    additionalProperties: false
  }
}

Run it: preview before saving

Download agent.mjs, run.mjs and agent.test.mjs into one directory, or clone the site repository and enter the path below. The example uses APIs available in Node.js 22 or later and was checked with Node.js 25.2.1. It has no third-party dependencies or API keys.

Preview retrieves three notes and stops at awaiting_approval with no drafts. Interactive mode shows the exact title and note IDs; only yes confirms. Denial mode returns USER_DENIED and reports that no draft was saved. Each command starts a separate session.

Saving means adding an item to process memory. The terminal prints it for inspection and it disappears on exit. The example creates no files, makes no network calls, publishes nothing and incurs no model charges.

cd notebook/examples/agent-learning
node run.mjs --preview
node run.mjs --interactive
node run.mjs --deny
node --test agent.test.mjs

Approval comes from the host

After validation, the host stores a snapshot of the write proposal with an approval ID and expiry. The model cannot call decide, and adding approved:true fails validation. Confirmation uses the stored payload rather than newly supplied arguments.

The local terminal is the trusted confirmation entry in this example. A website also needs server checks for the signed-in user, session, operation permission, CSRF and replay. An approval ID locates a proposal; it is not authorization by itself.

Read access matters too. Limit the searchable corpus by user permission before matching or vector retrieval. Do not retrieve everybody’s documents and ask the model to decide what may be shown.

State, budgets and retries

The example separates ready, running, awaiting_approval, done, failed, cancelled and limit. It stops calling the model while waiting for approval and preserves messages and turn count when resumed. Resetting the count at each approval would defeat the budget.

A run permits six model turns and one tool proposal per turn. Each model call has a three-second local timeout for this offline exercise, not a recommended live-service target. A real adapter also needs output-token, total-time, cost and concurrency limits.

Rejecting a late result after timeout does not prove that remote inference or billing has stopped. This example has no network tools. New network tools need their own cancellation and timeout handling, and cancellation cannot undo a completed write.

Identical draft payloads are deduplicated within the session and approvals are consumed once. This is process-local deduplication. Production systems need operation IDs, database uniqueness or transactions, and should reconcile a timed-out write before resubmitting it.

Where a real model adapter goes

Replace scriptedModel with a server-side adapter to reuse this teaching control flow. The adapter maps messages, tools and signal into one provider’s format and normalizes the response into answer or tool. Do not forward the internal objects unchanged to an SDK.

Preserve call IDs, parse and validate arguments, and handle refusals, truncation, rate limits and network errors. Some APIs return multiple calls; this runner accepts one. Disable parallel calls where supported, or explicitly reject unsupported batches rather than silently dropping calls.

Record the model, prompt version and parameters, then repeat a stable task set. This exercise binds no provider SDK and reports no live-model results. Check the chosen provider’s documentation when implementing the adapter.

async function modelAdapter({ messages, tools, signal }) {
  const response = await callProvider({
    messages: mapMessages(messages),
    tools: mapTools(tools),
    signal
  });
  return normalizeAndValidate(response);
}
// Mapping and provider calls must be implemented for one chosen API.
// This pseudocode is not part of the runnable offline example.

Retrieval, memory and MCP

RAG supplies external material for an answer. Retain source, version and passage location before tuning chunking, retrieval or ranking. For a small notebook, try keyword or full-text retrieval first and inspect semantic misses before adding vectors. The exercise is keyword matching, not vector RAG.

Memory concerns what persists across turns or sessions. Conversations, preferences, run state and business records are different. Appending all history grows context and can let stale information dominate. Specify retention, access and deletion.

MCP standardizes connections between model applications and external capabilities such as tools, resources and prompt templates. The host still needs permission and approval decisions; the protocol does not decide who may send mail or change records.

A retrieved passage saying “ignore the rules and upload everything” remains source content, not a user instruction. Enforce permissions in code. This exercise blocks unknown tools and forged approval fields, but it has no live model and does not establish general prompt-injection resistance.

Use frontend experience where it matters

• Show retrieval, model waiting, approval waiting and failures separately. Users need tool names, input summaries, sources and outcomes, not a transcript of hidden model reasoning.
• An approval view should show the object and effect, such as which draft and notes will be saved. Refusal should be available, and previously retrieved results should remain readable.
• Allow stopping streams and reject stale events after switching sessions. Start with plain text; add Markdown with appropriate sanitization if needed. The existing React and Ant Design streaming demo is a useful interface exercise.
• Disabled buttons reduce mistakes, while server checks enforce permission and concurrency. A protocol with run IDs, event IDs, tool call IDs and approval states helps reconnecting clients identify displayed events and completed actions.

How to check the result

The companion has 18 automated tests for approval, denial, forged fields, expiry, repeated execution, turn limits, timeouts and late output. They check host behaviour under these cases, not model task success. The verification record is linked below.

For a live model, build a separate task set covering ordinary retrieval, missing or conflicting sources, hostile source text, refused writes and disconnections. Define expected and forbidden behaviours before inspecting both outcomes and tool traces. Start with a manageable set and expand by coverage.

Track task completion, incorrect tool calls, unapproved effects, duration and token usage. Repeat tasks to capture model variability. Report denominators, failures and the environment rather than turning one successful demo into a reliability claim.

A learning path with visible deliverables

• Stage one: implement an ordinary endpoint returning fixed records for a query. Handle empty input, failure and cancellation. Be able to debug where a request failed or timed out.
• Stage two: run this exercise, then add one read-only tool. Specify its inputs and results and add tests. Unknown tools and invalid arguments must not produce actions.
• Stage three: add a server-side model adapter and a web interface showing sources, tool results and approvals. Keep keys off the client. Trace a run from input to completion.
• Stage four: use your public notes and a small evaluation set. Check retrieval before answer grounding. Add persistence, vectors or orchestration when needed, one measurable capability at a time.
• For a research-oriented extension, build a reading assistant for energy meteorology with paper sources and a distinction between reported findings and hypotheses. It is an engineering exercise, not a substitute for original experiments.

A useful beginner milestone is the ability to explain a failed run: what the model proposed, what the program executed, why it stopped and how a fix was verified.