An AI co-scientist built for researchers trained to question everything.

Why

Scientists don’t trust AI. And they shouldn’t have to.

Most AI tools are designed to make answers feel effortless. They return a polished response with little indication of how the answer was formed, how reliable the evidence is, or where the researcher should start questioning it.

That model works for everyday questions. Scientific research demands something different.

Researchers need to be able to:

• See what the AI is doing.Understand how it approached the question and what evidence shaped the response.
• Question the answer.Identify uncertainty, weak claims, and gaps instead of accepting a confident response at face value.
• Work with rigor.Move from an initial hypothesis to evidence, verification, and deeper investigation without leaving the research workflow.

The challenge wasn’t simply making Aristotle more accurate.

It was designing an interface that made its intelligence inspectable.

The design thesis

Transparency is the product.

Instead of hiding Aristotle’s complexity behind automation, we designed the interface around the ways researchers evaluate information themselves.

That meant giving researchers visibility into:

• what Aristotle is doing
• why it is doing it
• how it reached an answer
• and where they can challenge it

This became the principle behind the Beta experience.

Where we started

Just ask. Aristotle chooses the best model for you.

The first version of Aristotle was intentionally simple.

Every prompt was automatically routed across three models: Explore, Generate, and Verify.

There was no sidebar. No model picker. No visible reasoning layer.

The logic was straightforward:

And for simple questions, it worked.

But as Aristotle became capable of doing deeper research, the same simplicity became a limitation.

When simplicity broke

A black box, for people trained to question everything.

Automatic model selection meant researchers couldn’t see why Aristotle chose a particular approach.

When an answer felt wrong, there was little to interrogate.

At the same time, the product was gaining capabilities that couldn’t comfortably live inside the original canvas:

• Double Check needed room to surface verification.
• Source previews needed space for evidence.
• Reasoning traces needed somewhere researchers could inspect them.
• Different research modes needed to become visible and understandable.

Putting everything directly into the conversation made the canvas increasingly noisy.

Two things had to change.

Researchers needed more control over how Aristotle approached a question.

And Aristotle needed a dedicated space for making its work visible.

Control

How much control should a researcher actually have?

As Aristotle became more capable, we had to rethink an assumption from the original experience: that hiding complexity would make AI easier to use.

Instead, I explored how much of Aristotle’s underlying intelligence researchers should be able to see and control.

The exploration focused on two connected questions:

Control · Model control

From automatic routing to researcher intent

Rather than adding more models to a hidden router, we made the choice of approach the product’s core interaction model.

A fourth mode, Instant, stays available for quick conversational answers when depth isn’t necessary.

Exposing the choice raised a new problem. Our first explorations surfaced the models directly:

Model names alone don’t explain when or why someone should use them.

So we reframed the choice. Instead of asking:

The model became an implementation detail. The research intent became the interface. Each mode then got its own design pass.

System Thinking

What happens between the question and the answer?

Choosing the right research mode solved one part of the problem. But giving researchers more control only matters if they can also understand what Aristotle is doing with that control.

System Thinking

Instead of presenting a finished response as a black box, System Thinking gives researchers visibility into the research process behind it.

1. Question
2. Scope the problem
3. Identify relevant concepts
4. Explore evidence
5. Connect findings
6. Form conclusion

Designing for inspectability

The challenge was showing enough of Aristotle’s process to build understanding without exposing every intermediate step.

We designed System Thinking as a progressive view of the research process. Researchers could see how Aristotle moved from the initial question through different stages of investigation, while keeping the final answer as the primary focus.

Each stage could be expanded to reveal the relevant reasoning, evidence, and connections behind it.

How researchers use it

System Thinking gives researchers a way to follow the path, not just read the destination.

They can quickly scan the overall approach, then drill into a specific step when something feels unclear, surprising, or worth challenging.

For example, a researcher might notice that Aristotle identified an unexpected concept during Explore Evidence, open that step, and inspect the sources and connections that led to it.

This makes the AI’s process something researchers can inspect, question, and build on, rather than something they simply have to trust.

Researchers don’t just see what Aristotle concluded. They can see how it got there.

Peer Review

What if Aristotle could challenge its own work?

Researchers don’t stop at getting an answer. They question assumptions, look for weaknesses, and ask what might have been missed.

Peer Review extends that behavior to Aristotle itself. Instead of asking researchers to manually identify every weakness in a response, Aristotle can take a second pass on its own work, looking for gaps, unsupported claims, alternative interpretations, and areas that deserve further investigation.

A second set of eyes

The goal wasn’t to create another confidence score. It was to introduce productive disagreement into the research process.

Peer Review asks Aristotle to step outside its original line of reasoning and evaluate the work from a different perspective:

• What assumptions is the answer making?
• What evidence is missing?
• Are there alternative explanations?
• Which claims deserve closer scrutiny?
• What would a researcher challenge?

This gives researchers something more useful than “the answer is probably correct.” It gives them places to question.

Designing the interaction

We explored how Peer Review could fit into the research workflow without interrupting it.

Rather than making critique part of every response, we treated it as an intentional second pass. Researchers could ask Aristotle to review the work after an answer had been generated, then inspect the issues it surfaced.

The interaction was designed around a simple loop:

1. Answer
2. Review
3. Challenge
4. Refine

A researcher could scan the review first, then open individual findings to understand why Aristotle flagged them and return to the original answer with those challenges in context.

What we explored

The exploration centered on one question:

How much should Aristotle challenge the researcher?

Too little, and Peer Review becomes another reassuring summary. Too much, and every answer becomes buried under criticism.

We explored different ways of surfacing critique, from high-level review summaries to individual challenges tied back to specific parts of the response.

The direction that emerged was to make the challenges themselves the interface. Instead of giving researchers another opaque score, Peer Review surfaces specific things worth questioning.

Peer Review vs. Verify

Verify and Peer Review play different roles in the loop.

Together, they move Aristotle beyond simply producing an answer:

Verify asks: “Does this hold up?”
Peer Review asks: “What should we challenge?”

And that completes the larger control loop:

1. Choose the approach
2. Understand the process
3. Challenge the result

The goal isn’t to make researchers trust Aristotle more. It’s to give them better reasons to question it.

New problem

Aristotle worked well as an AI research assistant, but not yet as a coherent research workspace.

Researchers weren’t thinking in isolated chats. They were moving across papers, datasets, notes, reviews, and ongoing lines of inquiry.

Features like Highlights were valuable, but difficult to find and organize, while strong workflows like Peer Review still felt disconnected from the rest of the product.

Where does my work belong, and what is connected to what?

What we learned

The strongest signals weren’t about answer quality. They were about workflow.

The Shape Sessions showed that researchers saw real value in Aristotle, but the strongest signals weren’t just about answer quality. They were about how the product fit into their workflow.

Three themes kept coming up:

The broader signal was clear:

Aristotle needed to organize research around the work researchers were doing, not around the underlying AI system.

What changed

From a collection of AI interactions to a structured research workspace

Instead of allowing chats, highlights, documents, and tools to exist independently, we made Projects the foundation of the product. Every session, document, highlight, and workflow now belongs to a project, giving researchers a persistent place for the context and artifacts around a body of work.

Everything now belongs to a project. Nothing lives independently.

The project became the system of record for research.

Before

After

We moved from optional project organization to a persistent project model where every session, document, highlight, and tool inherits the same research context.

We also moved away from asking researchers to understand which model to use. The research showed that model names and modes were often unclear, while task-specific workflows like Peer Review were much easier to understand.

The new direction was simple:

Organize Aristotle around what researchers are trying to do, not around how the AI works.

New features / workflows

That shift led to a set of more explicit research workflows.

These weren’t four unrelated feature additions. They became explicit workflows inside the same project context.

Peer Review

A dedicated surface for reviewing papers and proposals, surfacing weak claims, inconsistencies, and areas that need attention.

Lab Sync

Researchers bring their own data into Aristotle and reason over it within the same project.

Highlights

Saved passages became an organized research artifact, with color, filters, search, and notes.

In-line Definitions

A reading workflow for understanding scientific terminology without leaving the document.

Together, these workflows made Aristotle feel less like a chatbot with modes and more like a workspace built around the different stages of research.

Highlights: from saving information to organizing evidence

Of the four, Highlights has the clearest line from research to design. Researchers liked Highlights but struggled to find and navigate them, especially when sorted only by recency.

Impact

A clearer product model

The post-Beta research gave us a much clearer product model. Instead of continuing to add capabilities onto the original chat structure, we reorganized the experience around persistent projects and explicit research tasks.

The result was a product with a clearer mental model:

One project, one research context, multiple connected workflows.

It also gave us a stronger foundation for future features. New tools, documents, notes, and research artifacts could now inherit the same project context instead of becoming another disconnected surface.

Designing Aristotle changed how I think about AI products.

At first, I spent a lot of time thinking about the quality of the model: how much reasoning to expose, how to distinguish different modes, and how to help users choose the right one.

But the research showed me that users rarely want to think about the system at that level.

Researchers cared about whether Aristotle could support the task in front of them: review a paper, understand a term, work with a dataset, save evidence, or challenge a claim. When we exposed too much of the underlying AI architecture, we often made the product harder to understand. Model selection itself became a source of uncertainty, and visible reasoning could compete with the answer rather than build confidence.

I also learned that trust is not the same as transparency.

Researchers did want to understand what Aristotle was doing, but more information was not always more useful. What mattered was showing the right evidence, uncertainty, sources, and reasoning at the moment it helped them make a judgment.

The biggest shift in my thinking was from designing an AI interface to designing a research system around AI.

The model was only one part of the experience. The harder design problem was creating the structure around it: where work lives, how context persists, how evidence is organized, and how researchers move from asking a question to building knowledge over time.