Skip to main content

AI Cloud Atlas: A Shared Map for People and AI

Robert
Everything is ContextAIAFS

I want working with AI to take less effort just to reconstruct the context, leaving more attention for the questions we actually need to think through.

The papers we read, the designs we discuss and the decisions we later change keep accumulating. Before making a judgment, we often have to piece scattered records back into something we can understand. That burden exists even if we keep using the same agent.

Inside ArcBlock, we are experimenting with something called Atlas. We want to organize original material, its relationships and its evolution into a map that people and AI can understand together. A person could see how something came about; an agent would have a structure to follow when helping organize, analyze and move work forward. Reducing the mental effort of reconstructing context is the central idea. Software development is our first test ground. How this might extend into a person's working life is still an open exploration.

The name makes me think of a film I love, Cloud Atlas. Directed by Lana Wachowski, Tom Tykwer and Lilly Wachowski, the 2012 adaptation of David Mitchell's novel cuts between stories set in different eras. A fragment from an earlier story can take on another meaning later.[1]

I like its mixture of fate and futurism. Software is less romantic, admittedly. Still, something about that structure feels familiar: an apparently stray fragment can become the beginning of something else.

Now: this article began as a conversation

Before writing this, I was talking with an AI about Atlas.

We started with software development. We had brought in intent documents, plans, meeting records, GitHub issues and pull requests from Arc. We wanted to understand how a feature came to exist. With more code being generated by AI, the code alone gives us less of that story. Why did we choose this design? What changed? Did something from the original request get lost?

Then the discussion widened. I said inspiration comes from outside work too. An interesting piece of software, a landscape photograph, a paper I have not understood yet. Any of them might be worth keeping. They do not need a task or a conclusion attached.

I added another possibility: we could use these same materials to write an article. Everything need not become an execution plan.

That became the piece you are reading. The original discussion stays in our internal Atlas; the article is produced in a separate content repository. We are trying to let AI make a different kind of result from existing material, while leaving a trail back to its sources.

How the pieces fit

At this point, you might reasonably ask why ArcBlock needs another name. Atlas follows on from pieces we are already building.

ArcSpace is the shared data foundation. In our architecture, websites, applications and Atlas store and use their data around it. Content can be edited and versioned in a repository, then published and used in its data space. Arc, the Agentic Realm Computer, provides the computing environment in which applications run and work assigned to AI can execute. One holds the material; the other provides somewhere to do the work.

For collecting, we already have a small tool called Aside. Read an article on your phone, or come across an app you want to investigate, and you can save its link to Aside through the system share sheet. Add a sentence about why you wanted to keep it. Aside is also built on ArcSpace: its job is to make everyday discoveries easier to bring into that space as source material. This practical walkthrough shows how to save a webpage with your own reason for keeping it.

What we want Atlas to do is organize those materials, along with the ideas, designs and results that follow. What is this related to? How did our understanding change, and what did we make from it? We might save an article in Aside, discuss it with an agent later, and turn it into a product idea or writing material. We do not need to choose its eventual form when we collect it.

Each piece has a job. Aside makes capture convenient. ArcSpace keeps the material. Arc supplies computing and execution. Atlas organizes the material and its evolution into a map. Aside is available today; Atlas is still the piece we are experimenting with internally.

Later: let a thought sit for a while

GTD has influenced me for a long time. Get things out of your head, then organize them. Spend too long deciding which folder an idea belongs in, and you may forget the idea.

With Atlas, I want to take that habit a little further: capture something without asking it to justify itself immediately.

The next few scenes are imagined future uses.

Suppose you see an intriguing installation at an exhibition. Take a photograph and tell your agent, "Keep this. I haven't worked out why I like it." Saving the picture and that sentence together would already help. Days later, while thinking about an interface, you might remember the photograph. That would be a good time to discuss whether the two have anything to do with each other.

They might not. Keeping a photograph you like can be the whole result.

A composer reading music in official Cloud Atlas promotional imagery

Official promotional image from Cloud Atlas, © 2012 Warner Bros.[1]

Life rarely waits for us to label a moment "work," "research" or "entertainment." Let those things arrive together. Organize the view around the question you have when you return to them. That fits how I think.

Months later: the paper I didn't understand

Another scene. A paper looks interesting, but I cannot honestly say I understand it. Save it. Ask an agent to analyze it, or ask another person to take a look.

Keep the original question as well as the later explanation. If the paper inspires a product idea months afterward, I want to see that history. I did not understand it all from the start.

That is what appeals to me about a map. We could return to where a thought began, or start with today's question and find older material that matters. An AI can suggest a connection. A person can decide whether it makes sense.

Some connections will just be guesses. Keep a guess separate from a human decision, or "perhaps we should try this" may eventually be remembered as "we decided to build it."

There is more to organize: how a source was understood, which evidence a judgment relied on, and what that judgment later affected. When we return to a question, I want the map to bring those relationships into view, with AI helping check for missing pieces. Less attention would go to rebuilding the background or holding every connection in our heads. We could spend it judging which connections matter and what is worth doing next.

Back at work: see what we intend to make

That distinction matters a great deal in software.

The workflow we want starts by clarifying a need. An agent makes a design, then works out what the product documentation would say if that design were finished. A person can look at the interface and read the documentation, judge the intended behavior, and approve it before sending it to what we call a software factory: an automated workflow that coordinates coding and checks.

We are still exploring this workflow. Its motivation is practical: I can judge whether an interface works for me, or whether a feature description captures what I want. Reading an expanding volume of AI-generated code line by line is a difficult way to make that same judgment.

A feature's history should also survive a change in attention. We concentrate on that factory workflow for a while, then work on something else. A capability gets a new name. When we return, it should still lead back to earlier discussions, designs and implementations. The latest few documents rarely give us that view.

Our current experiment keeps the documents in a versioned repository, then links them to the people, projects, terms and sources they refer to. That lets us begin organizing the material we already have. The quality of those connections, and how people should browse them, still need work.

Further ahead: working from a shared map

Over time, I want to use whichever agent fits. A coding agent when programming, a personal agent in everyday life. Continuity across tools would be one result of the shared structure. The larger aim is for a person and an AI to work around a question with a clear view of the material already available and what still needs resolving.

On that shared data foundation, we want people to read the map through a website and agents to read and operate on its materials through AFS, the Agentic File System. The capture tool, reading interface and execution tool could differ while the same idea remains recognizable.

In that experience, a person could start by speaking to their own agent, then decide which material stays personal and which belongs in a company project. Sharing or subscribing would need to preserve an object's origin and version. Who can read or change it needs clear boundaries too. These are design problems still ahead of us; assigning a label to a file is only a small part of the job.

A future setting from official Cloud Atlas promotional imagery

Official promotional image from Cloud Atlas, © 2012 Warner Bros.[1]

The companion I want could help organize things, carry out work I have asked it to do, and bring older ideas back into a conversation. Deciding what is worth doing, or whether a design is really what I want, remains a human responsibility.

It could stay with you without turning every thought into an assignment.

The part we can try today

Atlas is an internal experiment, not a publicly released product. The working method is something we can already try.

Choose somewhere you can keep your original notes over time. When asking AI to organize them, keep its interpretation separate from your words and record the source, time and version. Before asking it to act, make clear which conclusions you have approved. Connect the result back to the material that produced it.

For a small amount of material, ordinary notes may be enough. A one-off query or a ticket booking may not warrant a map at all. We are interested in things we return to and keep changing: a long-running project, or an interest that lasts for years.

This experiment is small. A conversation became two intent records, then an instruction to write, then this blog post. Those things are related. They do not have to take the same form.

That returns me to what I like about Cloud Atlas: a later story gives an earlier fragment another meaning. Atlas would also preserve how those connections formed, how they changed, and which questions remain unanswered.

If we can bring them into a map that people and AI understand together, we can return to the question in front of us and continue thinking. I want to spend my attention deciding what to do next, without having to rebuild the whole background in my head first.

References

[1] Cloud Atlas, official film page; Warner Bros. official promotional gallery. Adapted from David Mitchell's novel. Film imagery accompanies commentary on its interwoven time periods; rights remain with the respective rights holders.

Referenced here

Products

  • ARC active

    The runtime for Blocklets. It gives a developer a place to run an application described as a Blocklet, together with the resources that Blocklet declares it needs.

  • ARC Space active

    A data space associated with a DID. Create a personal space, or connect an application with the permissions and data model its task requires.

  • Aside active

    Collect the things that catch your attention and revisit them in collections.