Thinking Machines Lab published a report to build AI that extends human will and judgment. Most AI in use today is trained in a handful of places, then frozen. The report argues that this design excludes the people a model serves. Instead, the Thinking Machines lab researchers want AI that is distributed, customizable, and shaped by its users.
Thinking Machines Lab’s Proposal
The lab names four technical directions. First, it trains strong models with multimodal interaction and customizability. Second, it builds tools that let people fine-tune and train model weights themselves. Third, it develops interfaces that widen the human-to-machine communication channel. Fourth, it publishes research so more engineers understand how models are made. Together, these directions move both knowledge and alignment closer to users.
Why Distributed Knowledge Needs Distributed AI
Underneath these directions sits a claim about knowledge itself. Much know-how is tacit, local, and updated constantly through feedback. A chef refining a recipe cannot write that skill into a database. The report cites Michael Polanyi and Friedrich Hayek to support this. The main planning fails because such knowledge is private and fleeting, not scarce. Therefore, the lab argues, AI must be distributed to use distributed knowledge. It wants AI that helps organizations cultivate that knowledge, not extract and replace it.
Chess and math are the stated exceptions. Both have static, expressible goals and no hidden knowledge. So self-play and autonomous solving work well there. Outside such closed domains, the report says intelligence alone is not enough.
Technical Bottlenecks It Names
Given that framing, the report reframes two familiar limits as engineering targets. The first is the communication channel: a small text box and a long wait. This is the problem the lab’s interaction models address directly. Those models take in audio, video, and text continuously, using roughly 200ms micro-turns. The second limit is evaluation itself. Benchmarks like METR’s measure how long a model works alone. The report argues this misses what people and machines accomplish together.
Ownership And Decentralized Alignment
Beyond interfaces, the report turns to where values live. A single alignment authority, it warns, becomes a single point of capture. Prompts change surface behavior, while deeper model habits stay fixed. So the lab argues values should be encoded in model weights, not prompts. This is where its Tinker API becomes concrete for engineers.
Tinker fine-tunes open-weights models such as Llama and Qwen using LoRA. It exposes low-level primitives and lets you export portable adapter weights. A minimal supervised loop follows the official pattern:
import tinker
from tinker import types
# Reads TINKER_API_KEY from your environment
service_client = tinker.ServiceClient()
# LoRA fine-tuning client for an open-weights base model
training_client = service_client.create_lora_training_client(
base_model="Qwen/Qwen3-8B", rank=32,
)
for batch in dataset: # batch: list[types.Datum]
fwd_bwd = training_client.forward_backward(batch, "cross_entropy")
optim = training_client.optim_step(types.AdamParams(learning_rate=1e-4))
fwd_bwd.result() # accumulate gradients
optim.result() # update the weights
# Save the trained LoRA weights, then get a client to use them
sampling_client = training_client.save_weights_and_get_sampling_client(
name="my-adapter",
)Centralized Frozen AI vs The Distributed Approach
Taken together, the report’s stance contrasts with today’s default approach:
| Dimension | Centralized frozen AI | Thinking Machines’ distributed approach |
|---|---|---|
| Where it is trained | A few labs, then frozen | Adapted where the work happens |
| Who shapes values | The model’s owner | The organization and its users |
| Adaptation | Prompts and scaffolding | Fine-tuned weights via tools like Tinker |
| Interface | Text box, turn-based waiting | Live, multimodal interaction models |
| Alignment locus | One central spec | Many diverse, owned models |
Use Cases With Examples
In practice, these ideas map onto concrete engineering work. For example, a hospital could fine-tune a model on its own protocols. It would keep both data and adapter weights in house. Similarly, a law firm could adapt a model to its house style. It would retrain that model whenever internal guidance changes. Meanwhile, a support team could use live interaction to correct a model mid-task. In each case, the organization keeps ownership instead of renting a fixed model.
Key Takeaways
- The essay treats human participation as a technical challenge, not a limit on capability.
- Tacit, local knowledge is the stated reason AI itself must be distributed.
- Interaction models widen the human-AI channel using continuous, micro-turn multimodal input.
- Tinker lets teams encode their values into portable LoRA weights they own.
- The lab frames alignment as many diverse, owned models, not one central spec.
Sources
- Thinking Machines Lab, “The Future Worth Building Is Human” (Jul 10, 2026): https://thinkingmachines.ai/blog/the-future-worth-building-is-human/
- Thinking Machines Lab, “Interaction Models: A Scalable Approach to Human-AI Collaboration” (May 2026): https://thinkingmachines.ai/blog/interaction-models/
- Tinker documentation (quickstart and TrainingClient API): https://tinker-docs.thinkingmachines.ai/
- Kwa, West et al., “Task-Completion Time Horizons of Frontier AI Models,” METR (2025): https://metr.org/time-horizons/
