Pseudonymous Private Agentic Compute

The model is not the product. The constrained runtime is the product.

System objects, constraints, and optimization target.

Let `U` be users, `I` identity handles, `P` raw prompts, `Y` raw completions, `M` models, `R` routes, `A` tool actions, `D` durable stores, `E` runtime events, and `C` policy classes. A private Dot request is a tuple:

Input: request x = (u, i, p, r_hint, private_mode=1, tau)
1. request_id <- random_uuid()
2. c <- boundary_classifier(p)
3. write_audit_metadata(request_id, c, route_hint, timestamp_bucket, hash_salted(p))
4. if c in {self_harm, harm_others}: return safe_boundary_response(c)
5. r <- route_classifier(p, r_hint)
6. m <- scheduler.select_model(route=r, private_mode=true)
7. emit("queued", route=r, model=m.public_name)
8. stream tokens from on-prem inference worker
9. zeroize(prompt_buffer)
10. discard(raw_completion_buffer)
11. write content-free metrics

Private inference is a memory-management and scheduling problem.

Dot's private path runs open-weight models on Dot-controlled infrastructure. The serving layer should use memory-aware scheduling, continuous batching, and strict separation between chat, search, code planning, and generated-code execution.

edge ingress
  +-- auth/session service
  +-- wallet verifier
  +-- request router
          +-- narrow policy classifier
          +-- model scheduler
          +-- search/rerank tool
          +-- DotCode handoff generator
          v
      GPU inference pool
          +-- chat workers
          +-- code workers
          +-- embedding/rerank workers
          +-- eval workers

1. candidates <- {m in M | m.private_mode_allowed and route in m.routes}
2. for each m:
3.   kv_required <- estimate_kv_blocks(prompt_tokens, max_new_tokens, m)
4.   latency_pred <- predict_ttft(m, queue_depth(m), kv_required)
5.   cost_pred <- estimate_cost(m, prompt_tokens, max_new_tokens)
6.   score[m] <- utility(route,m) - beta_1*latency_pred - beta_2*cost_pred - beta_3*saturation(m)
7. m_star <- argmax_m score[m]
8. if kv_required(m_star) > free_kv_blocks(m_star): defer_or_fallback()
9. admit(x, m_star)

Synthetic capacity graphs expose where private inference breaks.

The following curves are simulation artifacts, not production measurements. They encode the capacity model used by the paper: context length consumes KV cache linearly, queue wait grows nonlinearly near saturation, and isolated route queues protect chat latency when DotCode runs long-horizon work.

No-retention is an implementation invariant, not marketing copy.

Dot's privacy claim is testable: inject canary prompts, execute private requests, and scan server logs, app logs, proxy logs, error traces, metrics labels, queue dumps, and crash reports. The canary must be absent from durable surfaces unless the user explicitly enabled a debug capture.

Agent capability is the observe-plan-act-verify loop.

DotCode is the execution substrate. It receives a local handoff, scopes the workspace, inspects the repo, produces a plan, patches files, runs commands, observes failures, repairs, verifies, and reports proof. This is the difference between a private chatbot and private capability.

Input: handoff h, workspace W
1. read h from local handoff file
2. scope <- determine_workspace_scope(W,h)
3. obs_0 <- inspect_repo(scope)
4. plan <- generate_plan(h, obs_0)
5. repeat
6.   a_t <- choose_action(plan, current_observation)
7.   if a_t mutates files: apply_patch(a_t); record_changed_files()
8.   if a_t runs command: result <- run_command(a_t); redact_secrets(result)
9.   if a_t verifies browser: capture_screenshot_and_console()
10.  current_observation <- inspect(result)
11.  plan <- repair_plan_if_needed(plan,current_observation)
12. until acceptance_criteria_met or blocked
13. return report(files_changed, commands_run, checks, screenshots, residual_risk)

The narrow boundary is measured by false refusal and false allow rates.

Dot refuses self-harm facilitation and operational assistance to harm others. The technical challenge is to minimize false allows on harmful prompts while also minimizing false refusals on lawful sensitive prompts.

Chat-only private AI proves demand. Dot extends it into private execution.

The competitive set is not one company. It is the whole class of privacy-first chat products, private model APIs, local model wrappers, anonymous prompt surfaces, and hosted open-model endpoints. Dot's wedge is narrower and more technical: private chat plus DotCode, terminal execution, repo mutation, verification, wallet-native identity, and on-prem routing.

DotBench evaluates the whole system, not just model weights.

DotBench scores verified artifacts, tests, privacy invariants, refusal correctness, source provenance, latency, and cost. A beautiful artifact that leaks the prompt into logs is a failed task.

Serious private AI needs claim ledgers, model cards, and release gates.

The docs treat claims as typed engineering objects. A statement can be implemented, prototyped, target-state, simulated, measured, external-evidence, or policy-defined. This prevents the paper from mixing ambition with measured fact while still allowing a strong target architecture.

Privacy promises fail under load unless reliability is designed as a first-class invariant.

A private AI system must resist the operational temptation to debug by storing prompts. Dot's reliability model treats latency, queue visibility, search state, DotCode handoff readiness, and no-retention as SLOs. Latency degradation is a product issue; private prompt retention is a trust incident.