Code415 Radar

Key ideas

Post training compute

Extra training after pretraining, such as reinforcement learning on coding and agent tasks, which can lift skills without changing the base model.

Claim level hallucination rate

The share of individual factual claims in an answer that turn out false, rather than counting whole answers as right or wrong.

Output token verbosity

How many tokens a model writes to finish a task, which multiplies cost and latency even when the per token price is average.

Steps

1. Read the Kimi K3.1 Pro post on the Kimi blog first, noting which numbers are vendor reported.
2. Open the Artificial Analysis model page and compare intelligence score, price, output tokens used and speed against the medians.
3. Check the Kimi platform pricing page for cache write and cache hit prices, since cached input at $0.20 per 1M tokens changes agent costs a lot.
4. Self check: if two models cost the same per token but one writes 70% more output tokens, which one costs more for the same task, and by roughly how much?

Steps

1. Create an API key on the Kimi API Platform and follow its quickstart guide for the request format.
2. Pick 5 small coding tasks from your own repo, such as writing a test or fixing a known bug.
3. Send each task to kimi-k3.1-pro and record answer quality, output token count and wall clock time.
4. Send the same tasks to kimi-k3.1-pro-highspeed and to the model you use today.
5. Compute cost per task from token counts and the listed prices, then compare quality per dollar.

Small angles to try

• Add a system instruction asking for concise answers and measure how much output token count drops.
• Feed a large file set to test whether long context answers stay accurate near the end of the input.
• After November 4, check the released weights and license to judge self hosting feasibility.

Key ideas

Thinking tokens

Tokens a reasoning model writes before its final answer, which cost time and money but are usually hidden from the user.

Active parameters in a MoE

A mixture of experts model routes each token through a few expert blocks, so only about 4B of its 26B weights do work per token.

Looping

A failure where the model repeats the same reasoning over and over until it hits the token limit, which wastes compute and often scores zero.

Steps

1. Read the BottleCap AI ThinkingCap post first, focusing on the per benchmark table.
2. Note how they measured: same harness, same hardware, many seeds per benchmark, and a 65,536 token cap.
3. Open the Hugging Face model card to see the sampling settings and the serving commands.
4. Self check: why does a lower loop rate also help accuracy when looped answers are truncated and scored as zero?

Steps

1. Install Ollama or a recent llama.cpp build on your own machine.
2. Run ollama run hf.co/bottlecapai/ThinkingCap-gemma-4-26B-A4B-it-GGUF:Q4_K_M to pull and chat with the model.
3. Get the base gemma-4-26B-A4B-it at a similar quantization the same way, so the comparison is fair.
4. Ask both models the same 10 reasoning prompts from your own work with thinking enabled, at temperature 1.0, top_p 0.95 and top_k 64.
5. Record thinking length, final answer correctness and time to answer for each pair, and compare the totals.

Small angles to try

• Use llama-server with the MXFP4_MOE file and the flags from the GGUF card, then call it from your own script.
• Feed one long document question to check whether the AA-LCR drop shows up on your data.
• Run each prompt three times to see how much thinking length varies between runs.

Key ideas

Deep search agent

An agent that runs many search, browse and read steps in a loop and combines evidence before answering.

Answer uniqueness

Each task is checked by humans so that only one answer is correct, which makes automatic grading fair.

LLM judge

A model that compares an agent's final answer with the reference answer and marks it right or wrong.

Steps

1. Read the abstract and analysis summary on the Hugging Face Papers page first.
2. Open the OpenDS GitHub README to see how a run is configured and what a trajectory file contains.
3. Look at a few rows of the OpenDS-World dataset to get a feel for task difficulty.
4. Self check: why can an agent beat the human average here and still be unreliable for production research?

Steps

1. Clone the repo, create a virtual env and run python -m pip install -e . inside it.
2. Download the data with hf download Yu2020/OpenDS-World --repo-type dataset --local-dir data/opends-world.
3. Run your own research agent on 10 of the 200 tasks and write a predictions.csv with the id, question, gold_answer, model_answer and status columns.
4. Score it with python ops/judge_predictions.py and the predictions, output dir, judge model id and base URL flags shown in the README.
5. Read summary.json and the per task judgments to find which failures came from search, reading or final reasoning.

Small angles to try

• Compare a single model with tools against your multi step agent on the same 10 tasks.
• Cap the number of tool calls and see how accuracy and cost change.
• Swap the judge model to check how stable the scores are.

Key ideas

Sequential diagnosis

Reaching a diagnosis step by step, choosing which question or test to ask next instead of seeing all facts at once.

Gatekeeper agent

A model that holds the full case and reveals only the result of each question or test the diagnostic agent asks for.

Cost aware orchestration

Coordinating several agents while tracking the price of each action, so accuracy is reported together with spend.

Steps

1. Read the Microsoft AI post first for the design and headline numbers.
2. Read the TechCrunch article for the base model versus orchestrator comparison.
3. Open the SDBench project site and skim how the agent, gatekeeper and judge interact.
4. Self check: if a stronger base model alone closes most of the gap, when is an orchestration layer still worth its cost?

Steps

1. Clone the sdbench repo from GitHub on your own machine.
2. Export your OpenRouter key and run uv run python -m sdbench.cli.harness to run the baseline agent on the synthetic cases.
3. Read the logs to follow how the agent asks questions, how the gatekeeper answers and how the judge scores.
4. Change the configured model to a cheaper one and rerun, then compare accuracy and estimated test cost.
5. Write down which steps cost the most and whether the agent ordered tests it did not need.

Small angles to try

• Reuse the gatekeeper and judge pattern for a non medical task such as debugging from logs revealed one at a time.
• Compare one model answering in a single turn against the stepwise harness on the same cases.
• Treat results as a learning exercise only, since five synthetic cases cannot measure diagnostic quality.

Key ideas

Shadow AI

Staff using AI tools the company has not approved, often by pasting work data into a public chatbot.

Data loss prevention

Tools that detect sensitive data such as addresses or ID numbers and block it from leaving approved systems.

Provider retention

Even after a user deletes a chat, the AI provider may keep the data for a fixed period for security or legal reasons.

Steps

1. Read the ITmedia NEWS article first, using a translator if needed.
2. List which data fields leaked for each group and why family member names raise the risk.
3. Look up the data retention and training settings of the AI tools your own team uses.
4. Self check: which control would have stopped this upload, a written ban, a training opt out, or a block on large personal data exports leaving the HR system?

Steps

1. Generate a fake CSV of 1,000 people with made up employee numbers, addresses, phones and emails.
2. Write a small Python script that scans text with regular expressions for email, phone and address patterns and counts matches.
3. Paste sample prompts that include rows from the fake CSV and some that do not, and check that the script flags only the risky ones.
4. Add a rule that blocks any prompt with more than a set number of personal records and prints the reason.
5. Note false positives and misses, and decide what a real gateway in front of an internal AI tool would need.

Small angles to try

• Replace the regular expressions with an open source PII detector and compare results.
• Mask matched fields with placeholders instead of blocking, then check the masked prompt is still useful.
• Review your own team's AI tool settings for training opt out and retention, and write them down.

Key ideas

Mixture of experts

A model where a router sends each token to a few expert sub networks, so only 30B of 293B weights do work per token.

Active parameters

The weights actually used for one token, which drive compute cost, while total parameters drive memory.

Thinking levels

A switch that controls how much hidden reasoning the model writes before its answer, trading latency for quality.

Steps

1. Read the Global Times report to get the headline facts on the 293B model.
2. Open the Spark-X2.6-4B card on Hugging Face and read the sections on thinking modes and serving.
3. Note how the card turns thinking off with "chat_template_kwargs": {"enable_thinking": false} in SGLang or vLLM style servers.
4. Self check: why can a 293B MoE with 30B active parameters run faster per token than a dense 70B model, yet still need far more memory?

Steps

1. Install Ollama v0.34.1 or later from ollama.com.
2. Run ollama run SparkLLM/Spark-X2.6-4B and ask it a short coding question.
3. Ask a multi step reasoning question and time the answer with thinking on, which is the default.
4. For the Python route, pip install transformers==4.57.1, load XHToken/Spark-X2.6-4B with trust_remote_code=True, and pass enable_thinking=True or False to apply_chat_template.
5. Compare answer quality and token count with thinking on and off on the same five prompts from your own work.

Small angles to try

• Feed it a long file from your own repo and check whether it answers questions about the far end correctly.
• Pit it against another small local model on the same prompts.
• Measure tokens per second on CPU only versus GPU.

Key ideas

Copy on write

A storage trick where a fork shares all existing data and only new writes take extra space.

Per tool call commit

Every action an agent takes becomes a recorded snapshot, so any step can be inspected or rolled back.

Last writer wins rules

A root /.lww file lists patterns such as lockfiles whose clashes resolve to the newer edit instead of a Conflict.

Steps

1. Read the layerfs.ai home page for the workspace, commit and fork model.
2. Read the GitHub README for the store design, platform support and the durability caveat.
3. Skim the HN thread for the btrfs comparison and the maturity debate.
4. Self check: why would two agents editing the same lockfile need a different rule than two agents editing the same source file?

Steps

1. Open the docs page at layerfs.ai/docs and pick the DSH or SDK path for your machine.
2. Follow the setup prompt in a container or throwaway directory on your own machine, not on a repo you cannot rebuild.
3. Mount a workspace over a small repo of your own and run a few file edits, then list the commits to confirm one per tool call.
4. Fork from an earlier commit, edit the same file on both branches and observe the Conflict.
5. Add a lockfile pattern to /.lww, repeat the clash and confirm the newer edit wins.

Small angles to try

• Time a fresh mount against a clone plus dependency install of the same repo.
• Compare disk use of ten forks against ten git worktrees.
• Run two agents on separate branches of one task and diff their histories.

Key ideas

World model

A model that predicts what the environment will look like after an action.

Decoder free prediction

Predicting the next state as an embedding rather than pixels, which makes checks fast and cheap.

Transition verification

Flagging a step when the observed next screen is far from what the action should have produced.

Steps

1. Read the abstract on the Hugging Face Papers page.
2. Read the GitHub README results table, which separates the integrity score from the harm head.
3. Look at a few lines of benchmark/rswt_bench_test.jsonl to see how legitimate and hijacked transitions pair up.
4. Self check: why does a detector that only looks at the final login screen score at chance on this benchmark?

Steps

1. Clone the lgwm repo, create a venv with python3 -m venv .venv, then pip install -c requirements-tested.txt -e '.[text]'.
2. Download weights with hf download jiamingzz/lgwm --local-dir weights.
3. Install the extras with pip install -c requirements-tested.txt -e '.[training,evaluation]' and fetch data with hf download jiamingzz/lgwm-data --repo-type dataset --local-dir data.
4. Extract features with python tools/extract_features.py --manifest benchmark/rswt_bench_test.jsonl --data-root data --index-dir data/index --output outputs/features/test.
5. Score with python tools/evaluate_benchmark.py --features outputs/features/test --output outputs/eval/test.json and compare against the README AUCs.

Small angles to try

• Time per decision on CPU versus GPU.
• Compare the integrity score and the harm head on the harm task.
• Inspect the lowest scoring legitimate transitions to see what fools it.

Key ideas

Terminal multiplexer

A program that runs many shells in one window and keeps them alive after you detach.

Agent attention state

A per tab signal for whether an agent is busy, blocked on you or has output you have not read.

Git worktree

A second checkout of the same repo in another folder, so parallel agents do not trample each other.

Steps

1. Read the corgi.computer page for the status icons and keybindings.
2. Read the GitHub README install section for supported platforms.
3. Skim the Show HN thread for user feedback.
4. Self check: with four agents running, what does F1 save you compared with cycling through tmux panes?

Steps

1. Read https://corgi.computer/install.sh before running it, then install with curl -fsSL https://corgi.computer/install.sh | bash.
2. Run corgi, press Ctrl-T and start two agents on a small repo of your own in separate worktrees.
3. Give each a task, switch away, and use F1 to jump to whichever needs input.
4. Open the token view and the files touched view to review what each agent did.
5. Detach, run corgi again and confirm the agents kept running.

Small angles to try

• Run corgi --skill and ask an agent to open a new tab itself.
• Compare the workflow with plain tmux on the same two tasks.
• Mix two different agent CLIs and compare their token use.

Key ideas

Egress control

Limiting which outbound network connections a sandbox may make, including DNS.

Side channel

Leaking information through shared hardware effects such as cache timing instead of a network or file.

Defense in depth

Stacking independent controls so one failed layer does not open the whole system.

Steps

1. Read the OpenAI post, focusing on the three red team findings.
2. Read the TechCrunch piece for outside context and the critical view.
3. List which of the indirect paths, such as logging or metrics endpoints, exist in your own agent sandbox.
4. Self check: why does blocking direct internet access not stop an agent that can reach a service which fetches URLs for it?

Steps

1. Start a throwaway container with networking turned off, see the Docker docs for the option, and confirm DNS lookups and HTTP requests fail.
2. Start a second container on an internal only Docker network that also holds a small local web service of your own.
3. From the sandbox, confirm it can reach the local service but not the internet.
4. Read your own service's code and list any feature, such as a URL fetch or webhook, that could relay a request outward.
5. Write down a one page egress policy for your agent sandbox covering DNS, proxies, logging and metrics.

Small angles to try

• Audit an existing devcontainer or CI runner config for open egress.
• Log every DNS query a sandboxed agent makes during one task.
• Compare gVisor and plain runc isolation docs for your setup.

Key ideas

Agentic memory

A system where the agent rewrites past conversation into summaries, facts or graphs and later reads those instead of the original text.

Dense retrieval plus reranking

An embedding model picks candidate chunks by vector similarity, then a cross encoder rescores each chunk against the question for a sharper top list.

Evidence coverage

The share of facts needed to answer a question that actually reach the reader model's context.

Steps

1. Read the abstract and the author comments on the Hugging Face Papers page for the paper.
2. Skim the RAW-RAG README to see the pipeline: windows of raw history, embedding retrieval, cross encoder rerank, reader LLM.
3. Look at the benchmark list, LoCoMo, LongMemEval, MEME and MemoryAgentBench, and note what kind of question each tests.
4. Compare with a memory system your team uses and list which facts its summarization step could lose.
5. Self check: why can keeping raw evidence beat a cleaner, compressed memory store when the reader model has a long context?

Steps

1. Export one of your own long chat logs with an assistant, or write a synthetic 200 turn conversation that plants facts early and updates some later.
2. Write ten questions whose answers sit in specific turns, including one where a fact was changed later.
3. Split the history into overlapping windows of a few turns, embed them with an open embedding model, and retrieve the top 20 windows per question.
4. Rerank those windows with a cross encoder reranker, keep the top 5, and pass them with the question to any chat model you already run.
5. Score answers by hand, then repeat with a summary of the chat instead of raw windows and compare.
6. To try the authors' code, clone the repo and follow the README, starting with python -m pip install -r methods/EverCore/requirements-eval.txt and python -m evaluation.cli --dataset locomo --system rag from methods/EverCore.

Small angles to try

• Drop the reranker and see how much accuracy falls.
• Vary window size from one turn to ten turns.
• Ask questions about facts that were later corrected and check which version the system returns.

Key ideas

Speculative decoding

A small draft model guesses several tokens ahead and the large model verifies them in one pass, which speeds up generation without changing outputs.

OpenAI compatible endpoint

A local server that accepts the same request shape as OpenAI's API, so existing client code can point at it by changing the base URL.

Decision model

A small model that answers a narrow routing question about an input, such as which category or handler it belongs to.

Steps

1. Read the v0.40.9 and v0.40.10 notes on the ollama/ollama releases page.
2. Note which features are platform limited, for example Phonon on Apple Silicon only.
3. Read how the d3 example uses a question flag to turn a model into a yes or no router.
4. Self check: why does a draft model make Nemotron Bolt E4B faster without changing its answers?

Steps

1. Update Ollama to the latest release from the releases page and confirm the version.
2. On an Apple Silicon Mac run ollama run phonon "Hello from Ollama." and listen to the output.
3. Run ollama run nemotron-3.5-bolt:e4b and ask it a few questions, noting response speed.
4. Run ollama run d3 "A customer says their card was charged twice." --ask "Is this a billing issue?" and try a few of your own support style messages.
5. Point an existing OpenAI client at your local Ollama server and call the speech endpoint, following the request shape in Ollama's OpenAI compatibility docs.

Small angles to try

• Compare d3 at 2B and 9B on twenty of your own routing examples.
• Pipe Nemotron Bolt E4B replies into Phonon for a fully local voice loop.
• Feed Nemotron Bolt E4B a screenshot and check its vision answers.

Key ideas

Full duplex speech

The model hears and speaks at the same time, so it can be interrupted and can say short acknowledgements while the user talks.

Speech only training

Learning language directly from audio, instead of starting from a text LLM and attaching speech input and output.

Backchanneling

Small listener sounds such as mm hmm that signal attention without taking the turn.

Steps

1. Read Block's Dessa page and listen to its samples.
2. Contrast it with a cascaded voice agent that chains speech recognition, a text LLM and text to speech.
3. Read the HN thread for listener reactions on realism versus reasoning.
4. Self check: what does a model gain and lose by never seeing text during training?

Steps

1. Listen to the Dessa samples on Block's page and note pauses, overlaps and backchannels.
2. Record a two minute conversation with a cascaded voice assistant you already have access to.
3. Mark every moment where you interrupt it and note how long it takes to stop or react.
4. Write a short score sheet for turn taking, latency and naturalness, and rate both recordings.
5. Decide which behaviors in your notes would need full duplex modeling rather than a faster pipeline.

Small angles to try

• Test with background noise to see how the assistant handles overlapping sound.
• Ask a reasoning question to separate voice quality from answer quality.
• Have a colleague rate the recordings blind.

Key ideas

Formal notation

A language with precise syntax and meaning, so each statement has one interpretation.

Specification

A description of what software must do, which many different programs can satisfy.

Ambiguity cost

The extra work needed to pin down what an informal instruction really meant.

Steps

1. Read EWD667 on the University of Texas Dijkstra archive; it is short.
2. List his three main claims in your own words.
3. Read the top HN comments by nickm12 and js8 and place each on Dijkstra's side or against it.
4. Self check: if an agent writes Rust from a prose prompt, where does the formal step happen and who checks it?

Steps

1. Write a one paragraph prose description of a small function, such as parsing dates from log lines.
2. Ask a coding assistant to implement it three times in fresh sessions and save each result.
3. Write five edge case tests that your prose did not mention and run them against all three versions.
4. Rewrite the prose as a precise spec with examples and edge cases, regenerate three versions, and rerun the tests.
5. Compare how much the versions disagreed before and after the precise spec.

Small angles to try

• Use a type signature plus property based tests as the spec instead of prose.
• Try the same task in a language with a stricter type system.
• Commit the precise spec next to the code and review it like a design doc.

Key ideas

Agent daemon

A background process that starts, tracks and streams many coding agent sessions so a UI can manage them.

Sync proxy

A layer that pushes database changes to clients in real time, here Electric syncing Postgres.

Software factory

A setup where tickets flow to coding agents and back as reviewed pull requests with little manual glue.

Steps

1. Read the HumanLayer blog post on open sourcing the platform.
2. List the components and draw how a ticket from Linear could reach a Claude Code session and return as a PR.
3. Note which parts need third party keys today.
4. Self check: which component would you replace first to run this without any external SaaS?

Steps

1. Clone the humanlayer/humanlayer repository from GitHub to your own machine.
2. Read the docker-compose.yml and the DEVELOPMENT guide to list services and required environment variables.
3. Find where the daemon launches Claude Code or Codex sessions and trace one session lifecycle.
4. If you hold test accounts for the required services, bring up the dev stack in a local container following the repo docs.
5. Write down which required keys block a fully offline setup.

Small angles to try

• Ask a coding agent in the repo to walk you through getting the devstack running, as the blog suggests.
• Compare its session tracking with how your team tracks agent runs today.
• Check the Apache 2.0 terms against your company's open source policy.

Key ideas

Path traversal in archive extraction

An archive entry named with ../ segments can land outside the target folder unless the extractor checks each resolved path, the classic Zip Slip bug.

Unauthenticated management API

A control endpoint that registers or downloads models without any login, so anyone who can reach the port can feed it archives or URLs.

End of life software

Code that no longer gets security fixes, so the only real remedy for a new CVE is removal or isolation.

Steps

1. Read AWS bulletin 2026-148-AWS end to end, noting the two CVEs and the workaround section.
2. Open the MMS configuration doc on GitHub and find inference_address and management_address with their defaults.
3. Compare the default split ports with the SageMaker style single port setup the bulletin describes.
4. Read the CVE-2026-115812 entry on TheHackerWire for the CVSS vector and CWE-23.
5. Self check: why does binding management to loopback not help in the SageMaker style setup?

Steps

1. Search your own repos, requirements files and Dockerfiles for the PyPI package multi-model-server and for base images that bundle MMS.
2. On each of your own hosts running it, read the config.properties file passed with --mms-config or the MMS_CONFIG_FILE environment variable, and record inference_address and management_address.
3. Flag any deployment where the management address is not 127.0.0.1, or where management and inference share one port on all addresses.
4. For flagged hosts, check your firewall or security group rules so only trusted callers can reach the serving port.
5. Write a short migration ticket per deployment, since AWS says no fix is coming.

Small angles to try

• Write a small script that scans your own config.properties files and fails CI on a non loopback management_address.
• In your own extraction code, add a check that rejects archive entries whose resolved path leaves the target folder, and test it with a harmless archive you build yourself.

Key ideas

Shell startup files

Files such as .bashrc or .zshrc that a shell runs before each command, so running them outside the sandbox let unsandboxed code slip in.

Workspace trust

A one time confirmation that a folder is safe before a tool runs code or reads config from it.

Worktree isolation

Running an agent in a separate git worktree with a guard that refuses commands that could escape it.

Steps

1. Open the v2.1.309 release notes on GitHub and read the first ten items, which cover the sandbox and permission fixes.
2. Read the Changed items near the end of 2.1.309 for claude ultrareview and the rm and rmdir behavior.
3. Read the v2.1.310 notes for Monitor on Bedrock, Vertex and Foundry and the gateway retry fix.
4. Self check: which of these changes would break an existing unattended CI script, and how would you fix it?

Steps

1. Update Claude Code and confirm the installed version is 2.1.310 or later.
2. In a throwaway repo, enable the Bash sandbox, add a harmless echo line to your shell startup file, and confirm in the session that sandboxed commands now run it inside the sandbox.
3. Start a session with --mcp-config pointing at a copy of your MCP config and ask Claude to edit that file; confirm the change is blocked.
4. Find any script that calls claude ultrareview and add --trust-workspace after the PR number or base branch.
5. If you use Bedrock, Vertex or Foundry, try the Monitor tool on a long running build and confirm it now works there.

Small angles to try

• Run the same cd then git compound command in old and new versions and compare whether a permission prompt appears.
• Behind your own gateway, check whether requests that used to fail now succeed with the retry.

Key ideas

Image embeddings

A model turns each photo into a vector so that photos of the same product land close together.

Similarity search against references

Each new listing photo is compared with a set of official product images, and close matches get flagged for review.

Human in the loop review

AI ranks or flags items, and staff make the final decision, trading speed for fewer wrong removals.

Steps

1. Read the Impress Watch report on LINE Yahoo's measures, in Japanese or via a translator, and list each AI use.
2. Read the ITmedia Mobile resale article to see the price gap that drives scalping.
3. Look up how image embedding models such as CLIP measure similarity between photos.
4. Self check: why might detection rise from 46% to 90% when matching against official images rather than keywords?

Steps

1. Collect 5 official product images that you are allowed to use, such as your own photos of boxed items, as the reference set.
2. Take 20 photos of your own items, some showing the same products in different light and angles, some unrelated.
3. Embed every image with a public pretrained image model and compute cosine similarity between each photo and the reference set.
4. Pick a threshold, label your photos by hand, and measure how many true matches the threshold catches.
5. Send borderline scores to a manual review list and note how many need a human look.

Small angles to try

• Add text matching on a title you write for each photo and see if combining text and image scores helps.
• Crop or blur the photos to see how fragile the matching is.

Key ideas

Sim to real transfer

A control policy is trained in a physics simulator and then run on the real robot, with the simulation tuned until behavior carries over.

PPO

Proximal Policy Optimization, a common reinforcement learning method that improves a policy in small, stable steps.

Policy sharing

A trained controller is published as a file others can download and run, which makes new tricks the software update path.

Steps

1. Read the TechCrunch story for the launch and preorder context.
2. Read Pollen's Microduck page for price, the open stack and the train, deploy, refine loop.
3. Skim the microduck GitHub README and the simulation doc to see how the simulator talks to the robot daemons.
4. Self check: why does a policy fail to balance if the simulator runs slower than real time?

Steps

1. Clone pollen-robotics/microduck and pollen-robotics/microduck_rl, and set up microduck_rl following its README, setting DUCK_SIM_RL if you put it somewhere other than the default.
2. From the microduck repo, run scripts/duck-sim to open the MuJoCo window and watch the duck stand up.
3. Run scripts/duck-sim status to confirm it is standing, then scripts/duck-sim drive to walk forward for 8 seconds.
4. Run scripts/duck-sim realtime and confirm the real time factor stays at or above 1.0.
5. Shut down with scripts/duck-sim down.

Small angles to try

• Start in a different pose by setting DUCK_SIM_KEYFRAME to STAND or FOLD.
• Run headless with DUCK_SIM_VIEWER=0 and compare the real time factor.
• Try the apartment scene with DUCK_SIM_SCENE=apartment.

Key ideas

Model Context Protocol

An open protocol, originally from Anthropic, that lets AI agents call a service's tools through a standard server interface.

Scoped agent identity

Giving each agent its own profile so its actions are logged and limited separately from the human account owner.

Spending cap with approval

A rule that lets an agent buy alone under a limit and asks the human to approve anything above it or every purchase.

Steps

1. Read the TechCrunch story and list what agents can and cannot do on Walmart.
2. Compare Walmart's terms with Amazon's blocking approach and write down the tradeoff for a store.
3. Check Apple's top free feed to see how big consumer agents like Muse already are.
4. Self check: which of Walmart's rules can a server enforce in code, and which depend on trusting the agent?

Steps

1. Write a toy MCP server with two tools, search_catalog over a small JSON file of fake products and place_order that only records orders locally.
2. Give each calling agent a profile record with a spending cap and an approval mode, mirroring Walmart's Agent Profiles.
3. Make place_order refuse anything over the cap unless an approval flag is set, and never accept or store payment data.
4. Connect the server to your MCP client and ask the agent to buy items below and above the cap.
5. Review the local order log to confirm agent purchases are recorded separately from manual ones.

Small angles to try

• Add a per day order limit and see how the agent explains a refusal to the user.
• Return a structured error instead of plain text when the cap is hit and compare how well the agent recovers.