Hire an AI WebAssembly engineer

Everything it can hand back

Your task sets the actual outputs. The specialist picks the methods that cover them.

• A fit verdict on whether Wasm helps, with the reason
• A benchmark plan to measure the current version first
• A boundary design that lists what crosses to Wasm, in what batches, and who owns the memory
• A toolchain choice by language, with the size and start-up cost
• A plan to shrink and stream the file
• A sandbox and fallback plan, plus the open questions

How it does the job well

• The boundary is the bottleneck — design around it first. JS↔Wasm calls are cheap individually and ruinous in aggregate. Move the loop into Wasm; cross the boundary with big batched buffers, not per-element calls. Most Wasm performance failures live here.
• Benchmark before you port, and against the real baseline. "Wasm is faster" is a hypothesis until measured. Compute-heavy kernels win; glue code and DOM manipulation usually lose to the marshalling cost. Prove it, don't assume it.
• Strings and objects don't cross for free. JS strings and structured objects must be encoded/decoded and copied into linear memory. Minimize crossings, pass numeric handles or shared buffers, and never marshal a rich object graph per call.
• Linear memory is yours to manage — and to leak. Wasm memory grows but effectively never shrinks in a running instance. Free deliberately (or use arena/bump allocation), watch the growth cliff, and design for bounded memory in long-lived modules.
• Read the existing code, its conventions and its tests before changing anything. Match the project's patterns.
• Make the smallest change that fully solves the request. Keep unrelated refactors out.
• Reproduce a bug before fixing it, and add a test that fails without the fix.

Mistakes it avoids

• Claiming code works without running it or its tests.
• Inventing APIs, package versions or settings instead of checking the installed ones.
• Changing behaviour outside the request, such as reformatting whole files or renaming public interfaces.

What a good result looks like

An example, not your task: A browser feature, such as image work, a parser or a codec, is too slow in JavaScript.

• Fit verdict. Go, no-go or maybe for Wasm, with the reasons and what would change the answer.
• Baseline to measure. What to time, on what data, and the current value or NOT MEASURED.
• Boundary design. What crosses between JavaScript and Wasm, in what batches, and who owns the memory.
• Toolchain. The language and tool choice, with its file size and start-up cost.
• Size and loading. The steps to shrink the file and load it while it downloads.
• Sandbox and fallback. The least access a server module needs, and fallbacks for missing browser features.

How the work is checked

• The changed files build, and the relevant tests and linters pass. The commands and results are shown.
• Each change is explained in one line with its reason, and risky areas are named.
• Any check that could not run is reported as NOT_RUN with what it needs.
• States which checks passed, failed or could not run, and names missing inputs.

These checks have not been run against a model yet. Your AI uses them to check its own work.

A second opinion

Before it hands back, your AI reviews the draft the way Donald Knuth and Linus Torvalds would. This is a way of reviewing the work. It does not mean they wrote or endorse it.

Capabilities

• Check the fit. It asks whether the work is heavy computing with few crossings, or glue code that only feels slow.
• Plan the baseline. It plans a timing of your current code on real data, so a port has a number to beat.
• Design the boundary. It decides what crosses between JavaScript and Wasm, in big batches, and who owns the memory.
• Pick the toolchain. It picks by language and target, and counts the size and start-up cost of each.
• Plan size and loading. It plans a size budget, smaller builds and loading while the file downloads.
• Plan the sandbox and fallback. On servers it plans the least access a module needs. In browsers it plans a fallback for missing features.

How the role works

1. Checks your task, context and available tools.
2. Picks the methods needed and prepares a work plan.
3. Carries out supported tasks, with each method's limits and review gates.
4. Checks the real deliverables and corrects supported faults.
5. Hands back files, evidence and unresolved gaps.

Your specialist's working setup

Download the base specialist without a task form or account. README.md and SETUP.md explain how to use the folder. SOUL.md defines its scope. INTAKE.md asks missing questions inside your AI. PLAYBOOK.md, SKILLS.md, BEST_PRACTICES.md, CHECKS.md and HANDOFF.md guide the work and its checked deliverables.

Complete associated skills, supporting files and licences are included. Choose only the methods needed for the actual task. Keep context, working files and accepted feedback in your AI project.

Use this specialist through MCP or the API

Call prepare_specialist with role_id engineering-webassembly-engineer only. No task is required to load it. Your AI asks what job you need done, what you want back and which relevant context it can use.

For task-led hiring, call find_specialist, explain the suggested specialists and let the user accept or change the team.

Complete ZIP: Download base specialist. API: GET /api/v1/specialists/engineering-webassembly-engineer/pack. The host AI supplies its own model, tools and execution; a pack does not connect accounts or run a task.

Inputs and helpful context

The specialist starts from the task brief. Only active methods require their inputs.

For the primary method, when used

• The task or code you want to speed up or isolate, in plain words
• The language it is written in, such as Rust, C++ or Go
• Where it will run, such as the browser, a server or the edge
• Your current speed on real data, such as 40 milliseconds per image (optional)
• Browsers or runtimes you must support, and your file size limit (optional)
• The code itself, if you can share it (optional)

Helpful context (optional)

• A sample of real data that the slow code handles, so the baseline is honest.
• The slowest device you must support, for timing and file size limits.

Tools and access

• Claude, ChatGPT or Gemini: A chat can write the plan and outlines. Run your own timing and builds, because the agent cannot.

Functions and deliverables

• WebAssembly engineer agent: Find out if WebAssembly will speed up your web app or plugin system, then plan the port, the file size and the safe limits.
  • A fit verdict on whether Wasm helps, with the reason
  • A benchmark plan to measure the current version first
  • A boundary design that lists what crosses to Wasm, in what batches, and who owns the memory
  • A toolchain choice by language, with the size and start-up cost
  • A plan to shrink and stream the file
  • A sandbox and fallback plan, plus the open questions
  Source: Michael Sitarzewski and Agency Agents contributors.
• Single-task agent heartbeat builder: Plan a safe AI agent run loop: one task per run, no overlapping runs, time and cost limits, and a run record. Draft code only.
  • A numbered run loop, with what stops the run at each step
  • The four checks that run before any work, and what is saved when one fails
  • The pick order for work, with how ties are broken
  • The fields of the run record
  • A schedule worksheet for each agent
  • A list of gaps in the starter runner, and test cases
• AI app and chatbot builder: Describe the chatbot, document question answerer or tool-using agent you want. Get starter code for your AI app in Python with LangChain.
  • Starter Python code for your chatbot, question answerer or agent
  • Install commands for the right packages
  • A document search setup, if your app needs one
  • An example of an agent that uses tools
  • A note on when a different library is a better fit
  Source: Orchestra Research.
• Agent delegation and dependency planner: Plan which AI agent owns each task, who may hand work to whom and what must finish first. Get a delegation plan and failure test cases.
  • A delegation plan: for each handoff, who gets it, why, what they may do and what it waits for
  • An authority and depth check, listing any handoff that would be refused
  • What is logged for each handoff and each refusal
  • A failure checklist
  • Test cases using made-up agents and tasks
  • A list of missing inputs and checks that did not run
• AI project context organiser: Share your project and next task. Get a short rules file, a focused file list and a clear handoff for later sessions.
  • A ready rules file for your project
  • A list of which files to load for each task
  • Rules for when to reset or trim the session
  • A checklist for spotting drifting answers
  Source: Addy Osmani.
• Donald Knuth: Review code or a careful explanation using Donald Knuth’s recorded approach. Work a small example, make the reasoning readable and separate tests from proof.
  • Your problem worked on the way Donald Knuth would: their questions, their method, their push-back
  • The answer or the work, in Donald Knuth's voice, using their ideas by name
  • Anything that goes beyond their public record, marked
  • One suggested next step
• Linus Torvalds: Review a code change using Linus Torvalds’s recorded approach. Ask what works, what breaks for existing users and who owns the fix.
  • Your problem worked on the way Linus Torvalds would: their questions, their method, their push-back
  • The answer or the work, in Linus Torvalds's voice, using their ideas by name
  • Anything that goes beyond their public record, marked
  • One suggested next step

Tasks you can use it for

• A browser feature, such as image work, a parser or a codec, is too slow in JavaScript.
• You want to run other people's plugins on your server without giving them your files or network.
• Someone says "let's rewrite it in Rust and compile it to Wasm" and you want proof first.
• Your Wasm file is several megabytes and slows the first page load.

Limits to check before starting

• Your slow part is page layout, DOM work or network calls. Use the Frontend developer.
• You want to clean up Rust code, not compile it to Wasm. Use the Rust refactoring planner.
• You need to measure the speed of a whole site or API. Use the Performance benchmark planner.
• You need a security review of your sandbox setup. Use the Security Architect agent.

Best way to use this role

Give it one clear outcome, the actual files and a definition of done. Keep the work in one AI project so it can reuse checked context and earlier files.

• Download the pack from this page and add it to your AI as a skill. If you cannot, paste SKILL.md into a new chat, then references/source-agent.md.
• Describe the task, the language, where it runs and any timing you have. Paste the code if you can.
• Say "Write the WebAssembly plan. Tell me first if Wasm is the wrong choice. Ask me once if anything is missing."
• Read the fit verdict first. If it says no, stop there and fix the real bottleneck.
• Run the benchmark it plans on your own data and paste the numbers back. Until you do, speed claims stay marked as not measured.
• Port the smallest hot loop first, and compare against the baseline before you port more.

Read it as data

Read the complete role setup as JSON. Connect your AI to the AI Blocks MCP library and read aiblocks://roles/engineering-webassembly-engineer for its role instructions and pinned sources.

This is a prepared AI role. No task has run. Your AI carries out authorized work using its available tools and reports the actual deliverables and checks.