The research log is Thesis’s answer to a common problem: important decisions get made during a research session, but by the next session they’re buried in chat history or forgotten entirely. Thesis solves this by giving you an append-only log that the agent writes to automatically as work progresses. Every decision, hypothesis, failure, pivot, and compute approval lands here as a permanent, typed entry, not as a chat message that will eventually scroll out of context.

​
What the log captures

The log is not a transcript of your conversation. It records the things that matter, the choices and outcomes that should be traceable months from now.
  • Decisions. Explicit choices made during the research process, which method to use, which hypothesis to prioritize, which approach to abandon.
  • Hypotheses. Formal research hypotheses entered into the record, distinct from the hypothesis field on an empirical node.
  • Dead ends. Approaches that were tried and ruled out. Dead ends are valuable: they prevent future agents and collaborators from repeating the same wrong turns.
  • Assumptions. Explicit assumptions underpinning an experiment or analysis, the conditions that must hold for a result to be valid.
  • Results. Outcomes of experiments or analyses, including quantitative metrics and qualitative assessments.
  • Failures. Recorded experiment failures, separate from dead ends, a failure means the experiment ran but the outcome was not what was expected.
  • Pivots. Documented changes in research direction, when you decide to shift focus, the log captures why.
  • Compute events. Proposal events (when the agent stages an experiment), approval events (when you approve compute spending), and agent telemetry milestones (progress updates from running sub-agents).
The log also records asset registrations, when a file, report, or dataset is attached to a node, so you can trace exactly when a piece of evidence entered the project.

​
Why append-only

The log is append-only by design. You cannot edit or delete a log entry after it’s written. This is intentional:
  • Reliability: An append-only log is a true audit trail. If an entry says an experiment was approved on a particular date, that record cannot be altered retroactively.
  • Agent trust: The agent is instructed to treat the log as the authoritative project record. If entries could be edited silently, the agent could not trust what it reads.
  • Reproducibility: A complete, unmodified history of decisions makes it possible to reconstruct exactly how a result was reached.

​
How the agent writes to the log

The agent writes log entries automatically during the ReAct loop, you don’t need to prompt it to do this. When the agent makes a notable decision, records a result, encounters a failure, or approves compute, it calls the log service and the entry appears in the timeline immediately. From your perspective in the chat UI, you’ll see log entries surface as part of the event stream alongside tool results and text responses. You can also view the full log timeline from the project sidebar at any time.
You can write your own log entries too. Use the record decision action from the agent or MCP tools to add a manual entry, useful when you make a judgment call outside the agent loop.

​
What a log entry looks like

Each entry has a type, a timestamp, a human-readable summary, and structured metadata. Here’s an example of what a decision entry looks like: 
{
  "entry_type": "decision",
  "summary": "Chose GRPO over PPO as the baseline RL method for this experiment series.",
  "rationale": "PPO showed instability in preliminary runs on our dataset size. GRPO converged faster in related work (see node n_3a1f).",
  "created_at": "2026-04-15T14:32:07Z",
  "node_id": "n_3a1f",
  "project_id": "proj_ab12"
}
And an approval event entry, written automatically when you approve a compute spend: 
{
  "entry_type": "approval_event",
  "summary": "User approved compute for experiment node n_7c9e.",
  "provider": "MODAL",
  "sku": "gpu-a10g",
  "budget_cents": 200,
  "timeout_hours": 4,
  "approval_token": "tok_...",
  "created_at": "2026-04-15T15:01:43Z",
  "node_id": "n_7c9e"
}

​
All entry types

Explicit choices made by you or the agent. Includes a rationale field and an optional reference to the node where the decision was made.
Formal hypothesis statements entered into the log as research artifacts, separate from the hypothesis field on empirical nodes.
Approaches ruled out after consideration or failed trials. Prevents repeated mistakes across sessions and sub-agent runs.
Stated preconditions for a piece of analysis. Useful for reviewing whether assumptions held after results arrive.
Quantitative or qualitative outcomes of experiments and analyses, linked to the relevant node.
Experiments that ran but did not produce the expected outcome. Distinct from dead ends, the attempt was made.
Documented direction changes. Includes a summary of what changed and why.
Written when the agent stages an experiment and presents a proposal card for your review.
Written when you approve a compute proposal. Includes the approval token, provider, SKU, budget, and timeout.
Written when a file or report is attached to a node, capturing when evidence entered the project record.
Progress updates from running sub-agents, start, heartbeat, milestone reports, and completion events.