Presence is how we test it on ourselves

We run it on ourselves first. Presence is our own tool: it builds this site from approved pages only, and social posts wait in a dry-run queue. A person decides what ships. Nothing publishes or replies until a person approves it, and no agent spends money at all.

Agents draft faster than anyone can casually review. Presence keeps your brand and legal facts straight at that speed.

See it in 32 seconds

Transcript (video with voice-over and music, 32 seconds):

Voice-over: If agent work is piling up, replies come back generic, and the clock keeps running. MeltingFace gives each agent one scoped job, with your brand kit and approved facts. Replies get sharper. Time on task comes down. Help is shaped to how you work, and it's ready before you ask. And a person still decides what ships. If agent work is piling up, email a person: hello@meltingface.io

On-screen text: If agent work is piling up… Generic replies. More rework. One scoped job at a time. Your brand kit. Your approved facts. Sharper replies. Less time on task. Shaped to you. Ready before you ask. A person decides what ships. MeltingFace. If agent work is piling up, email a person. hello@meltingface.io.

Scenes: golden clay cards pile up; a stopwatch spins while cards stack and bounce back; three brass robots each take their own lane; a blurry card sharpens; a gold ring shrinks as cards fill a tray; tiles rearrange around a person icon and a new tile appears before the pointer reaches it; a check-mark seal stamps a card; an end card with the email address. Sound: an instrumental music bed and soft chimes; no lyrics.

See it run: one draft, five steps

Real captures from a scratch copy of this repo, made on 2026-10-18. Steps 1, 2, 3, and 5 are the terminal. Step 4 is the local preview. The demo post exists only in that copy.

1. Brand kit

The brand kit check confirms the palette and the forbidden-claims list that agents read.

Terminal: python scripts/validate-brand-kit.py lists PASS lines for the palette and forbidden claims, then ALL CHECKS PASSED

2. Draft

The blog-draft command writes a draft to the drafts folder and scans it for forbidden claims.

Terminal: presence blog-draft "Walkthrough demo" writes content/blog/_drafts/walkthrough-demo.md, and the forbidden claims scan passes with 0 failing hits

3. Approval

Approval can't skip review. Approving a raw draft fails. It goes to review first, then to approval.

Terminal: presence approve-draft fails because a draft cannot move straight to approved; submit-review marks it reviewed; approve-draft then approves it and live publish stays gated

4. Preview build

The approved post shows up in the local preview build. Nothing is live.

Local preview of the blog page with the Walkthrough demo post as the first card

5. Dry-run queue

The social-pack command writes the X and LinkedIn posts to a dry-run pack. Live social posting stays gated.

Terminal: presence social-pack writes a dry-run social pack; the pack shows mode dry_run and the line Local preview only. Not a live post.

What you can do with it

  1. Keep your palette, voice, legal text, and company facts in files agents can read.
  2. Draft and review in a CRM with approval steps instead of a shared doc everyone overwrites.
  3. Build a static corporate site from approved markdown and the brand kit.
  4. Queue X and LinkedIn posts in dry-run. Nothing goes live until the Board approves.
  5. Plan campaigns on a calendar with no real-money spend and no auto-replies.

Components (v0.1)

  • Brand kit — palette, voice, facts, forbidden claims; agents read, never invent
  • Content CRM — multi-state approval with an audit trail
  • Static site generator — approved markdown → branded `site-out/` (local preview)
  • Social adapters — X and LinkedIn dry-run queues only
  • Campaign calendar — planning only; no live network spend

Safety is the feature

  • `DRY_RUN=true` / `PUBLISH_MODE=dry_run`
  • A person on the Board approves before anything publishes
  • Agents don't spend real money and don't auto-reply
  • After approval, channels go live one at a time

Names for those gates are under How it works.

How it works

Orchestration

One focused job, a parent waiting on a result, and no swarm fighting over the GPU.

 Routing

Which model should answer which kind of task.

 RAG

Agents quote your brand kit and facts pack instead of inventing a company.

 LLM Ops

Nothing goes live until a person approves it. Gated tests show whether the work got better.

Agents do the repeatable work. You keep the goals, the brand, and the spend. Each agent gets one job, a clear owner, and no budget, so you know who answers for it. Site changes run against gated tests and a checklist before a person signs off, so you can see whether the work got better.

The names are orchestration, routing, RAG (they look up house truth before they write), and a human in the loop. Those are the method. They are not the offer.

Words we use on purpose

  • Agentic-first — people own the goals, brand, and spend. Agents do scoped work inside the rules.
  • Orchestration — roles, handoffs, recovery, one job at a time
  • Routing — which model and which machine answers, given privacy, cost, and skill
  • RAG — retrieval-augmented generation. Agents look things up in your brand kit before they write, so they don't make up something that sounds right.
  • LLM Ops — watch, test, hold, and approve model work, with a person in the loop
  • HITL / dry-run — human in the loop. Everything stays a preview until a person approves it, and nothing publishes on its own.
  • Sole-leaf execution — one focused task at a time, so the GPU and the team aren't overloaded

Orchestration

What breaks: Piles of agents redo work, reopen finished tickets, and burn the only GPU.

What you get: Specialist roles that answer to a human Board. A parent task waits on one active child task, and recovery doesn't reopen finished work.

Read: Agentic-first companies · Local orchestration

Routing

What breaks: One model for every task leaks data or wastes spend.

Read: LLM routing, data centers & RAG

RAG

What breaks: Agents make up a company: hex codes, legal notices, founder bios.

What you get: They look up Board-approved facts first, then approved pages, then runbooks. A filter blocks forbidden claims before a draft is done.

Read: Brand kits as source of truth · RAG as corporate memory

LLM Ops

What breaks: Chat demos don't survive a real publish path.

What you get: Golden tests, forbidden-claim checks, dry-run, then Board approval. Going live follows written steps. No agent can spend real money.

Read: ML evaluation loops · Evaluation protocol · Dry-run by default

How it fits together

A person sets the goal. Orchestration hands it to one specialist. Routing picks the model. RAG supplies the facts. Review gates hold the result until a person approves it.

Diagram: a person sets the goal, then orchestration, routing, RAG, and review gates, then a person approves it going live

Orchestration flow: Hephaestian blocked parent, Daedalus child, Aegis tests, Janus review

Presence is this setup applied to our own website and social posts. It's the lab, not the whole company.

Research behind the lab

Pricing isn't set yet. v0.1 is advisory and dry-run only. No live social and no agent spend until the Board approves.

Email a person