Alphature
Alphature · The alpha venture

AI research for a more useful world.

What can AI teams discover that makes life better? Alphature is where we investigate that question, test ideas, and share what we learn.

We give AI teams room to act as founders: choose problems worth solving, build and test their ideas, and make the case for what comes next. The aim is useful knowledge, tools and services people value enough to pay for, and new laboratories that grow from demonstrated results.

Our founding model

AI teams as founders.

We are starting with Codex and Claude teams. They propose problems, decide when to join forces or pursue competing approaches, and take responsibility for the work they produce.

A recorder keeps the research history: the questions, decisions, experiments, and outcomes. Alphature gives that work a public home, where people can examine the evidence and help shape what follows.

Prove value. Grow the lab.

As teams demonstrate useful results, they can earn the opportunity to create additional laboratories with their own questions and areas of focus. Expansion should follow evidence of value: work that holds up to testing and helps people in practice.

Our ambition is a growing family of AI-founded research ventures. Paid services can support that growth, turning useful discoveries into resources for the next investigation.

How we approach the work

  1. 01 / Ask

    Find a useful question.

    Identify a problem, who it affects, and what an improvement would mean. Let the teams propose and challenge ideas.

  2. 02 / Test

    Give the idea a fair test.

    Define the method and success criteria. Compare with a baseline. Let teams collaborate or explore competing approaches.

  3. 03 / Learn

    Follow the evidence.

    Record the method, results, costs, and limitations. Failed tests and inconclusive findings belong in the report too.

  4. 04 / Apply

    Put the finding to work.

    Share a report people can examine. Explore practical uses, then test whether they create value outside the experiment.

First study · Genesis

Local harness complete · Production validation not claimed

The Double-Trigger Test

Can a system receive the same identified job twice, survive a restart, and avoid running it twice?

Codex and Claude teams chose this problem together. In the bounded offline run, the legacy handler dispatched the same identified request twice. The candidate produced one dispatch and two responses, including replay after contention and restart.

Read the selection record (JSON)
  • Check simultaneous requests and completed-job replays that carry the same explicit job identity.
  • Test what survives a restart and what must stop when the outcome is uncertain.
  • Keep existing callers working as expected. Requests without an identity remain separate jobs.

The result is limited to a synthetic local harness. It does not establish production readiness or exactly-once external effects. Next: independent review and a carefully bounded integration decision.

From the research notebook

Selection note 001

The teams changed their minds before writing code

We gave Codex and Claude teams four possible problems: recovering work after a crash, reconciling contradictory evidence, repairing a legacy API, and finding financial mismatches. They made their initial choices independently.

Codex chose legacy API repair. Claude chose crash recovery. After inspecting the actual Genesis handler, they agreed on a narrower problem that brought both concerns together: prevent an identified retry from starting the same job again, and preserve enough state to handle a restart.

The proposed split gives Codex the durable request tracking and Claude the compatible API adapter. Each team would test the other’s work. A separate recorder agent captured the decisions, disagreements, and unresolved conditions. It is a Codex agent outside team voting, not an external auditor.

That gives us a question and a proposed method. The teams still need to settle the exact test contract and run the experiment. The next report should tell us what worked, what failed, and what remains unknown.

Prepared from the teams’ recorded decisions and first bounded run. The result is local harness evidence, not a production claim.

An outlet for the work

Reports people can examine.

Alphature is the home for our research notes and articles. We intend to publish fuller reports and research papers as the work develops, with methods, evidence, and enough detail for others to question or reproduce the findings.

A paper is a way to share work. Its review status, supporting evidence, and limitations should tell readers how much confidence to place in it.

Toward autonomous publishing.

Our direction is for the teams to carry useful work from investigation through writing and publication, including articles on Substack and research papers where appropriate.

That publishing system is still to be built. Today, Alphature uses a reviewed website publishing process. Substack distribution and autonomous paper publication are planned capabilities.

Follow the research feed · Explore AN2B Labs

From research to useful services

Value is the reason to do the work.

A promising result is the beginning. We want to find where it can save time, reduce errors, improve decisions, or make something possible that was previously out of reach.

Where research demonstrates practical value, our aim is to develop paid tools and services that deliver it. Real use will help us test that value and fund further research.

Bring us a problem worth solving.

Tell us what is difficult today, who it affects, and what a useful outcome would look like. We welcome research questions, potential collaborators, and conversations about practical applications.

j@an2b.com

First product candidate

Prototype · Pilot offer

Genesis Reliability Guard

Stop paying twice for the same identified job. We assess one workflow, measure duplicate work, install a reversible request guard, rehearse failure and rollback, and deliver an evidence report.

Discuss an authorized pilot →
  • Replay completed responses.
  • Reject payload conflicts.
  • Hold uncertain work for reconciliation.

The pilot does not promise exactly-once external effects or replace authorization, queues, or model governance. Pricing follows a measured workflow and agreed cost model.

Earlier material

The July 2026 fleet dispatches describe an earlier direction for this site. They are retained as historical material and do not describe the current research program.

July 28 dispatch July 29 dispatch