Research

Research directions and standards.

What we want to find out, how we intend to work, and where real results will appear. No publications, papers or experimental results have been released yet.

Research directions, not results

01 / Philosophy

Four standards we intend to hold ourselves to.

  1. State the question and the assumptions. A result is only interpretable next to what it assumed.
  2. Separate observation from interpretation. What happened and what we think it means are reported apart.
  3. Publish limitations with results. Untested conditions and known weaknesses are part of the finding.
  4. Never report a number without its method. A benchmark without a method is an assertion.

Execution safety is a lens, not a separate topic: every direction below asks what could go wrong, how it would be noticed, and how it would be contained.

02 / Directions

Six questions worth working on.

Each entry gives the open question, why it matters and the method we would start from. These are interests and intended approaches. None reports a finding.

Agent planning

How can a system produce plans that are adequate and revisable, and recognise when a plan has gone stale?

Why it matters
Plan quality bounds every later stage of execution.
Intended approach
Compare plan representations (flat lists, dependency graphs, hierarchies), study replanning triggers, and measure the divergence between plan and execution on defined tasks.
Relates to
Objective Interpretation · Planning Engine · Verification Engine

Tool-use reliability

Which descriptions, schemas and validations keep tool selection and parameterisation dependable as toolsets grow?

Why it matters
Wrong or malformed calls are a major source of failure.
Intended approach
Study descriptor formats, pre-execution validation, error classification and selection quality under large registries.
Relates to
Tool Execution Layer

Multi-agent coordination

When does dividing work among agents beat a single agent, and which protocols limit error propagation?

Why it matters
Coordination adds communication cost and new failure modes.
Intended approach
Define single-agent baselines, compare coordination structures and instrument every handoff.
Relates to
Planning Engine · Context and Memory · Verification Engine

Evaluation and verification

How should task success, step correctness, cost and recovery be measured so that results mean something?

Why it matters
Without sound evaluation, claims of progress cannot be trusted.
Intended approach
Design evaluation-harness concepts and acceptance-criteria formats, study verifier reliability, and document the limits of every metric.
Relates to
Verification Engine · Safety and Control Layer

Execution safety

How do permissions, approvals and limits behave when an agent composes tools in ways no one listed in advance?

Why it matters
Safety properties that only hold for the anticipated cases are not properties of the system.
Intended approach
Study action classification, approval design, containment of side effects and how failures are noticed and bounded.
Relates to
Safety and Control Layer · Tool Execution Layer

Human-agent collaboration

How should approvals, explanations and handoffs be designed so people can review well and remain in control?

Why it matters
Oversight fails when it is too hard to do properly.
Intended approach
Study approval design, how evidence is presented, interruptibility and criteria for escalation.
Relates to
Objective Interpretation · Safety and Control Layer

03 / Demonstrations

How demonstrations will be labelled.

Four lanes, one rule: nothing is shown in a lane it has not earned. Today the first three are empty.

  • VerifiedDemonstrated and checked against a documented method others can inspect.None published yet
  • PrototypeA working implementation that may be incomplete, shown with recorded runs and known limitations.None published yet
  • ResearchAn open question or an experiment in progress. No claim of a working capability.None published yet
  • PlannedIntended work. Nothing exists yet.4 proposed demonstrations

Proposed demonstrations

  • Research Agent. Answer a technical question from an approved set of documents and produce a structured report.
  • Developer Agent. Analyze a small coding task in a sample repository, propose a change and report the test outcome.
  • Data Analysis Agent. Examine a public or clearly labelled synthetic dataset and answer a question with evidence.
  • Multi-Agent Collaboration. Coordinate specialist agents to complete a larger objective, then compare against a single agent doing the same job.

Presentation policy

  • Recorded runs come first, with the full trace, tool calls, checks, date and version.
  • Live runs only once isolation, rate limits and cost controls exist, and kept separate from this website.
  • Any scripted walkthrough is labelled as such and never placed in the Prototype or Verified lanes.
  • Failed runs are shown, not hidden.

04 / Technical notes

Technical notes and experiments.

No technical notes have been published yet.This index will list notes and experiment reports when they exist, each with its method and its limitations.

How an entry will look · template only

Date · Revision · Authors (real people only)

Title of a future note

The question the note asks.

Why it matters
Method, observations, limitations and untested conditions, and links to artefacts that others can inspect.
Relates to
The reference-model components the note concerns.
See the reference architecture these questions come from

Contact

Discuss a research question.

If you work on agent evaluation, planning, tool use or human oversight, we would like to compare notes.