Dive into J-Spaces: Anthropic’s New Research on AI’s Inner Workspace

Anthropic published this week an interesting research paper about LLMs. They may have found something in large language models that looks a lot like a working space for thought. Not that we say "AI is consious" or it has a mind, but rather something more subtle.

source: https://transformer-circuits.pub/2026/workspace/index.html

Inside a model, there seems to be a small privileged space where certain concepts become available for the model to work with. Anthropic calls this J-space (a model representational space). You can think of it as something like a temporary workbench: a place where intermediate ideas, judgments, and partial conclusions show up before the model gives its final answer.

That matters because we usually judge AI from the outside. Normally we are looking for the answers like: is this correct, safe etc.

But the harder question is what happened before the answer appeared. Was there any reasoning? Something suspicious happened? Not disclosed mistake? Maybe even right answer but for the wrong internal reason? Until now, LLM interaction was some kind of a blackbox that has an input and produces a text outside. This research gives us a way to start looking at some of that hidden process.

One example I like is arithmetic. A model might only output the final answer, but internally you can sometimes see intermediate steps appear before the final response. In other cases, the model may recognize that a piece of code contains a bug, or that a prompt looks suspicious, before it says anything about it.

source: https://transformer-circuits.pub/2026/workspace/index.html

 That has big implications for AI safety. The future of trustworthy AI will not just be about making models more polite or better at refusing bad requests. It will be about understanding what is happening inside them. Because an answer can look fine on the surface while the internal reasoning behind it is not fine at all.

That is the part I find most important here. We are moving from “Does the model say the right thing?” toward “Can we inspect how the model got there?” There is still a lot to be careful about. This is not proof that AI thinks like humans. But it does suggest that these models may have internal structures that behave like a working memory for concepts.

And if we can observe that space, even imperfectly, we may get better at detecting hidden reasoning, strategic behavior, mistakes, and mismatches between what a model says and what it is internally representing.

To me, that feels like a meaningful step. Now we can make AI systems not only more capable, but more inspectable.

Link to full article: https://transformer-circuits.pub/2026/workspace/index.html

External commentary: https://www-cdn.anthropic.com/files/4zrzovbb/website/cc4be2488d65e54a6ed06492f8968398ddc18ebe.pdf

 

 

From Farms to Blockchains: Understanding Ledgers, Daml and Canton

I often see terms like blockchain, ledger, Daml, smart contracts, and imagine something highly abstract and technical. Now I want to explain using my favorite analogy - farming.

Imagine several farms:

• Your farm
• John's farm
• Peter's farm
• A dairy cooperative
• A bank

They all do business with each other: selling cows, leasing land, financing equipment, making agreements.

Everyone needs to keep track of who owns what.
A traditional database is like a barn full of paper records.

Inside you can write things like:

• John owns 5 cows
• Peter sold 2 pigs
• Mark leased a field

The barn stores information well. But the barn itself doesn't enforce rules. It doesn't know:

• Can John sell the same cow twice?
• Can Peter see Mark's private agreement?
• What happens if two people try to sell the same cow at the same time?
• Who is allowed to change records?
• What happened first?

A database stores information, but business rules usually need to be enforced separately by applications and processes.

Daml 

This is where Daml enters.

Daml lets you describe the rules of the business:

To sell a cow:

• the seller must own it
• both parties must approve
• after the sale, the previous owner no longer owns it

Daml defines the business rules and workflows that participants must follow.

Ledger

Think of the ledger as a farm manager. A manager who not only checks the rules but also maintains the official state of who owns what.

The manager checks:

• Are the rules followed?
• Is the cow really owned by the seller?
• Has it already been sold?
• Who can see this transaction?

So the system becomes:

Farmer - submits agreement
Daml - defines rules
Ledger - enforces rules, manager
Database - stores records

Blockchain

Now imagine there is no single manager. Instead, every farm keeps its own notebook.

When a cow is sold:

1. You write: "I sold a cow to John."
2. Other farms in the network verify:
   • Was the cow yours?
   • Does it exist?
   • Was it already sold?
3. If everyone agrees, everyone updates their notebook.

That is essentially a blockchain.

Example: public blockchain (Bitcoin, Ethereum)

Anyone can join, think: "Any farmer in the world can keep a copy of the notebook." Thousands of participants maintain and validate the same system. Everyone sees everything.

Enterprise ledger (Daml + Canton)

Think of a private agricultural cooperative, only trusted members participate:

• Bank A
• Bank B
• Exchange
• Insurance company

Each participant can run their own machine, but random people on the internet cannot simply join.

And unlike public blockchains, not everyone sees everything. John only sees agreements involving John. Banks only see transactions they are allowed to see. Privacy is built into the model.

So far we have:

• Blockchain - thousands of farmers sharing copies of the same notebook
• Ledger - a system enforcing rules and maintaining records
• Daml - the language defining the rules
• Database - where the papers are stored

Every blockchain is a ledger.
Not every ledger is a blockchain.

Canton 

Canton Network is a distributed ledger network that shares some characteristics with blockchains, but works differently from Bitcoin or Ethereum. Instead of showing every transaction to everyone, it is built for privacy. Think of it as a "network of networks."

Only the people involved in a transaction can see its details. Other participants cannot. This is called a "need-to-know" model — you only see the information you actually need, not everything happening on the network.

Smart Contracts 

In Daml, business rules are implemented as smart contracts — digital agreements with built-in logic that automatically execute when conditions are met.

Think of it like farming:

Imagine a farmer, a grain buyer, and a transport company making a deal.

The agreement says:

• the farmer delivers 100 tons of wheat,
• the transport company confirms delivery,
• the buyer sends payment.

With paper contracts, people have to check everything manually. With a Daml smart contract, the rules are already written into the system. Once delivery is confirmed, the contract can automatically move to the next permitted step, such as triggering the payment process.

The important difference is that not everyone sees the contract. Only the parties involved can access it.

Putting everything together:

• Database stores records
• Daml defines business rules
• Smart contracts apply these rules automatically
• Ledger validates and maintains the shared state
• Blockchain is one way of running a ledger across many independent participants
• Canton focuses on shared records with privacy and selective visibility between participants.

 

 

 

Qdrant is staying in my setup for good.

Recently, I moved from application-level cosine similarity comparisons to a dedicated vector search engine running at the storage layer. Qdrant significantly improved the performance of semantic search in my pipeline, reducing similarity search time from around 40 seconds to roughly 1 second for the same workload.

What surprised me most was not only the raw speedup, but how much architectural complexity disappeared after the migration.

The previous approach was simple: embeddings were stored as regular data and compared inside the application layer. That was a reasonable starting point.

But I was indexing Flink, which is a big Repo, the architecture crossed a clear boundary.

 

At that point, the application was doing work that belonged to a specialized vector search engine:
- loading large embedding sets into memory
- calculating similarity scores one by one
- sorting candidates in the application process

Moving this responsibility into Qdrant changed the shape of the system.

The application now focuses on orchestration: parsing code, generating embeddings, storing metadata, and asking semantic questions. Qdrant handles vector indexing, similarity search, scoring, and retrieval.

That separation matters.

It made the pipeline faster, but also cleaner:

- fewer memory-heavy operations in the app layer

- clearer ownership between application logic and retrieval infrastructure
- a much better foundation for future RAG-style workflows (MCP Server?)

It doesn't have to be “always start with the most advanced tool.” Start with the simple architecture that lets you understand the problem. Then, when the system shows you where the boundary is, move the responsibility to the right layer.

In this case, vector similarity search clearly belonged in a vector database.

Qdrant turned out to be the right fit.

Repo: https://github.com/wbrycki/code-genius

Qdrant: https://qdrant.tech/