Social posts and publishing
Social work covers drafts, schedules, publish actions, accounts, and performance analytics.
Social publishing manages content from a draft through scheduling or publication. Use it when you want to prepare a post for a connected social account, then review the schedule in Calendar at /dashboard/calendar. It is separate from Context, which supplies workspace knowledge, and from sequences, which deliver outreach.
Architect uses the social, LinkedIn posts, X posts, and Reddit posts skills to plan the requested channel work. Those skills teach the practice, while the fetched social capability contract determines what the system can actually do.
Schedule or publish only after checking the contract
Search and fetch the exact schedule or publishing capability before running it. A connection can be needed for delivery, but missing connections do not prevent you from creating a draft. Use a dry run when that contract supports it, then examine the returned object and its web_url in Calendar.
Review the draft in Calendar
A draft is the point where content can be checked without being delivered. Architect uses the social, LinkedIn posts, X posts, and Reddit posts skills to plan the requested work, but those skills do not grant a publishing capability. The fetched capability contract defines the account, content shape, and mode that an actual request can use.
The article-create capability creates an article, its content artifact, and an empty body. It forces LinkedIn as the target, has no account binding, and cannot schedule regardless of supplied values. The resulting object is a draft to inspect, rather than a request that has already selected a social destination.
Open Calendar after a state-bearing result provides a link. Check the visible draft, target platform, and intended content before you ask for a schedule or publication capability. JSON ids remain the source of truth for later calls, while web_url links to the matching app screen.
Keep draft, schedule, and publication separate
Creating content, scheduling content, and publishing content are different operations. A draft can exist without a connected account, while a delivery action can require a connection to the requested provider. Missing connections block the later execution step, not the work of preparing the draft.
Use Modes to inspect the exact schedule or publishing contract. A smoke test inspects schema and policy, and a dry run validates and previews against workspace state without a business write, provider spend, or outward action. Live execution is the point at which the chosen contract can create its described effect.
When a paid live call returns quote_required, retain its parameters and rerun with the quote binding and a max_credits ceiling. The estimate belongs to that request. Do not infer a schedule or publication cost from a separate draft because their capability contracts can differ.
Check delivery state after live work
A live publishing request can create durable work. If its result includes a Run, use Runs to see whether execution completed, remains incomplete, or exposes more event pages. Do not treat a request receipt as proof of later provider delivery.
Calendar is the app surface for reviewing planned content. It complements the Run record by showing the content object and its scheduling context. Check both when a post has a scheduled date or target account, because the Run is execution evidence and Calendar is the object view.
Context is separate from publication. Use Context to maintain workspace knowledge, then use the social contract to create and deliver a specific content object. A Sequence is also separate, because it controls outreach journeys rather than a social post lifecycle.
Keep these boundaries visible when you report status. A draft proves that content exists, a schedule describes planned timing, and a publication result describes a delivery action. Check each state in its own object or Run record.
When publishing work fails
Keep status reports specific: a draft proves content exists, a schedule records planned timing, and a publication result records a delivery action. Check each state in its own object or Run record.
If discovery does not return a contract for the requested outcome, change the request or use the capability that was returned instead of guessing an id. If delivery needs an unavailable provider connection, retain the draft and resolve the connection in the app before retrying. Inspect its run when the call returns a run handle.
If a live request has an external audience, stop at the draft until the target platform and connected account are correct. Use the returned error repair information and refetch the current contract when it came from another turn. A failed delivery does not change the distinction between the draft object and the later provider action.