Seven projects to build on NOOA

01 Portfolio analyst over live objects Weekend

An agent class holding your actual position data and broker connection as typed fields — portfolio: DataFrame, broker: Broker, prices: PriceFeed — where analysis happens by the model writing pandas directly against those objects in the REPL.

class PortfolioAnalyst(Agent, llm=llm):
    """You analyse a live portfolio and propose rebalances."""

    portfolio: DataFrame
    broker: Broker
    api_key: Annotated[str, hidden] = ""   # never rendered into a prompt

    def max_position_pct(self) -> float:    # real body: deterministic
        return 0.15

    async def propose_rebalance(self, thesis: str) -> RebalancePlan:
        """Propose a rebalance consistent with the stated thesis."""
        ...                                  # ellipsis: LLM-driven

This is the cleanest demonstration of D (live objects) that exists. Consider what the same task costs elsewhere: to let a model compute a rolling correlation, you must anticipate the operation, define a compute_correlation tool with a JSON schema, serialize the frame in, deserialize a result out — and you must do that again for every unanticipated operation. Under C (code as action) the model writes three lines of pandas against the frame that already exists in memory. The set of analyses it can perform is no longer bounded by the set you predicted.

It also lands A and B hard, because a portfolio agent is exactly where the deterministic/generated boundary matters most: max_position_pct() has a real body and is therefore a guarantee, while propose_rebalance() has an ellipsis body and is therefore a guess. Encoding "which parts of my trading logic are allowed to be wrong" as a syntactic property of the class is a genuinely different way to reason about risk.

Add a MethodPrecondition asserting that no proposed order exceeds max_position_pct(), and a postcondition raising InvariantError on violation, and you get J: the model is told why its plan was rejected and retries against the constraint, instead of the run dying.

• Nothing about tracing, memory, skills, or multi-agent structure. It is a single-agent demo.
• The financial modelling itself is orthogonal — NOOA contributes no domain value here.

02 MCP aggregator agent Weekend

One agent class with several MCP servers attached as typed fields — mail, calendar, a notes or knowledge store — performing a real recurring job end to end rather than answering one question per server.

Partially, and it is worth being precise about which part. MCP support itself is not a NOOA differentiator; every serious framework has a client, and examples/quickstart/11_mcp.py shows a conventional one. The project earns its place on a narrower claim: under conventional tool-calling, combining three servers means three model turns — call mail, get JSON back, reason, call calendar, get JSON back, reason, call notes. Under C, the model writes one cell that fetches from all three, filters in Python, joins them on a key, and returns a result. The reasoning happens in code rather than across round-trips, which is fewer tokens, fewer opportunities to lose the thread, and one trace span instead of six.

That is a real and measurable benefit. It is also the only unique thing this project demonstrates.

• MCP integration — universal, not distinctive.
• Typed contracts, live objects, and tracing barely feature; MCP results arrive as data, not as live Python objects, so D is untouched.
• As a framework demonstration it proves little. As a way to learn the API on a task you actually want done, it is excellent.

03 Golden-trajectory regression CI for agents Substantial

A pytest plugin that captures real agent runs as ATIF trajectories, stores them as fixtures, and — when you change a prompt, swap a model, or switch strategies — replays and diffs behaviour, not just final output. Did it take more steps? Call a different method? Branch elsewhere? Burn 40% more tokens for the same answer?

This is the project I would bet on, because it is the one that is genuinely hard to build anywhere else, and the reason is structural rather than incidental.

Behavioural regression testing for agents needs three things at once. First, a complete and structured record of what happened — F gives you that by default, with parent-child spans preserved across orchestrators, generation methods, and helpers, and with src/nooa/atif/schema.py providing a versioned Pydantic schema whose normative rules (sequential step ids, joinability, context-management boundary semantics) are enforced by tests in the repo. Diffing two typed trajectories is tractable in a way that diffing two log files is not. Second, the agent must be re-instantiable in a test harness with dependencies substituted — which A gives you free, because the agent is a class and the test is just pytest. Third, deterministic replay of non-model state, which the event-sourced storage layer (src/nooa/storage/, snapshots) supports.

Most frameworks give you at most one of the three. Tracing is usually an add-on exporter producing spans shaped for a dashboard, not for assertion; agents are usually graph configurations rather than objects, so there is nothing clean to instantiate; and state is usually held in a runner you cannot snapshot.

The wider point is that prompt engineering is currently done by vibes, because nobody can see regressions. A tool that fails CI on "this prompt edit made the agent call the database twice as often" would be useful to everyone building on the framework.

packages/nooa-bench/src/nooa_bench/trace_analyzer.py already exists, as do runner.py and protocol.py, and examples/quickstart/14_atif_trajectory.py demonstrates export. So this is extending an existing foundation, not inventing from nothing. Read those three files before scoping — the honest version of this project might be "add trajectory diffing and a pytest fixture API to nooa-bench," which is smaller and more likely to be upstreamed.

04 Self-extending domain expert Substantial

An agent that, on completing a task it found difficult, writes the procedure down as a reusable capability and loads it next time. Facts go to long-term memory; procedures become code.

Because the framework ships explicit affordances for exactly this, which is unusual. src/nooa/tools/method_writing_lib.py defines a MethodWriting skill whose docstring instructs the model to define helper functions at the top of a REPL cell — and, more interestingly, to decorate standalone async functions with @strategy(PredictStrategy()) and an ellipsis body to create per-item LLM sub-calls fanned out through asyncio.gather. The agent is not merely writing helper code; it is authoring new generation methods at runtime and parallelising them. That is B and C composing in a way that has no clean analogue in a tool-calling framework, where a new capability means a new schema registered out-of-band.

library_writing_lib.py sits alongside it for persisting capabilities beyond a single cell, the skills/nooa-self-extending/ skill documents the pattern, and DynamicMethodAdditionError is a first-class error type in src/nooa/errors — a good sign that dynamic method addition is a supported path with defined failure modes rather than an accident.

Pair it with nooa-memory, whose module list (retrieval.py, reflection.py, forgetting.py, generative.py) is more opinionated than a bare vector store. Then instrument the thing that actually matters: skills written, skills reused, and tokens-per-task over weeks. That last chart is the entire project — without it you have an agent that accumulates clutter and no evidence it is learning.

• Memory subsystems are common across frameworks; the memory half earns no distinctiveness points.
• The self-extension half is where the novelty is concentrated.

05 Multi-agent teams by composition, not message bus Substantial

A small team — say author, reviewer, and integrator — where one agent holds another as a typed field and invokes it as a method: await self.reviewer.critique(patch). No router, no message schema, no graph definition.

It is the sharpest available test of the framework's central claim. If agents really are ordinary Python objects (A), then multi-agent orchestration should reduce to ordinary composition, and the entire category of orchestration machinery that other frameworks sell — routers, state graphs, message protocols, handoff schemas — should evaporate into method calls. Nothing else on this list puts the thesis so directly at risk.

Two secondary features carry real weight here. D means the author agent can hand the reviewer a live object rather than a serialized summary, so the reviewer inspects the same artifact rather than a lossy description of it. And F's parent-child spans mean a nested agent call appears as a nested span, so the trace of a three-agent run reads as a call tree — which is what it actually is.

Composition may relocate complexity rather than remove it. Message buses exist partly to solve problems that method calls do not address: retry and backoff at a boundary, cycle detection, concurrency between peers, and observability of a handoff. If you find yourself writing a coordinator class that dispatches, tracks status, and retries, you have rebuilt an orchestrator with worse ergonomics — and that negative result is worth writing up, because it bounds the claim. Build the equivalent in one graph-based framework and compare debuggability honestly rather than charitably.

06 Harness-ablation study on open models Research

Take an open model at two or three sizes, run one benchmark, and ablate the harness: context blocks on/off, summarization on/off, skills on/off, CodeAct versus Predict versus Prefill. The question worth answering is whether harness capability substitutes for parameter count — and where that substitution breaks down.

The repo is built for it. src/nooa/strategies/ contains codeact.py, predict.py, pure_python.py, prefill.py, and composite.py behind a common GenerationStrategy base with set_default_strategy(), so swapping the reasoning loop is a config change rather than a rewrite — that is the ablation axis handed to you. src/nooa/context_blocks/ and the skill registry give two more axes. packages/nooa-bench supplies BenchAgent and a runner, and util/eval_pipeline the scoring. The repo's own framing — a paper and a blog post on harness capabilities and model performance — means there is a baseline to compare against rather than a vacuum.

Local models are first-class: Ollama and vLLM are both supported through LiteLLM with no API key, so a full ablation grid costs GPU time rather than inference spend. That matters when the design calls for dozens of runs per cell to get error bars.

• CodeActLiteStrategy and ReflexionStrategy are experimental and deliberately gated behind a FutureWarning in src/nooa/__init__.py — they are re-exported lazily through nooa.experimental precisely so the warning cannot be bypassed. Ablations involving them sit on an unstable API and may not reproduce across versions.
• Ablation is generic methodology. NOOA makes it cheap, which is a real contribution to your time budget, but the study does not demonstrate anything architecturally unique about the framework.

07 Cross-episode memory for the existing benchmark agents Research

examples/arc_agi_3/ and examples/cybergym/ are already in the repo, each with configs, skills, and tests. Both currently start each episode cold. The experiment: give the agent memory that persists across episodes and measure whether it transfers.

Modestly, and mostly by combining nooa-memory with the event-sourced snapshot layer to carry state across runs. ARC is the more interesting target because its puzzles are deliberately designed to resist transfer — a positive result there would be a real finding, and a negative one is informative rather than embarrassing. trace_analyzer.py in nooa-bench gives you the measurement apparatus without building it.

• Cross-episode memory is a well-trodden research direction, not a NOOA capability.
• You are extending existing examples, so relatively little of the framework surface gets touched.