How it thinks

Every request starts from what Atlas already knows about you.

A chatbot starts from a blank page. Atlas starts from your standing rules, your own procedures, your people, and the time of day — then decides what you meant, how to do it well, and what it is never allowed to decide alone. Here is that path, followed through four requests — one that only answers, three that act.

Before it reads a word

Six things are already in front of it.

Your ruleswhat things mean

"When I say Sam, I mean Sam Rivera." "Those two calendar entries are the same session." Rules like these are present on every message, whatever you're asking about — not fished out of memory when the wording happens to match. A rule that only sometimes applies isn't a rule.

Your policieswhat it may do

Spend caps, quiet hours, standing grants, do-not-disturb. Atlas plans inside them, and when an action brushes against one, the approval card says so — you decide with the rule in view.

Your skillshow to do it well

Written-down procedures: how to book your haircut, how you like an intro email to read, how to move an appointment without creating a second one. Atlas sees the list on every message and loads the full procedure before it starts a task one covers — steps, pitfalls, and how to verify it worked.

Your peoplewho's who

Names, relationships, how to reach them. Your household is always in view — so "what should I make for dinner?" already knows the family's tastes without anyone being named. Everyone else comes in when you mention them.

What's relevantfrom memory

The handful of things it knows that bear on this message — a preference, a verdict on a restaurant, a fact about a place. Retrieved by meaning, not by keyword, and never the whole store at once.

Right nowthe date and the time

Today's date, the day of the week, and the time in your timezone — stated, so it never works out "tomorrow" for itself or guesses whether a 10 AM meeting has happened yet.

Deliberately not in front of it: the full text of every skill, facts about people you haven't mentioned, and anything a connected system can answer for itself. Context is earned, not dumped.

How it decides

Some layers guide it. Some are not up to it at all.

Strongest first. Nothing lower on this ladder can override anything above it — and the top two aren't choices the model makes. They're enforced by the system before and after it.

Its non-negotiablesnever claim an action it didn't take · never share what you didn't ask it to · always in your language
The gatesnothing outward without your approval · one action at a time · the same approval can't run twice
Your policieswhat it may do — surfaced on the card, never silently applied
Your ruleswhat things mean — always applied
Your skillshow to do it — loaded first, followed through verification
What it knowsyour people, your calendar, your memory, the time
Your requestread in light of all of the above

The order is the point. A request can't talk Atlas past a rule; a rule can't talk it past a gate; and nothing talks it past its non-negotiables.

A simple request

"How is my day looking for tomorrow?"

Simple to ask. Answering it well means knowing that a calendar is not the truth about your day — it's one witness.

Step 1

It already knows when "tomorrow" is

The date and the day of the week are stated in front of it. Nothing is derived, so nothing is off by one.

Step 2

It gathers every witness

All your calendars — personal, work, shared — plus the record of what actually happened: the appointment you cancelled in Atlas that's still sitting on Google, the session that took place after its entry was deleted.

Step 3

It reconciles them, once

The same event on two calendars is one event. Cancelled beats "still on the calendar." A household member's appointment is theirs, not yours. Where the sources disagree, it says so instead of quietly picking one.

Step 4

It answers in your terms

Your timezone, your format, your day versus the family's. If something is cancelled but still on your calendar, that's mentioned — and it can offer to tidy the calendar to match.

Honest footnote: for a quick schedule question, Atlas may today answer from the week it pre-loads at the start of a conversation rather than running the full reconciliation. We're closing that gap; the morning brief already uses the full path.

A request that acts

"Send Jordan an email about becoming an Atlas test user."

One sentence from you. Six steps from Atlas — and the email doesn't leave until you've seen it.

Step 1

It knows who Jordan is

Jordan is in your people — a colleague, address on file. No lookup, no guessing between two Jordans; if there were two, a rule would settle it.

Step 2

It loads the skill for this

You've taught it how an Atlas intro email should read: your voice, honest about the setup, sent from your business account rather than your personal one. It loads that procedure before writing a word.

Step 3

It drafts, proofreads, and checks your policies

The draft is proofread before you see it. If a policy applies — quiet hours, a standing rule about that account — the card says so. Nothing is blocked silently, and nothing is bypassed silently.

Step 4

It shows you a card — and stops

To, from, subject, the full message, the proofread notes. Nothing has been sent. Ask for changes, reject, or approve. One action at a time: if you'd asked for two emails, you'd see the second only after deciding on the first.

Step 5

You approve — it sends, once

Through the account the skill named. The same approval can't run twice, and the reply quotes what actually happened rather than what was planned.

Step 6

Afterwards, it may propose what it learned

If a task took real figuring-out, Atlas can write the procedure down as a new skill — staged for your approval, never followed until you say so.

One judgment it won't make for you: Jordan's address on file is a work mailbox, and the skill says "the recipient's personal address." Atlas asks — it doesn't invent one.

A goal, not a command

"Find us a table for four on Friday around eight, book it, and text Sam the details."

Three things in one breath. Atlas doesn't run them as three commands — it makes one plan, gets one approval, and follows through.

Step 1

It drafts a plan, and shows you the whole thing

Search for tables → pick the best fit → book it → text Sam. Reads are marked as safe; the booking and the text are marked as actions. You approve the plan once, up front — not step by step.

Step 2

Skills come first

If you've taught it how you like to book — where to look, what to do when the first search comes back empty — that procedure is loaded before the first step runs.

Step 3

It runs, and adapts

Reads run automatically. Between steps it looks at what came back: no 8:00, but an 8:15 — take it. A step that fails doesn't sink the plan; Atlas re-plans around it and, if the new plan changes what it will do, comes back for your approval.

Step 4

It follows through

The text goes to Sam through the channel you prefer. If the plan needs a reply — "does 8:15 work?" — it waits for one; a wait that would span days is handed to a follow-up watch that checks back at the right time.

Step 5

It tells you once, with the real result

One notification when the plan completes — the actual reservation, the actual time — or a clear account of where it stopped and why.

After

It may write down what it learned

If the booking took real figuring-out, Atlas can propose the procedure as a skill for next time. Staged for your approval; never used until you say so.

Nobody asked

A text arrives: "Have to cancel Friday's session, sorry."

You didn't say anything to Atlas. It noticed anyway — and knew how far it was allowed to go.

Step 1

It reads the message and knows what it's about

Your trainer, Friday's session — the one already in your calendar and in Atlas's record of your appointments. Not a keyword match: the same reconciliation that answers "how's tomorrow?"

Step 2

It records the change, with the evidence

The session's outcome becomes cancelled, and the record keeps the words that proved it. From now on, the morning brief and any question about your week get the right answer — even though the entry still sits on your calendar.

Step 3

Your standing order fires

You once told Atlas: "whenever a session with my trainer is cancelled, clear it from my calendar." That's a playbook. It matches, and Atlas drafts the plan to do exactly that.

Step 4

It goes as far as you said — and no further

If the playbook is set to ask first, the plan stops at the approval card. If you set it to run automatically, it runs — and tells you right after, every time. Either way it's on the record.

Even without a playbook

The calendar still catches up

Each morning Atlas compares your calendar with what it knows actually happened. A cancelled session still sitting there is offered to you — once — to clear.

The line Atlas holds: it will change what it knows on its own; it changes what's yours — your calendar, your messages — only with permission you've given, in advance or in the moment.

The gates

Decided by the system, not by the model.

01

Nothing outward — a message, a call, a booking, a calendar change — happens without your approval.

02

One action at a time. Atlas will never tell you it's doing two things "at once"; it can't, and it says so.

03

It never claims what it didn't do. "Sent" means the send returned; "booked" means the booking was read back.

04

Your rules apply on every message, not only when the wording reminds it.

05

Anything it teaches itself waits for you. A wrong fact corrects itself next time; a wrong procedure would repeat — so procedures are approved first.

06

Every morning it checks its own indexes against the record, repairs what drifted, and tells you once if something was out of step.

Approval cards · Proofread before you see it · Policies surfaced, never silent · Skills staged until approved · Daily self-check · Full activity history

How Atlas stays in your control →

The model is the reasoning. The architecture is the judgment. Atlas is built so the second doesn't depend on the first having a good day.

Go deeper — the technical architecture →