Auctor Agent

A White Paper on Bounded Autonomy for Content Operations

Executive Summary

OpenClaw is useful to Auctor not because Auctor should become a clone of it, but because OpenClaw names a set of agent primitives that are easy to miss when we focus only on prompts, models, or UI.

The core lesson is this:

Smarter agents do not come primarily from bigger prompts. They come from better runtime primitives: durable state, scoped memory, proactive observation, constrained action, skill loading, and tight feedback loops.

For Auctor, the right response is not to become a general-purpose personal daemon. The right response is to become a domain daemon for content operations.

That means:

• more durable than a chat session
• more proactive than a request-response tool
• more stateful than a workflow runner
• more governed than an autonomous shell agent

The thesis of this paper is:

Auctor should evolve into a site-scoped, database-first, policy-governed content operator whose agents can continuously observe, reason, prepare artifacts, request approvals, and learn from outcomes without abandoning the existing stack of Next.js, FastAPI, Mastra, Supabase/Postgres, and Electron.

This paper translates OpenClaw's ideas into Auctor-compatible primitives and argues for a specific architecture: bounded autonomy over canonical content state.

Why This Matters Now

Today Auctor already has several important ingredients:

• a canonical content domain model
• typed workflows for strategy, briefs, and drafts
• a Mastra harness with modes and subagents
• structured grounding via documents, extractions, summaries, and graph edges
• audit logs and sync runs
• a read-only workspace layer
• an Electron shell with scheduled cycles and approval gates

That is already much more than a chat wrapper.

But the current system still behaves like a collection of workflow features rather than a coherent agent runtime. The gaps are not mainly "better prompts." They are runtime gaps:

• memory is fragmented across threads, runs, tables, and files
• scheduled autonomy is prompt-driven rather than state-driven
• workspace artifacts are present but not yet central to cognition
• tool policy exists but is not yet a unified capability model
• agents can act inside workflows, but they do not yet maintain a durable operating posture across time
• the system can log actions, but it does not yet learn systematically from outcomes

OpenClaw is a good foil because it is explicit about these missing primitives.

The Constraints We Should Preserve

Any proposal that ignores Auctor's existing constraints will be elegant on paper and wrong in practice.

The architecture should preserve the following:

1. Database-first canonical state

The source of truth for operational entities should remain the ContentEngine database:

• documents
• extractions
• summary nodes
• graph edges
• plan items
• briefs
• drafts
• reviews
• validations
• workflow runs
• audit logs

Files should remain mirrors, casefiles, playbooks, or working sets.

2. Human approval as a product feature

Auctor's value is not that it removes humans from the loop. Its value is that it makes the loop legible, faster, and better grounded.

Publish actions, major state transitions, and non-obvious decisions should continue to pass through explicit approval surfaces.

3. Existing framework boundaries

We should keep:

• Next.js App Router as the operator surface
• FastAPI as the LangExtract sidecar
• Mastra as the workflow and harness substrate
• Supabase/Postgres as primary persistence
• Electron as the local always-on shell where autonomy is desired

The goal is to deepen the runtime, not replace it.

4. Domain specificity over generic agent breadth

Auctor is a content operator, not a universal personal assistant.

We should resist:

• multi-channel messaging sprawl
• generic shell-first autonomy
• arbitrary plugin execution
• file-first canonical state
• open-ended personal productivity scope

5. Site scoping

The system is architecturally multi-site, even if consul is the dominant default today.

Every durable primitive should remain site-aware.

Current Auctor Anchors

The proposed primitives are not starting from zero. Auctor already contains partial versions of several of them.

Current anchors in the codebase include:

• frontend/src/mastra/harness.ts
  • mode-aware orchestration, shared state, subagents, workspace hookup
• frontend/src/mastra/workflows/content-engine-workflows.ts
  • typed strategy, brief, and draft workflows with suspend and resume points
• frontend/src/content-engine/services/workflow-runner.ts
  • persistent run execution and resume semantics
• frontend/src/content-engine/services/agent-runner.ts
  • model execution, cost accounting, and audit logging
• frontend/src/mastra/tools/content-engine-tools.ts
  • a typed tool surface over canonical content data and publishing actions
• frontend/src/mastra/workspace.ts
  • a read-only searchable workspace with BM25 and filesystem access
• frontend/app/api/harness/chat/route.ts
  • a streaming operator control plane for conversational orchestration
• desktop/src/workspace/scheduler.ts
  • scheduled autonomy with morning, midday, evening, and weekly cycles
• desktop/src/claude/tool-policy.ts
  • approval-gated tool use and workspace-scoped write restrictions

This means the architectural question is not "how do we bolt agents onto Auctor?"

It is:

How do we turn these isolated agent features into a coherent agent runtime?

What OpenClaw Teaches, and How Auctor Should Respond

The most useful way to interpret OpenClaw is primitive-by-primitive.

The pattern is clear:

Auctor should borrow OpenClaw's runtime ideas, not its product surface.

The Auctor Agent Thesis

The right mental model for Auctor is not "chatbot with workflows" and not "desktop AI OS."

It is:

A site-scoped content operator with durable memory, observation loops, typed capabilities, and artifact-centered reasoning layered on top of canonical workflow state.

This implies five first principles.

1. Perception

The agent must continuously observe:

• research freshness
• competitor changes
• ranking movement
• analytics anomalies
• blocked drafts
• pending reviews
• publish readiness

Without perception, autonomy degrades into blind scheduling.

2. Memory

The agent must remember more than the current thread:

• durable site directives
• prior operator decisions
• workflow outcomes
• repeated editorial corrections
• successful and unsuccessful publish patterns

Without memory, every run starts from zero.

3. Deliberation

The agent must decompose work into distinct reasoning roles:

• observe
• prioritize
• plan
• draft
• critique
• validate

Without decomposition, the system becomes one large prompt with weak guarantees.

4. Action

The agent must be able to mutate the world in bounded ways:

• create artifacts
• update workflow state
• prepare casefiles
• request review
• publish only behind policy and approval

Without action, intelligence never leaves the prompt.

5. Governance

The agent must act under policies, budgets, and approval rules.

Without governance, autonomy becomes operational risk.

Reference Architecture

Proposed Primitives

The rest of this paper defines the primitives that would make Auctor measurably smarter while remaining inside the current architecture.

Primitive 1: Agent Operating Profile

Definition

A durable, inspectable operating profile that defines how an Auctor agent should think and behave for a given site, mode, or workflow layer.

Why it matters

Today Auctor instructions live in a mix of:

• hard-coded agent strings
• harness mode prompts
• strategy directives
• workspace templates

That works, but it fragments agent identity across code and storage.

An operating profile would consolidate:

• site mission
• audience and brand constraints
• editorial rules
• escalation rules
• approval boundaries
• workflow defaults
• "never do this" constraints

Auctor-compatible implementation

Represent the profile as a layered combination of:

• DB-backed site directives
• workspace markdown docs
• agent and mode-level instructions
• runtime policy settings

The profile should be loadable by Mastra orchestrators and visible in the operator UI.

What it unlocks

• consistent agent behavior across chat, workflows, and scheduled runs
• easier inspection and revision of agent posture
• less prompt drift between surfaces

Primitive 2: Attention Queue

Definition

A durable queue of agent-relevant issues that need judgment, review, or action.

Why it matters

Right now the system has many raw events and statuses, but not a unified "attention model."

The agent should think in terms of:

• stale research
• competitor spike
• AI overview appearance for tracked keyword
• brief awaiting review
• draft blocked by SEO
• publish-ready draft awaiting approval
• integration degraded

Without an attention queue, proactive behavior turns into repeated full scans of the whole system.

Auctor-compatible implementation

Promote system events and workflow conditions into normalized attention items with:

• site key
• item type
• severity
• owning mode or layer
• linked artifact IDs
• status
• created and resolved timestamps

This can be surfaced in the web UI and consumed by both scheduled loops and interactive orchestrators.

What it unlocks

• proactive work with bounded scope
• better triage
• less redundant reasoning
• an operator inbox that matches how the agent already thinks

Primitive 3: Observation Loops

Definition

Scheduled or event-driven runs that inspect the system, convert raw state into attention items, and only escalate when something actually requires action.

Why it matters

The desktop scheduler already runs morning, midday, evening, and weekly cycles, but those cycles are prompt-driven and broad.

A smarter system should be state-driven:

• check for stale competitor crawl data
• detect ranking drops for strategic keywords
• find drafts stuck in review
• flag repeated editorial corrections on the same agent
• identify publish-ready items with missing metadata

Auctor-compatible implementation

Use the existing scheduler and workflow infrastructure, but shift the contract from "run a long generic prompt" to "execute a typed observation pass."

Observation passes should:

• read canonical DB state
• compute findings deterministically where possible
• create attention items
• optionally generate short casefile notes
• notify the operator only when thresholds are crossed

What it unlocks

• proactive autonomy without chat spam
• less token waste
• a transition from scheduled prompts to continuous monitoring

Primitive 4: Casefile Workspace

Definition

A durable artifact layer that captures the evidence, reasoning context, and output bundle for each important run or content artifact.

Why it matters

The RFC already points toward casefiles, and OpenClaw is right about one thing: agents become more capable when they can inspect and build artifact bundles over time.

For Auctor, casefiles should not replace the database. They should make the database legible.

Each casefile should make it easy to answer:

• what did the agent see
• what evidence mattered
• what it proposed
• what the operator changed
• what finally shipped
• how the outcome performed

Auctor-compatible implementation

Extend the existing workspace into run-scoped and artifact-scoped bundles:

• manifest.json
• evidence summary
• selected extractions
• plan rationale
• brief package
• draft package
• validation report
• publish payload
• reflection note

The DB remains canonical. The casefile is the inspection and export layer.

What it unlocks

• higher trust
• better debugging
• better long-term learning inputs
• cleaner human handoff

Primitive 5: Hybrid Memory Stack

Definition

A layered retrieval model that combines structured data, artifact files, and synthesized run memory.

Why it matters

Auctor's strongest asset versus generic agent systems is that it already has structured retrieval:

• documents
• extractions
• summary nodes
• graph edges
• workflow state

The mistake would be to throw that away and replace it with generic vector memory.

The right move is to add memory layers above it.

Auctor-compatible implementation

Use a three-tier memory model:

1. Canonical structured retrieval from the database
2. Workspace and casefile retrieval through BM25 and optional embeddings
3. Reflection memory composed of run summaries, operator corrections, and learned patterns

The agent should query these in order of trust:

1. DB facts
2. current casefiles and workspace docs
3. distilled historical reflections

What it unlocks

• stronger contextual recall
• less duplication of mistakes
• richer grounding without abandoning structured data

Primitive 6: Skill Packs and Playbooks

Definition

On-demand capability bundles that package domain instructions, templates, retrieval hints, and allowed tools for a specific class of work.

Why it matters

OpenClaw is directionally right that large prompts do not scale. Auctor should not try to stuff every brand rule, workflow nuance, SEO heuristic, and publishing checklist into every model call.

Skill packs let the agent load context only when needed.

Examples:

• competitor teardown playbook
• high-trust B2B briefing playbook
• comparison-page drafting playbook
• internal linking remediation playbook
• publish-readiness playbook
• post-publish monitoring playbook

Auctor-compatible implementation

Represent skill packs as workspace-backed markdown plus structured metadata:

• scope
• owning mode
• required tools
• optional templates
• examples
• approval requirements

Mastra orchestrators can select them explicitly, and workflows can declare defaults by content type or step.

What it unlocks

• modular agent behavior
• less prompt sprawl
• easier continuous improvement
• domain specialization without changing code for every behavior tweak

Primitive 7: Capability Profiles and Policy Engine

Definition

A unified model for what each agent, mode, and workflow step is allowed to read, write, mutate, or publish.

Why it matters

Auctor already has the beginnings of this:

• different tool sets per agent
• desktop approval gates for publish tools
• explicit publish-target state

But the policies are split across code paths and surfaces.

To become more autonomous safely, the system needs a single capability language.

Auctor-compatible implementation

Define capability profiles by:

• mode
• agent
• workflow step
• environment
• site

Each profile should express:

• allowed tools
• allowed write scopes
• approval-required actions
• cost or step budgets
• model class
• escalation rules

This policy engine should be shared conceptually across:

• Mastra tools
• workflow runner
• desktop runtime
• publish surfaces

What it unlocks

• safer autonomy
• more consistent operator expectations
• easier reasoning about what an agent may do in each context

Primitive 8: Execution Lanes and Conflict Control

Definition

A concurrency model that prevents multiple agent runs from stepping on the same artifact or objective at the same time.

Why it matters

OpenClaw's lane queue is not interesting because it is clever. It is interesting because it acknowledges that concurrency without coordination is destructive.

For Auctor, the danger is not two chat messages racing. It is:

• two runs revising the same draft
• a scheduled loop mutating a plan item while a human is reviewing it
• publish and SEO remediation colliding
• multiple agents writing overlapping casefiles

Auctor-compatible implementation

Add execution lanes scoped to:

• site
• plan item
• brief
• draft
• workflow run

A lane should support:

• serialize
• defer
• merge
• require operator choice

The workflow runner, scheduled loops, and desktop runtime should all honor the same lane model.

What it unlocks

• safer autonomy
• fewer artifact conflicts
• cleaner mental model for the operator

Primitive 9: Reflection and Learning

Definition

A structured post-run learning loop that turns outcomes into reusable memory rather than leaving them buried in audit logs.

Why it matters

Auctor already logs what happened. That is not the same as learning from what happened.

The system should be able to capture:

• which plan items were approved quickly
• which briefs repeatedly triggered changes
• which draft issues appear over and over
• which SEO blocks were common
• which published formats performed best
• which agent configurations correlated with higher quality

Auctor-compatible implementation

After major runs, generate a small reflection artifact with fields like:

• objective
• outcome
• operator corrections
• failure modes
• reusable lessons
• confidence for reuse

Only high-signal reflections should be promoted into durable memory or playbook updates.

What it unlocks

• cumulative intelligence
• fewer repeated mistakes
• better agent prompts and playbooks over time

Primitive 10: Model Routing and Deliberation Topology

Definition

A formal map of which models and reasoning roles should be used for which tasks.

Why it matters

Auctor already has partial specialization:

• strategy agents
• writer
• editor
• validator

That should become a deliberate topology, not an incidental one.

Different tasks want different properties:

• observation wants low cost and consistency
• strategy wants synthesis
• writing wants voice and composition
• editing wants critique
• validation wants determinism

Auctor-compatible implementation

Keep the current agent layering, but formalize a topology like:

• observer
• researcher
• strategist
• brief architect
• writer
• critic
• validator
• publisher
• reflector

Model routing should consider:

• cost ceiling
• task criticality
• step budget
• need for tool use
• tolerance for creative variance

What it unlocks

• lower operating cost
• clearer agent responsibilities
• better repeatability

Primitive 11: Operator Inbox and Escalation Surface

Definition

A single place where the agent can surface decisions, approvals, blocked items, and proposed next actions.

Why it matters

The current system already has:

• plan approval flows
• question responses
• suspended workflows
• draft and brief review surfaces

These should become one coherent operator inbox rather than several unrelated interruptions.

Auctor-compatible implementation

Normalize all escalations into operator-facing decision objects:

• approval required
• question asked
• conflict detected
• review requested
• anomaly detected
• publish-ready notification

The inbox should link directly to the relevant casefile or artifact.

What it unlocks

• better human-agent collaboration
• cleaner autonomy boundaries
• easier review of what the system is waiting on

Primitive 12: Autonomy Budget

Definition

A set of hard limits that define how much autonomous work the system may do before it must stop, summarize, or escalate.

Why it matters

The more proactive Auctor becomes, the more it needs bounded stopping conditions.

Otherwise the system risks:

• burning cost budgets
• creating too many low-value artifacts
• over-notifying the operator
• mutating too many entities without review

Auctor-compatible implementation

Budgets can be expressed per run or per cadence:

• max steps
• max cost
• max artifacts created
• max unattended mutations
• max time window
• mandatory escalation checkpoints

These budgets should be visible to the operator and enforced by policy.

What it unlocks

• safer long-running autonomy
• better predictability
• easier trust calibration

Operating Model: What a Smarter Auctor Actually Does

If these primitives are implemented, Auctor changes from a workflow-triggered app into a bounded operating loop:

1. Observe system state and external signals.
2. Convert signals into attention items.
3. Prioritize the highest-value items based on site strategy and budgets.
4. Load the relevant operating profile, playbooks, memory, and casefiles.
5. Delegate to specialized agents or workflows.
6. Write outputs to canonical state and artifact bundles.
7. Escalate when policy requires human review.
8. Reflect on outcomes and store only high-value lessons.

The important change is not "more autonomy." It is closed-loop autonomy.

What We Should Not Copy from OpenClaw

OpenClaw is strongest when it names useful primitives. It is weakest when copied too literally into the wrong domain.

Auctor should not copy:

1. Messaging-platform sprawl

Auctor does not need to live in WhatsApp, Telegram, Slack, Discord, and Signal to become intelligent.

Its natural surfaces are:

• the operator web app
• the agent window
• the desktop shell
• structured inbox and review surfaces

2. Generic shell-first power

Open-ended local shell capability is not the right center of gravity for Auctor.

Auctor should prefer:

• typed tools
• typed workflows
• scoped mutations
• explicit publish approvals

3. Plugin permissiveness

A wide-open plugin marketplace would create trust, maintenance, and safety problems faster than it would add value.

Domain-specific, approved adapters and playbooks are a better fit.

4. File-first truth

Files are useful for legibility and inspection. They should not outrank the ContentEngine database.

5. Personal assistant scope

Auctor should stay focused on content operations, research operations, and publishing operations.

That focus is a strength.

A Practical Adoption Path

This paper is theoretical, but the primitives can be introduced incrementally.

Phase 1: Consolidate agent posture

Goals:

• introduce operating profiles
• unify instructions across harness, workflows, and scheduled runs
• define capability profiles

Expected effect:

• more consistent agent behavior

Phase 2: Build attention and observation

Goals:

• add attention items
• convert scheduled cycles into typed observation passes
• introduce site-scoped execution lanes

Expected effect:

• proactive but bounded autonomy

Phase 3: Make artifacts first-class

Goals:

• implement casefiles for major runs
• connect workspace browsing to actual workflow artifacts
• attach operator decisions to casefiles

Expected effect:

• higher transparency and better memory inputs

Phase 4: Add playbooks and reflections

Goals:

• load skill packs on demand
• promote high-value reflections into durable memory
• connect repeated corrections back into playbooks

Expected effect:

• cumulative improvement over time

Phase 5: Tighten the autonomous loop

Goals:

• introduce autonomy budgets
• formalize model routing and agent topology
• unify inbox and escalation handling

Expected effect:

• smarter autonomous operation without loss of control

The Deeper Theory

The deepest lesson from OpenClaw is not about daemons, chat apps, or markdown files.

It is that useful agents need a runtime that can answer six questions continuously:

1. What do I know right now?
2. What has changed since the last time I looked?
3. What deserves attention next?
4. What am I allowed to do about it?
5. What evidence will justify my recommendation?
6. What should I remember if this happens again?

Today Auctor can answer pieces of those questions.

The primitives in this paper would let it answer them coherently.

That is what would make Auctor feel smarter:

• not more verbose
• not more agent-branded
• not more "autonomous" in the abstract

But more situationally aware, historically grounded, policy-bounded, and operationally continuous.

Conclusion

The right future for Auctor is not a generic AI operating system.

It is a bounded content operations intelligence layer built on:

• canonical workflow state
• artifact-centered reasoning
• proactive observation
• modular playbooks
• explicit policy
• durable learning

OpenClaw shows the shape of the missing runtime primitives.

Auctor's opportunity is to implement those primitives in a way that respects its own architecture:

• database-first
• workflow-native
• human-gated
• site-scoped
• operationally auditable

If we do that, Auctor stops being "an app with agents" and becomes "an agent with a real operating model."