Core concept · schedule authority
Schedules and plans
Each connected account has an autonomy level. Postdom applies the strictest level across every destination before accepting a schedule.
Account autonomy
Authorization modes
New connected accounts start with bounded autonomy. A human can choose a stricter mode for any account without granting the agent permission to change its own authority.
L0 · Manual
The agent creates a draft. A human chooses whether and when it publishes.
L1 · Post review
Each agent post waits for exact human approval before provider handoff.
L2 · Plan review
Posts flow only inside one approved plan covering the accounts, UTC window, and post maximum.
L3 · Bounded autonomy
Posts flow only inside the account's saved daily cap, visibility allowlist, and quiet hours.
Default bounds
New accounts start at L3 with a three-post daily cap and quiet hours from 23:00 to 07:00 in the account timezone. Humans can edit the policy or select a stricter mode.
For multi-account posts, the strictest destination governs the whole request. Postdom never splits one request into partially authorized publishes.
Human and agent roles
Plan boundary
An agent proposes a bounded plan. A human approves it or returns structured feedback.
Proposes authority
Supplies the configured accounts, UTC window, objective, post maximum, and intent.
Grants authority
Approves the plan, requests changes, rejects it, or leaves it to expire.
Records authority
Preserves plan state, structured feedback, authorized destinations, and post usage.
Concept contract
Configured contract
The configured plan tool accepts seven required planning fields. Workspace Brief version, agent identity, and idempotency are optional callable fields.
account_ids- Destination accounts inside the requested boundary.
starts_at · ends_at- RFC 3339 UTC datetimes ending in
Z. title · objective · intent- Human-readable purpose and calling-agent intent.
max_posts- The maximum number of posts authorized by the plan.
brief_version- Optional Workspace Brief version used to prepare the plan. It must exist in the same workspace.
requires_approvalapprovedchanges_requestedrejectedexpiredcancelledRead and return these values exactly. Do not collapse them into approved or denied.
Labeled example
Example plan
The account IDs and values below are examples. They do not represent a connected workspace.
submit_plan({
account_ids: ["acct_example_ig", "acct_example_yt"],
title: "Launch week",
objective: "Coordinate the approved launch schedule",
starts_at: "2026-09-01T00:00:00Z",
ends_at: "2026-09-07T23:59:59Z",
max_posts: 12,
intent: "Schedule approved short-form video"
})Stop conditions
State handoff
requires_approvalWait for a human
Stop scheduling against the plan until its state changes.
changes_requestedRevise the plan
Use the returned feedback category and text, then submit a deliberate revision.
rejected · expired · cancelledReturn the boundary
Stop plan-backed work. A human must define or authorize a new plan before that work continues.
approvedStay inside it
Use only its accounts, time window, and remaining post capacity. Destination validation and pause controls still apply.