Vision

What Atlas Portal is for. Read this before proposing what to build next — the register says what is committed, this says what it is all in service of.

The north star

Not a toolbox. A client record that does work.

The failure mode to avoid is a portal that is ten disconnected tools sharing a login. What Alex described is the opposite: open a client, see how they are doing, see what worked and what did not, and press a button that produces the next thing — informed by everything already known about that client.

So: the client record is the spine. Every feature hangs off it or it does not belong here. A feature that cannot answer "which client, and what does this know about them?" is a tool, not part of the system.

The organising surface: client success

One page per client, and it is the product:

┌─ Inspire ID Group ───────────────────────────────────────────┐
│  Performance      what ran, what worked, what fatigued        │
│  Knowledge        verified facts, approved angles, conflicts  │
│  Roadmap          goals, deliverables, what is due            │
│  Actions          [generate proposal] [ad report] [new angle] │
│  Changelog        what happened, decided, delivered           │
└───────────────────────────────────────────────────────────────┘

The changelog matters more than it sounds: it is the second brain. An agency's real failure is nobody remembering what was decided three months ago, and every downstream tool inherits that amnesia.

What compounds, and what is merely work

The list of wants is roughly twenty products. Most will never be built, and that is fine — the job is picking the few where building one makes the next cheaper.

Compounding — build these:

Not compounding — buy, integrate, or defer:

Performance ingest is the keystone

Half the list is impossible without it: "what worked", "do we need new creatives", client dashboards, the agency dashboard, creative proposals informed by results, angle fatigue.

Everything built so far produces creative. Nothing yet learns from it. Until performance data flows back, the system is a very careful one-way pipe.

Two notes:

• Backlog creatives should be processed once, slowly, cheaply into the knowledge base rather than analysed on every request. Pre-process, then serve instantly. Same principle as buying a scene once.
• agency-monitor already exists and already watches ad accounts. Absorb or integrate it rather than building a second thing that reads Meta.

Replacing ClickUp

The differentiator is not better task management — ClickUp is fine at that. It is that tasks are generated by the pipeline rather than typed by a human: brief lands, ideation runs, scripts are drafted, tasks appear assigned to the right people with the client's knowledge base attached.

That only works if each stage is genuinely good. A half-decent scripting stage produces tasks nobody trusts, and then the team goes back to ClickUp. So: do not replace ClickUp until the pipelines feeding it are good enough that generated work beats typed work.

Scripting in particular is not one skill file. It needs several agents — hook, structure, proof selection, voice — with a critic, because the nuance is where the quality lives.

Where agents go, and where they do not

The standing rule from docs/rules/cost.md: agents where volume is low and judgment is high; code where volume is high and the path is fixed.

Applied to this list:

• Code / API: rendering, performance ingest, reports, assignment, calendar, invoicing, dashboards
• Agents: ideation, scripting, strategy, reconciliation, proposals, storyboarding, orchestration
• MCP: anything a vendor already does well — generation, video analysis, clip cutting

The orchestrator picks *which* agents run and in what order. It does not do the work, and it never sits in a hot path.

Scalability: media is the thing that kills this

An agency portal dies on file size, not on request volume.

Rules, to be honoured from the first upload:

1. Never proxy media through the app. Direct-to-storage uploads with presigned URLs, direct downloads from the CDN. A Node process streaming a 4GB rush is a dead Node process.
2. Never store media in Postgres. Rows point at object storage. Always.
3. Derivatives are content-addressed and cached. A crop is computed once, keyed by hash.
4. Video never touches the web dyno. Transcoding and analysis are jobs, not requests.
5. Egress is a cost line. R2 chosen for zero egress because creatives get downloaded constantly.
6. Thumbnails, not originals, in every list view. The obvious mistake is the expensive one.

Atlas Brain

An advisory layer over everything the portal knows. Two modes, and the difference is a data boundary, not a UI toggle.

Owner mode — Alex and Jun Kai

Strategic questions across the whole business: *"what is the biggest bottleneck right now?"*

It must answer across every dimension, not just P&L. A bottleneck is rarely financial — it shows up as one of:

Employee mode — by role

An editor asks *"what should I work on"* and gets their queue with the client context attached. They do not see margins, salaries, or another client's profitability. This maps onto the roles already in the schema — admin, strategist, operator — and is enforced by the same RLS, not by prompt instructions asking the model to be discreet.

What makes it useful rather than decorative

It names the bottleneck and cites the evidence. "Consider reviewing your processes" is worse than silence. The output should be closer to: *"Scripting. Eleven deliverables are waiting on scripts, average age nine days, while generation sits idle. The constraint is one person's approval queue."*

Every claim traces to data. Same discipline as the knowledge base: if it cannot point at the rows, it does not assert it.

It must be willing to say the bottleneck is you. The most common real answer in a founder-led agency is that work waits on founder approval. An advisor that will not say that — because it is uncomfortable — is worthless, and this is a property to design for deliberately rather than hope for.

It says what to do next, and what it would need to be more certain.

Why this is late in the sequence, not early

Atlas Brain can only be as good as what it can see. Today the portal knows clients, knowledge and creatives — no performance, no utilisation, no finance. It could currently answer almost nothing worth asking.

It is the payoff for putting everything in one place, not a parallel build. Attempting it early produces a confident advisor working from a third of the picture, which is worse than none — it would be believed.

The counterpart layer

Every employee gets an AI counterpart — their second brain, inside the portal. Claude, but theirs: it holds their context, routes their work, learns from how they do things, and stands in when they are out. Alex's framing: a big lever, added to the vision 20 Aug 2026.

What it is

• A personal front door. Each person talks to *their* counterpart instead of a generic assistant. It knows their clients, their open work, their habits, their standards.
• A router, not a doer. The counterpart decides where a task belongs — a portal pipeline, a Claude Code session, a plain conversation — and dispatches. Orchestration stays deterministic; the counterpart is the judgment at the front, not a hidden pipeline.
• State lives in the portal. Context packs in the database, personality and method in versioned markdown files — the same shape as skills/, one directory per person, hash-versioned so "which version of me answered that" always has an answer.
• Co-built. The person edits their counterpart's files directly (how I write, what I check first, what I never do), and the counterpart also learns from observed actions — approvals, edits, rejections — which the system already records with provenance on every artefact.
• Stand-in when OOO. Ping a person's counterpart when they are away. It answers from their context with the Atlas Brain discipline: cite what it knows, say plainly what only the human knows, never approve on their behalf — the guardrail stays human.
• Cross-learning by role. Individual counterparts feed a role agent: every AM's difficulties, workarounds and initiatives compile into the AM skill at company level. Person → role → company, so one AM's good practice becomes every AM's default.

Why this is cheaper than it sounds

It is the generalisation of loops that already run:

Sequencing honesty

The counterpart layer is the reason several earlier decisions were shaped the way they were, and it comes after its dependencies, not before:

1. Auth — a counterpart without a verified person attached is a toy. This is the concrete trigger the roles decision has been waiting for.
2. The work model carrying real activity — counterparts learn from actions; there must be actions to learn from.
3. Then counterparts, starting with one role (AM) and one person, co-built, before generalising.

Sequence

Each stage makes the next cheaper. Skipping ahead is how the ten-disconnected-tools outcome happens.

What went wrong in the ordering, recorded because the doc warned about it

Steps 3 onwards were built hard while step 2 was skipped, and the result is the outcome this document opens by naming: roughly twenty endpoints, each defensible, that a person has to know about individually to use. Alex's words on 23 Aug: *"instead of just disconnected tools. I want my tools to enhance and work together."*

The endpoints were not wasted — the success page is a composition of them and could not have been built first. But the lesson stands: a capability nobody can reach from the client record is not yet part of the product. Build the spine early even when the organs are more interesting.

The standing tension

Alex wants it fast, cheap in tokens, and not laggy. Those pull in the same direction more often than they conflict: the deterministic path is both the cheap one and the fast one. Reach for an agent when the answer genuinely cannot be computed — and when reaching, prefer one call producing many outputs over many calls producing one.