Brummel
6b1e148b36
The 18f bench result (rc/bump = 2.86x but gc/bump = 2.90x) showed the existing bench measures alloc-path cost, not the determinism question Decision 10 actually commits to. The user's framing made this explicit: RC has to be DEMONSTRABLY better than Boehm — the relevant axis is per-operation latency under heap pressure (Boehm's stop-the-world vs RC's amortized constant), not total wall-time. This agent's mandate: design workloads against a falsifiable hypothesis, run measurements that fit the hypothesis (latency distribution for determinism, not throughput), pair Implicit-mode fixtures (Boehm-fair) with explicit-mode fixtures (RC-fair) so each allocator is benched in its native regime, and report honestly what the data does NOT say. Distinguished from implementer: ships evidence, not features. Distinguished from architect: focuses on a single dimension (memory) and on empirical measurement, not drift review. Honesty rules built in: - Tie => bench did not distinguish, not "they are equivalent". - Implicit-mode RC numbers are not informative (RC leaks under Implicit) — call out whenever reported. - Bench-only instrumentation in runtime/rc.c must be marked removable and not leak into production. - No verdict statements: orchestrator decides defaults / drops.
AILang agents
These agent definitions are part of the project toolchain. They bundle the discipline and context that every task in this repo needs (which design documents to read first, which tests must run, which output format comes back). They are versioned, reviewable, and changeable like any other part of the repo.
What lives here
| Agent | Role |
|---|---|
ailang-implementer.md |
Carries out tightly scoped implementation tasks. |
ailang-architect.md |
Read-only reviewer; checks for drift against DESIGN.md after iterations. |
ailang-tester.md |
Writes examples and E2E tests. |
ailang-debugger.md |
Diagnoses compiler or codegen bugs. |
ailang-docwriter.md |
Writes and maintains rustdoc on the Rust crates. |
ailang-bencher.md |
Hypothesis-driven memory-management benchmarker; ships evidence, not features. |
Invocation scheme
Each .md file consists of YAML frontmatter (name, description, tools)
and a system-prompt body. There are two ways to invoke them:
-
As a subagent (preferred, when the tooling supports it). When the file sits under
~/.claude/agents/or.claude/agents/, Claude Code loads it as asubagent_typeand calls it as a native agent. The files here are deliberately NOT in.claude/because they belong to the project toolchain and should be visible. Anyone who wants to enable subagent loading can symlink:ln -s $(pwd)/agents .claude/agents. -
As a prompt prefix (always available). The body of the
.mdfile is prepended to the concrete task description and handed to ageneral-purposeagent. Functionally identical to the subagent call, except the caller has to send the body explicitly.
Extending or changing agents
- New agent: another
.mdfile with frontmatter (name,description,tools) and system-prompt body. - Existing agent: edit directly, like any other code file. Changes show up in git history.
- Convention: the frontmatter
descriptionfield is the one-sentence description an orchestrator reads to decide whether to call the agent. Keep it short and specific.