# Your agent creates. Shager ships it everywhere. In the new world, if you have no content, you don't exist. Shager takes what your agent or your team creates and ships it to tens or hundreds of Facebook Pages, Instagram accounts and YouTube channels, at the pace each network allows, with a tracked link for every account. - API and MCP server on every plan - Agents can sign up on their own - 14-day trial, no card ## For agents: Give your agent the power to distribute and to follow every number. Shager is built for AI agents to work with directly. Claude, ChatGPT, Cursor or an agent you built connect over MCP or the API and, in plain language, upload a video, build a post for every account, send it to the client for approval, schedule it, and ask tomorrow what brought in leads. - **Connected in a minute:** One MCP URL and one key. No SDK to install, no integration to maintain. - **Agents sign up on their own:** One call creates a workspace. A person approves with a link before anything goes live. - **Data an agent can read:** Clicks per account, publishing status and errors, structured so an agent understands and acts on it. ## Less manual work. More presence. Every lead with an address. - **Once, not a hundred times:** One post reaches every account, adapted to each network. No copy-paste, no forgotten branch. - **Every lead attributed:** A short link and UTM tag for every account and every post. See exactly which Page brought the enquiry. - **No bans:** Official APIs, staggered delivery across accounts and format checks before sending, not after a network rejects it. - **Clients connect themselves:** Send your client a link and they connect their own Pages. No Shager account, no passwords shared. - **Clients approve from a link:** A preview, an approval or a change request. No more screenshots over WhatsApp. - **Hebrew first, English too:** Right-to-left interface, a Hebrew writing assistant and a holiday calendar covering every religion. Fully usable in English. ## Distribution: Schedule once. It reaches everyone. Pick a group of accounts (a client, their branches, a portfolio of brands) and Shager does the rest: adapts the post to each network, checks the media against each network's rules, and spreads delivery over minutes so it never looks like spam. - **Account groups:** Tens or hundreds of accounts in one selection, by client or campaign. - **Staggered dispatch:** Delivery is spread over time and respects every network's rate limits. - **Checked before sending:** YouTube titles, Shorts aspect ratios, caption lengths: all validated up front. ## Leads: Every account gets its own link. Each post on each account gets its own short link and UTM tag. The link can go out as the first comment, where people actually click, and your report splits itself by Page, branch and video. - **UTM per account:** utm_content identifies the account, so your analytics reports split themselves. - **Our own short links:** Clicks per account and per post, without storing IP addresses. - **First comment:** The lead link is posted as a comment right after publishing, on networks where links are clickable. ## Clients: Clients connect and approve. You publish. Open a client, send them a connect link, and they connect their own Facebook, Instagram and YouTube accounts. When there's a post, they get a preview link and approve it. Only approved content goes out. - **A connect link for clients:** The client signs in directly with the network. You see the accounts immediately and get notified. - **An approval link per post:** A preview that looks like the network itself. Approve or request a change in one click. ## Built to work with the networks, not against them. - **Official APIs only:** No bots, no scraping, no logging in as you. Every account is connected with permission you can revoke at any time. - **A human approves, the agent executes:** A workspace an agent opened publishes nothing until a person claims it. Every agent action is logged. - **Encrypted tokens:** Network access tokens are encrypted in the database and never leave the server. - **Hosted in the EU:** Servers in Finland, in the European Union. No tracking cookies on this site. Self-hosting available. ## Start at $0. Pay per account, not per seat. API, MCP server and unlimited users on every plan. Free forever with 3 accounts, or 10 accounts for $9 a month. Publishing only through the official APIs of Facebook, Instagram, YouTube. In development: TikTok, LinkedIn. --- Source: https://shager.ai/en # From the first connection to the lead. No manual work in between. Five steps. The same process for ten accounts or five hundred, and the same process whether you run it or your agent does. ## Workflow 1. **Connect accounts.** Each client gets their own workspace. Connect accounts yourself, or send the client a connect link and they connect their own Facebook, Instagram and YouTube accounts on the network's official permission screen. Shager never sees or stores passwords. 2. **Organize into groups.** Group by client, region, brand or campaign. An account can sit in several groups. Pick one group in the composer and you've picked every account in it. 3. **Write once, or hand it to your agent.** One composer for every network: text, images, video, a YouTube title, the format (post, Reel, Story, Short) and a first comment. Prefer an AI agent to do it? It does exactly the same through MCP or the API. 4. **Get client approval.** If needed, your client gets a preview link and approves or asks for a change. No account, no screenshots. 5. **Dispatch and measure.** Shager sends at a pace that respects each network's limits, retries when a network is busy, and reports on every account. Each post goes out with its own link and UTM tag, and clicks land in your report. ## What's inside - **API and MCP server:** An AI agent connects and runs the whole system, on every plan. - **Client connect links:** Clients connect their own accounts, without a Shager account. - **Account groups and bulk selection:** Select tens or hundreds of accounts at once. - **Staggered dispatch:** Spacing between accounts to respect network pacing and avoid blocks. - **Media checked up front:** Aspect ratio, video length, titles and text limits, checked before sending. - **First comment:** The lead link as a comment, on networks where links are clickable. - **UTMs and short links:** A tag per account and click counts without IP addresses. - **Client approval links:** Optional per workspace. - **Holidays of every religion:** Jewish, Muslim, Christian, Druze, Hindu, Buddhist and more, with advice per day: hold back, be sensitive, or make the most of it. Your agent gets the same calendar. - **Hebrew writing assistant:** Draft, shorten and adjust tone. You decide what goes out. - **Self-hosting:** The same system on your own server, with Docker. ## Frequently asked ### Isn't this spam? Not when it's done right. Shager only publishes to accounts you manage and are authorized to post to, through official APIs, at the pace networks allow. We recommend adapting content per account (the composer is built for exactly that), and our terms prohibit spam. ### Which networks are supported? Facebook (Pages), Instagram (professional accounts) and YouTube. TikTok and LinkedIn are in development, and we'll announce them when they're live. ### Do you store our passwords? No. You connect through the network's own permission screen and we receive a limited access token, which we encrypt. You can revoke it at any time, in Shager or in the network's settings. ### Where is the data stored? On servers in the European Union (Finland). You can also install Shager on your own server. ### How much does it cost? Start free with 3 accounts, forever. The Creator plan is 10 accounts for $9 a month, then $1 per extra account. API, MCP and unlimited users on every plan. Every plan is on the pricing page. ### Can an AI agent work with Shager on its own? Yes. An agent connects over MCP or the API and can even open a sandbox itself. Nothing publishes until a person claims the sandbox with a link. --- Source: https://shager.ai/en/product # Supported networks. Official APIs only. Every connection happens on the network's own permission screen, with the minimum permissions needed to publish, by you, or by the client themselves through a connect link. Revoke at any time. ## Facebook (Live) - Account type: Pages - Formats: Posts, photos, video, Reels, Stories - Notes: First comment with a clickable link. Connected via Facebook Login for Business. - API: Meta Graph API ## Instagram (Live) - Account type: Professional accounts (business / creator), connected directly with Instagram Login, no Facebook Page needed - Formats: Posts, carousels, Reels, Stories - Notes: Links in captions and comments aren't clickable on Instagram, so measure through the bio link or UTM tags. - API: Instagram API with Instagram Login ## YouTube (Live) - Account type: Channels - Formats: Videos and Shorts - Notes: Title and privacy per video; first comment on public videos. - API: YouTube Data API v3 ## TikTok (In development) - Account type: Business and creator accounts - Formats: Video and photo posts - Notes: Awaiting API access from TikTok. Privacy and commercial-content disclosure will be chosen per post. - API: TikTok API for Business ## LinkedIn (In development) - Account type: Member profiles and Company Pages - Formats: Text, link, images, video, documents - Notes: Awaiting Community Management API approval from LinkedIn. - API: LinkedIn Posts API ## Our principles for every connection - Minimum permissions: only what's needed to publish and measure. - Access tokens encrypted in the database, and revoked at the network when an account is removed. - Respect for each network's rate limits and quotas, with delivery spread across accounts. - Publishing only to accounts the user manages and is authorized to post to. - Client connect links: the client signs in with the network themselves. No Shager account, no shared password. - Data deleted on request, including Meta's data-deletion callbacks. --- Source: https://shager.ai/en/networks # Building the distribution layer for the agent era. From Israel. Shager (שַׁגֵּר) is Hebrew for “dispatch”: sending something to the right place at the right time. That's the whole idea: one piece of content that reaches every account it should, and is measured in each one. Agencies today run tens or hundreds of Pages and accounts: clients with branches, franchise networks, brands with sub-brands. Most tools were built for one account or five, and know nothing about Hebrew, local holidays or the way clients actually approve content. The result is familiar: copy-paste into every Page, approvals over WhatsApp, and no way to tell which account brought the lead. Shager was built to close those three gaps (distribution, approval and measurement) in one place. And soon, the one doing this work won't be a person at all. AI agents already write, edit and plan campaigns. What they lack is a reliable way to distribute, by the rules, and to measure what worked. So we built Shager for agents to work with directly, with a person still the one who approves. ## What we don't compromise on - **Only through the front door:** Each network's official API, minimum permissions, and no tricks that put your clients' accounts at risk. - **Real numbers:** What we measure, we show. What we don't know, we don't invent, including on this website. - **Hebrew first:** A right-to-left interface, a Hebrew writing assistant and a holiday calendar covering every religion. Not a translation of a foreign product. English is fully supported too. - **Your data:** Hosted in the EU, tokens encrypted, deletion on request, and the option to run the whole system yourself. --- Source: https://shager.ai/en/about # Your agent already writes. Now it ships. Shager is distribution infrastructure that agents work with directly: an MCP server, a documented API, and a sign-up an agent can do on its own. The agent creates, schedules and measures, and a person approves before anything goes live. ## Three steps, no SDK. ### 1. The agent opens a sandbox One call returns an API key and a claim link. In the sandbox the agent can create clients, upload media, build drafts and previews, but not publish. ``` curl -X POST https://app.shager.ai/api/v1/agent/signup \ -H 'content-type: application/json' \ -d '{"agent_name":"Acme marketing agent", "contact_email":"owner@acme.com", "purpose":"Distribute weekly videos to 40 branch pages"}' ``` ```json { "data": { "api_key": "shgr_live_…", "claim_url": "https://app.shager.ai/claim/…", "sandbox": true, "mcp_url": "https://app.shager.ai/api/mcp", "expires_at": "…" } } ``` ### 2. Connect the MCP server Paste the config into Claude Desktop, Claude Code, Cursor or any MCP client. Or work directly against the REST API. ``` { "mcpServers": { "shager": { "url": "https://app.shager.ai/api/mcp", "headers": { "Authorization": "Bearer shgr_live_…" } } } } ``` ### 3. A person claims it, the agent ships The owner opens the claim link, signs in and connects the accounts (or sends the client a connect link). From then on, the agent schedules and publishes for real. ## What the agent can do - `whoami`: undefined - `list_workspaces`: List clients (workspaces) - `create_workspace`: Open a new client - `list_channels`: Connected accounts, by client or group - `create_connect_link`: A link the client uses to connect their own accounts - `list_groups`: Account groups - `create_group`: Create a group (branches, brands, campaign) - `upload_media_from_url`: Upload an image or video from a URL - `create_post`: One post for tens or hundreds of accounts, adapted per network - `schedule_post`: Schedule with staggered delivery across accounts - `request_approval`: An approval link for the client - `get_post`: Publishing status on every account, including errors - `list_posts`: The content calendar - `get_analytics`: Clicks and leads per account and per post - `cancel_post`: Cancel a schedule - `get_holidays`: undefined ## The agent executes. A person decides. - **Nothing goes live without a person:** A sandbox an agent opened stays in draft until a person claims it with the link. - **Scoped keys:** Every key belongs to one organization and can be revoked at any time. - **Rate and volume limits:** Per-account and daily publishing caps, and staggered delivery that respects network limits. - **Audit log:** Every agent action is recorded: who, what, when and with which key. - Live networks: Facebook (Pages), Instagram (professional accounts), YouTube. TikTok and LinkedIn are in development. - Publishing only through official APIs, and only to accounts the user manages and is authorized to post to. - Numbers on this site are illustrations unless stated otherwise. ## Machine-readable end to end - `/llms.txt`: A site map for agents: what Shager is and where each page lives. - `/llms-full.txt`: All public content in one Markdown file. - `/md/…`: A Markdown version of every page. Example: /md/en/pricing - `https://app.shager.ai/api/v1/openapi.json`: The full OpenAPI spec of the REST API. - `/sitemap.xml`: Every page in both languages, with hreflang links. ## What we're building next - **OAuth sign-in for MCP:** Sign in with your Shager account straight from the MCP client, with no key to copy. - **CLI:** A command line with device login, for scripts and CI pipelines. - **A billing link for your human:** The agent sends a person a checkout link, then works within a budget the person sets. --- Source: https://shager.ai/en/agents # Pay for accounts. Everything else is included. Start free with the accounts you already have, and add accounts one at a time as you grow. API, MCP server and unlimited users on every plan, including Free. 14-day trial on every paid plan, no card required. | Plan | Price / month | Accounts | Includes | |---|---|---|---| | Free | $0 (₪0 in Israel) | 3 | 3 accounts; 30 posts a month; API and MCP; 50 AI assistant credits | | Creator | $9 (₪29 in Israel) | 10 | 10 accounts; Unlimited posts; $1 per extra account; 150 AI assistant credits | | Pro | $19 (₪59 in Israel) | 25 | 25 accounts; UTMs and short links per account; $1 per extra account; 300 AI assistant credits | | Agency | $69 (₪209 in Israel) | 60 | 60 accounts; Client connect links; Client approval links; 1,000 AI assistant credits | | Agency+ | $129 (₪389 in Israel) | 150 | 150 accounts; Everything in Agency; 2,500 AI assistant credits; Priority support | | Scale | $299 (₪899 in Israel) | 500 | 500 accounts; $0.35 per extra account; 6,000 AI assistant credits; Higher API limits | | Network | Custom | 1,000+ | Per-account pricing; Dedicated server; SLA; Self-hosting | Prices in USD; in Israel, in ₪ before VAT (18%). Yearly billing: two months free. Media is kept for 90 days after publishing. ## What you never pay extra for - **API and MCP server:** Your agent connects from day one. No add-on, no developer plan. - **Unlimited users:** The whole team and every approving client. No per-seat pricing. - **Hebrew and English:** Right-to-left interface, a Hebrew writing assistant and a holiday calendar covering every religion, with English throughout. - **Hosted in the EU:** EU servers and encrypted tokens, at no extra cost. ## Agent posts included Every plan includes 50 agent-created posts a month per account (3,000 on Agency). Beyond that, $1 per 1,000 posts, with a cap you set. Reads and reports aren't counted. ## Pricing questions ### What counts as an account? Each connected Facebook Page, Instagram account or YouTube channel is one account. Paused accounts don't count. ### Why more accounts? Every extra account is another audience seeing the same content. Once you have made one post, sending it to ten accounts takes no more work from you. That is why Creator and Pro let you add one account at a time instead of jumping a plan. ### Do prices include VAT? In Israel, prices are in ₪ before 18% VAT and you get a tax invoice. Outside Israel, prices are in USD. ### Can we self-host? Yes. Community is free up to 10 accounts. An Agency license (up to 200 accounts) and an Unlimited license are available on request. ### What happens after the trial? Pick a plan or drop to Free. Nothing is deleted and nothing is charged, because we never asked for a card. ### Can we switch plans? Any time. Upgrades apply immediately and you pay only the prorated difference. --- Source: https://shager.ai/en/pricing # Contact Request access, book a demo or ask a question. Tell us how many accounts you manage and on which networks. - Email: yaniv.presler@gmail.com - Form: https://shager.ai/en/contact --- Source: https://shager.ai/en/contact # Blog: brand marketing, leads and distribution at scale Practical guides for agencies: one brand voice, per-account lead measurement, client approvals and posting at scale without getting blocked. - [From Client Brief to Published Posts: A Full Week Run by an Agent, Call by Call](https://shager.ai/en/blog/from-brief-to-published): A worked example of one client week through Shager: brief, media upload, per-account drafts, review, client approval, scheduling, delivery checks and reporting. - [How Should an AI Agent Handle Holidays When It Posts for Many Different Audiences?](https://shager.ai/en/blog/holiday-aware-posting-for-agents): How an AI agent should schedule around holidays: map each account to its traditions, call get_holidays, read calendar_notes and block the evening before. - [The Agent Content Pipeline, End to End: Brief In, Per-Account Posts Out, Clicks Back, With Every Shager Call in Order](https://shager.ai/en/blog/agent-content-pipeline-end-to-end): A full agent pipeline on Shager in TypeScript: brief, media, per-account captions, draft, client approval, staggered scheduling, delivery checks and clicks. - [First-Comment Lead Links With Agents: One Tracked Link per Account, Posted Right After the Post](https://shager.ai/en/blog/first-comment-lead-links-with-agents): How an agent uses Shager's first comment and per-account tracked links for leads: where links work on each network, which fields to set and how to measure it. - [Posting at Scale Without Getting Blocked: Pacing, Variety and Original Content](https://shager.ai/en/blog/avoid-spam-blocks-when-posting-at-scale): How agencies publish to dozens of accounts without restrictions: official APIs, staggered pacing, original content per account, and the networks' own rules. - [How to Choose a Distribution Platform for AI Agents: 12 Criteria](https://shager.ai/en/blog/choosing-a-distribution-platform-for-agents): Twelve criteria for choosing a social distribution platform an AI agent can run: MCP and API access, scoped keys, audit, per-account variation and pricing. - [Multilingual Content Agents: Localising for Hebrew, Arabic and English Accounts Without Translating](https://shager.ai/en/blog/multilingual-content-agents): Running content in several languages with AI agents: localisation versus translation, Hebrew and Arabic right-to-left pitfalls, and per-account captions. - [A Weekly Distribution Routine as a Claude Skill: Monday Drafts, Client Approvals, Friday Click Report](https://shager.ai/en/blog/skill-weekly-distribution-routine): A Claude Code skill that runs an agency week in Shager: drafts from plan files, client approvals, scheduling only what's approved, and a Friday click report. - [Making a Website Agent-Ready: llms.txt, Markdown Pages, OpenAPI, api-catalog and MCP Server Cards](https://shager.ai/en/blog/agent-ready-websites-llms-txt): What an agent-ready website publishes: llms.txt, Markdown page versions, OpenAPI, the RFC 9727 api-catalog and an MCP server card, with shager.ai as example. - [API Keys for Agents: Read, Write, Publish, and an Audit Trail You Will Actually Check](https://shager.ai/en/blog/api-keys-scopes-and-audit): Giving AI agents Shager API keys safely: what read, write and publish allow, the sandbox claim, key storage, rate limits, key rotation and the audit log. - [Build a Claude Skill for Shager: SKILL.md, Folder Layout and the Rules That Make Multi-Account Posting Repeatable](https://shager.ai/en/blog/build-a-claude-skill-for-shager): Package Shager distribution as a Claude Agent Skill: frontmatter that triggers well, reference files, a REST helper script, and where the skill should live. - [A Client Approval Workflow That Doesn't Stall Your Content Calendar](https://shager.ai/en/blog/client-approval-workflow-for-agencies): How agencies build client approvals that work: what needs sign-off, clear deadlines, approval links instead of email threads, and rules for silent clients. - [MCP Explained for Marketers: What It Is and Why Your Tools Need It](https://shager.ai/en/blog/mcp-explained-for-marketers): A plain-language guide to the Model Context Protocol for marketers: what MCP is, what servers and tools mean, how agents use them, and what to ask vendors. - [One Agent, Twelve Clients: Keeping Brands, Accounts and Links From Bleeding Into Each Other](https://shager.ai/en/blog/one-agent-many-clients): How an agency runs one AI agent across many clients in Shager: a workspace per client, per-client context folders, naming rules and guards against cross-posts. - [Per-Account Lead Attribution: UTMs, Short Links and the First Comment](https://shager.ai/en/blog/utm-per-account-lead-attribution): A practical guide to attributing leads to each page and profile: a consistent UTM scheme, one short link per account, first-comment links, and CRM handoff. - [The Weekly Client Report, Written by an Agent Every Monday Before You Wake Up](https://shager.ai/en/blog/weekly-client-report-by-agent): Build a weekly client report that an agent compiles from Shager: what was published, what failed, clicks per account and post, and how to join it to CRM leads. - [Client Connect Links: Access to Client Social Accounts Without Passwords](https://shager.ai/en/blog/client-connect-links): How agencies get publishing access to client Facebook, Instagram and YouTube accounts with a connect link: no shared passwords and no Shager account needed. - [Keeping One Brand Voice Across Dozens of Social Accounts](https://shager.ai/en/blog/brand-consistency-across-many-accounts): How agencies managing dozens of pages and profiles keep one consistent brand voice without duplicating posts: style guides, templates, groups and QA. - [Six Prompts That Make a Content Agent Safe to Run on Client Accounts](https://shager.ai/en/blog/prompts-for-a-content-agent): Copyable prompts for an AI content agent working through Shager: standing rules, weekly drafts, caption variation, scheduling, review and failure triage. - [Shager REST API Quickstart: From a Fresh Key to a Tracked Post on 40 Accounts in Seven Calls](https://shager.ai/en/blog/shager-rest-api-quickstart): A working tour of Shager's REST API in curl and TypeScript: auth, workspaces, channels, media, per-account drafts, scheduling, status checks and clicks. - [Scheduling Strategy for Agents: Time Zones, Staggering and Not Flooding Forty Pages at 9:00](https://shager.ai/en/blog/scheduling-strategy-for-agents): How an AI agent should schedule posts across many accounts: ISO 8601 offsets, time zones and DST, stagger math, splitting groups across days, and safe cancels. - [Caption Variation per Account: Letting AI Rewrite Without Losing the Brand](https://shager.ai/en/blog/caption-variation-per-account-with-ai): How an AI agent can write a different caption for every account in a campaign while claims, offer and voice stay fixed, using per_channel in one create_post. - [One Vertical Video, Forty Accounts: How an Agent Ships Reels and Shorts Through Shager](https://shager.ai/en/blog/agent-short-video-distribution): A hands-on playbook for agents distributing short video: format checks, Reels and Shorts metadata, per-account captions, staggered dispatch and real MCP calls. - [Agent Self-Signup: How an AI Agent Opens a Shager Sandbox in One Call, and Why a Human Still Holds the Publish Button](https://shager.ai/en/blog/agent-self-signup-and-claim): An agent can open its own Shager sandbox with one POST. Here is the call, what the sandbox allows, the human claim step, and how publish rights get granted. - [Safety Rules for AI Agents Posting to Hundreds of Accounts](https://shager.ai/en/blog/safety-rules-for-agents-posting-at-scale): A rulebook for AI agents publishing to many social accounts: official APIs, scoped keys, varied captions, staggered dispatch, network limits and a stop plan. - [Can ChatGPT Post Through Shager? What Works Today, What Waits for OAuth, and the Three Routes That Ship Now](https://shager.ai/en/blog/shager-and-chatgpt): ChatGPT's MCP connectors need OAuth or no auth, so Shager's API-key server can't plug in yet. Here are the routes that work today and what OAuth will change. - [Measuring Leads From Agent-Published Content, Account by Account](https://shager.ai/en/blog/measuring-leads-from-agent-content): How to tell whether agent-published posts produce leads: per-account short links and UTMs, campaign labels, get_analytics, CRM hidden fields and a weekly read. - [Add Shager to Cursor With .cursor/mcp.json: Turn Release Notes Into Drafts for Every Client Account](https://shager.ai/en/blog/connect-shager-to-cursor): Configure Shager's remote MCP server in Cursor with a url and an env-backed Authorization header, then turn a changelog into per-account social drafts. - [Human Approval for Agent-Written Posts: Where to Put the Gate](https://shager.ai/en/blog/human-approval-for-agent-posts): Where human approval belongs when an AI agent writes and schedules social posts: scoped keys, draft-first runs, client approval links and what reviewers check. - [Shager in OpenAI Codex: config.toml, bearer_token_env_var and a Tool Allowlist That Keeps Drafts as Drafts](https://shager.ai/en/blog/connect-shager-to-codex): Set up Shager's remote MCP server in Codex CLI via config.toml or codex mcp add, read the key from an env var, restrict tools, and create a first draft. - [The Agency Operating Model When AI Agents Handle Distribution](https://shager.ai/en/blog/agency-operating-model-with-agents): How a social agency restructures roles, weekly rhythm, client workspaces and API keys when AI agents do distribution and people own strategy and approval. - [Connecting Shager to Claude Desktop: Custom Connector With Request Headers, or the mcp-remote Route](https://shager.ai/en/blog/connect-shager-to-claude-desktop): Two working ways to connect Claude Desktop to Shager's API-key MCP server: a custom connector with request headers, or mcp-remote in the desktop config file. - [No Content, No Existence: Why Silent Brands Vanish When Agents Choose](https://shager.ai/en/blog/no-content-no-existence): When agents and answer engines decide what people see, they draw on what is published and findable. A brand that doesn't publish consistently isn't found. - [Connect Shager to Claude Code: One Command, Then Draft Posts for 50 Accounts From Your Terminal](https://shager.ai/en/blog/connect-shager-to-claude-code): Add Shager's remote MCP server to Claude Code with claude mcp add and a bearer header, pick the right scope, verify it, and draft a first multi-account post. - [Why AI Agents Should Run Social Distribution, and What Humans Should Keep](https://shager.ai/en/blog/why-agents-should-run-distribution): Distribution is repetitive, rule-bound work across many accounts, which makes it a natural job for AI agents. Here is what to hand over and what humans keep. --- Source: https://shager.ai/en/blog # From Client Brief to Published Posts: A Full Week Run by an Agent, Call by Call _2026-10-13 · A worked example of one client week through Shager: brief, media upload, per-account drafts, review, client approval, scheduling, delivery checks and reporting._ Getting from a client brief to published posts with an agent takes eight stages: confirm access and the workspace, check the connected accounts, upload media, plan, draft with per-account captions, review, get client approval, then schedule and verify. The agent does the volume work in every stage. A human makes three decisions: approving the plan, granting the right to publish, and, where the client wants it, the client's own sign-off through an approval link. What follows is one realistic week for a fictional client, with every Shager call the agent makes, in order. The client, Harbor Coffee, has 14 cafes, each with a Facebook Page and an Instagram professional account, plus one YouTube channel for the brand. ## Monday morning: the brief arrives The account manager drops a brief into the client's context folder: a new autumn drink, a launch on Thursday, a 20 percent discount for the first weekend, a 25 second vertical video and two photos hosted on the client's CDN. Nothing else. The agent's standing instructions forbid it from inventing anything the brief does not say, so the discount, the date and the product name are the only facts it will use. The session starts inside the client's folder, so the agent has the agency rules and Harbor Coffee's voice file loaded, and nothing about other clients. Why that matters is covered in [one agent, many clients](/en/blog/one-agent-many-clients). ## Stage 1: confirm who and where ```text whoami -> organization, claimed or sandbox, key scopes list_workspaces -> "Harbor Coffee" (ws_harbor), timezone Europe/London ``` `whoami` answers two questions before any work: is this organization claimed, and does the key have `publish`? If it is an unclaimed sandbox, the agent can still upload and draft, but scheduling and approval requests will fail with a clear error until a human claims it. The claim process is described in [/auth.md](/auth.md). ## Stage 2: check the accounts ```text list_channels ws_harbor -> 29 channels: 14 Facebook, 14 Instagram, 1 YouTube list_groups ws_harbor -> "All cafes FB", "All cafes IG", "Brand YouTube" ``` The agent looks at each channel's status. One Instagram account shows as disconnected. Rather than drafting around it silently, the agent creates a connect link for that cafe's manager: ```json { "tool": "create_connect_link", "arguments": { "workspace_id": "ws_harbor", "label": "Harbor Quayside, Instagram reconnect" } } ``` The account manager forwards the link. The cafe manager signs in to Instagram through it, without a Shager account, and the account returns to `list_channels` later that day. ## Stage 3: upload media Three calls, one per asset. The video carries its dimensions and duration so Reels and Shorts validation can run now rather than at publish time. ```json { "tool": "upload_media_from_url", "arguments": { "workspace_id": "ws_harbor", "url": "https://cdn.harbor-coffee.example/autumn/launch.mp4", "file_name": "autumn-launch.mp4", "width": 1080, "height": 1920, "duration_ms": 25000 } } ``` The two photos go up the same way, without the video fields. ## Stage 4: plan, then wait The agent proposes a plan instead of drafting immediately: | Day | Post | Format | Target | |---|---|---|---| | Tue | Teaser photo | FEED | All cafes FB, All cafes IG | | Thu | Launch video | REEL / SHORT | All cafes FB, All cafes IG, Brand YouTube | | Sat | Discount reminder photo | FEED | All cafes FB, All cafes IG | The account manager replies "go", moving the Saturday post to Friday afternoon. One message, and a weak plan never turns into 85 per-account captions. ## Stage 5: draft with per-account captions Each planned post becomes one `create_post` call without `schedule_at`, which saves a draft. The launch post shows the full shape: ```json { "tool": "create_post", "arguments": { "workspace_id": "ws_harbor", "group_ids": ["grp_all_fb", "grp_all_ig", "grp_brand_yt"], "media_ids": ["med_launch"], "caption": "The autumn drink is here. 20% off this weekend.", "youtube_title": "Harbor Coffee autumn drink, first pour", "youtube_privacy": "public", "cta_url": "https://harbor-coffee.example/autumn", "campaign": "autumn-launch", "label": "Harbor autumn launch video", "first_comment": "Find your nearest Harbor and the weekend offer: https://harbor-coffee.example/autumn", "per_channel": [ { "channel_id": "ch_fb_quayside", "format": "REEL", "caption": "Quayside regulars, it's here. Autumn's first pour, 20% off this weekend." }, { "channel_id": "ch_ig_quayside", "format": "REEL", "caption": "First pour at Quayside. 20% off all weekend, details in bio." }, { "channel_id": "ch_yt_brand", "format": "SHORT", "caption": "The new Harbor autumn drink, poured for the first time." } ] } } ``` In the real call `per_channel` has 29 entries, each caption anchored in that cafe. Every URL in the captions and comments becomes a short link unique to that account at publish time, with `utm_content` identifying the account, so the agent writes plain URLs. The craft of varying captions is in [caption variation per account with AI](/en/blog/caption-variation-per-account-with-ai). ## Stage 6: review in a separate pass A second session, running a reviewer prompt with read-only tools, calls `list_posts` with `status` set to `DRAFT` and `get_post` on each. It checks for duplicate captions, facts not in the brief, links placed where they will not be clickable, and video formats on non-vertical media. This time it flags two Instagram captions that say "link below" when the link is in the bio. The drafting agent fixes them by creating corrected drafts, and the old ones are left out of scheduling. ## Stage 7: client approval Harbor Coffee's workspace has `approval_required` set, so nothing can be scheduled until the client approves. The agent sends each draft for approval: ```json { "tool": "request_approval", "arguments": { "workspace_id": "ws_harbor", "post_id": "pst_launch", "reviewer_name": "Dana, Harbor Coffee marketing", "reviewer_email": "dana@harbor-coffee.example", "send_email": true } } ``` The client opens the link, reviews the post, and approves without logging in. The post's status moves through `IN_REVIEW` to `APPROVED`, or to `CHANGES_REQUESTED`, in which case the agent revises and resubmits. The design of good approval rules is covered in [human approval for agent posts](/en/blog/human-approval-for-agent-posts). ## Stage 8: schedule and verify Once approved, the scheduling step runs with a key that has the `publish` scope. The agent computes each time in the workspace zone, with the offset for that date: ```json { "tool": "schedule_post", "arguments": { "workspace_id": "ws_harbor", "post_id": "pst_launch", "schedule_at": "2026-10-15T08:30:00+01:00" } } ``` With 14 accounts on each of Facebook and Instagram and the default stagger of 30 to 90 seconds, each network's run takes roughly 13 minutes, and the two networks run in parallel. On Thursday at 9:15 the agent calls `get_post`. Twenty-eight accounts show as published with live URLs. One shows a permission error. The agent reports the account by name and suggests a fresh connect link; it does not retry blindly. ## The following Monday: the report The same week closes with the report: `list_posts` for what went out, `get_post` for per-account outcomes, and `get_analytics` for clicks per account and per post across the week, joined to CRM leads on `utm_content` when the client shares them. The full setup, including running it unattended, is in [the weekly client report by agent](/en/blog/weekly-client-report-by-agent). ## Who did what | Stage | Agent | Human | |---|---|---| | Access and workspace | Checks and states it | | | Accounts | Finds the broken one, creates the link | Forwards the link | | Media and plan | Uploads, proposes | Says "go" | | Drafts and review | Writes 85 captions, reviews them | | | Approval | Sends the links | Client approves | | Scheduling | Computes times, schedules | Granted `publish` once | | Delivery and report | Verifies, reports | Reads the report | ## FAQ ### How long does a week like this take a human? The human decisions in this example are a few messages and one approval. The exact time depends on the client and how much back and forth the plan needs. What changes is the kind of work: reviewing and deciding instead of typing captions and building links. ### Can the agent skip client approval for routine posts? Only if the workspace does not require it. `approval_required` is set per workspace, so a client who signs off on a monthly plan can have it off, while a cautious client keeps it on. The agent cannot change that setting for an existing workspace on its own. ### What if the client requests changes after approval? If the post has not started publishing, the agent calls `cancel_post`, which returns it to an approved draft, then creates a corrected version and sends it for approval again. Once publishing has started, changes on the networks themselves are a manual job. ## Where to go next Run this sequence on one client with a small group of accounts before you point it at everything. If your agent is not connected yet, the [agent entry point](/en/agents) covers the MCP server, the REST API and self-signup. --- Source: https://shager.ai/en/blog/from-brief-to-published # How Should an AI Agent Handle Holidays When It Posts for Many Different Audiences? _2026-10-13 · How an AI agent should schedule around holidays: map each account to its traditions, call get_holidays, read calendar_notes and block the evening before._ An agent that posts for many accounts should check every scheduled time against the holidays of each account's audience, not against one national calendar. In Shager that means two checks: call `get_holidays` for the traditions that matter before planning, then read the `calendar_notes` that come back on every scheduled post. The part no tool can do for the agent is deciding which traditions apply to which account, so that has to be written down per client. ## The calendar is easy. The mapping is the hard part. Most holiday mistakes come from assuming every audience shares one calendar, not from missing data. Picture an agency running these accounts from one workspace: 1. A family restaurant in a Druze village in the Galilee. 2. A chain of dental clinics whose patients are mostly Arab citizens of Israel. 3. A housewares shop selling to a Haredi audience. 4. A community center for Russian speakers, where part of the audience follows the Orthodox church calendar. 5. An e-commerce brand that ships to Europe and North America. A cheerful discount post on a Tuesday can be fine for four of them and badly timed for the fifth. An agent knows only what is in its instructions. So before any of the tooling below helps, each client profile needs one explicit line: the traditions this audience observes. If you already run [one agent across many clients](/en/blog/one-agent-many-clients), that profile is where it belongs. ## What does Shager's holiday calendar cover? The calendar includes Jewish and Israeli, Muslim, Western Christian, Orthodox Christian, Druze, Bahá'í, Hindu, Buddhist, Sikh, Jain, Chinese and Persian holidays. It also includes international and commercial days: Valentine's Day, International Women's Day, US Mother's Day and Father's Day, Halloween, Singles' Day, Thanksgiving, Black Friday, Cyber Monday and New Year. Every day carries one of four pieces of posting advice: | Advice | What the agent should do | Examples | | --- | --- | --- | | `avoid` | No promotional content to that audience | Yom Kippur; Holocaust Remembrance Day and Memorial Day in Israel | | `sensitive` | Respectful content only, no hard sell, no jokes | Fast days, Good Friday, Ashura, Day of Arafah, Laylat al-Qadr | | `opportunity` | A greeting or a themed post fits | Eid al-Fitr, Christmas, Diwali, Lunar New Year, Black Friday | | `normal` | Nothing to change | Everything else | The app's calendar shows the same data to humans, with a tradition filter and a colour per advice. ## Calling get_holidays It is exposed as the MCP tool `get_holidays` and as a REST operation documented in the [OpenAPI spec](https://app.shager.ai/api/v1/openapi.json): ```bash curl -s "https://app.shager.ai/api/v1/holidays?from=2026-11-20&to=2026-12-05&traditions=jewish,muslim&language=en" \ -H "Authorization: Bearer $SHAGER_API_KEY" ``` Without `from` and `to`, the range is today plus 60 days. The maximum is 400 days. `traditions` filters to the ones you name, and `language` returns names in English or Hebrew. The response has this shape: ```json { "data": { "from": "2026-11-20", "to": "2026-12-05", "note": "...", "holidays": [ { "date": "YYYY-MM-DD", "tradition": "...", "name": "...", "key": "...", "advice": "opportunity", "guidance": "...", "approximate": true } ] } } ``` Pass `guidance` on to the human reviewer; it explains in one sentence why a post moved. ## The call sequence, end to end Here is the order I use for a weekly run. Take late November 2026 as the example: Thanksgiving falls on Thursday the 26th, Black Friday on the 27th and Cyber Monday on the 30th. For the e-commerce brand, that is a run of `opportunity` days. For the Haredi shop or the Druze restaurant, those days may simply be `normal` and not worth a themed post at all. ```text get_holidays { from: "2026-11-20", to: "2026-12-05", traditions: } create_post { workspace_id: "ws_retail", channel_ids: ["ch_shop_eu_ig", "ch_shop_us_fb"], caption: "...", per_channel: [ { channel_id: "ch_shop_eu_ig", caption: "..." }, { channel_id: "ch_shop_us_fb", caption: "..." } ], media_ids: ["med_19ae"] } schedule_post { workspace_id: "ws_retail", post_id: "pst_5d2c", schedule_at: "2026-11-27T09:00:00-05:00" } read calendar_notes on the returned post if any entry is avoid or sensitive for a tradition in this account's profile: cancel_post, pick a new time, schedule again, and log why ``` First, `per_channel` lets one post carry a different caption per account, so the US page can mention Thanksgiving weekend while the EU page talks about Black Friday without the American framing. I wrote more about that in [caption variation per account](/en/blog/caption-variation-per-account-with-ai). Second, a post has a single schedule time. When two audiences in the same group disagree about a day, captions cannot fix it. Split them into separate posts with separate times. `calendar_notes` comes back on every post returned by `create_post`, `get_post` and `schedule_post`, listing the holidays on that post's scheduled day with their advice. It catches what planning missed, including a time someone changed by hand. ## Why "begins the evening before" breaks naive date checks Jewish holidays start at sundown on the evening before the date a calendar shows. The [Reform movement's explanation](https://reformjudaism.org/learning/answers-jewish-questions/why-do-jewish-holidays-begin-night) traces this to the creation story, where evening comes before morning. The Islamic day also begins at sunset. An agent that compares dates only will get this wrong in a predictable way. The calendar lists Yom Kippur on one date. The agent checks a promo scheduled for 19:00 on the previous date, sees no match, and publishes into the start of the fast. In Israel the stakes are higher on the two memorial days. Memorial Day for fallen soldiers begins at sunset the night before, and [places of entertainment are closed by law](https://www.jewishvirtuallibrary.org/yom-hazikaron-israeli-memorial-day) during the day. On Holocaust Remembrance Day, [places of public entertainment are closed by law](https://en.wikipedia.org/wiki/Yom_HaShoah) on the eve and on the day itself. A brand posting a playful sale that evening breaks no law, but the audience notices. My rule in agent instructions is simple: for `avoid` and `sensitive` days, the afternoon and evening of the day before count as part of the day. For `opportunity` days, the evening start helps you, because a greeting that lands before the holiday begins arrives on time. ## Why are Islamic dates marked approximate? Shager computes Islamic dates from the Umm al-Qura calendar and marks them `approximate: true`. Umm al-Qura is Saudi Arabia's official calendar and is calculated in advance, while the start of the religious months depends on sighting the crescent moon. [The New Arab quotes the calendar's own former website](https://www.newarab.com/news/will-saudi-arabia-announce-wrong-date-ramadan) saying it may not match actual crescent visibility. Countries also apply different sighting criteria, so [Eid can fall on different days in different countries](https://www.aljazeera.com/news/2023/3/16/infographic-when-is-ramadan-2023). The drift is about one day. For the clinic chain, that means: prepare the Eid al-Fitr greeting as a draft early and schedule it after the local announcement, or write it so it still reads well a day early. For an approximate `sensitive` day, leave a buffer day on each side. For audiences spread across countries, do not assume one date fits all of them. ## A prompt you can adapt ```text Before scheduling anything this week: 1. Read each client's audience profile and list its traditions. If a profile has none, stop and ask me. 2. Call get_holidays once for the whole week, with the union of those traditions. 3. avoid: no promotional posts to that audience, including the afternoon and evening before. 4. sensitive: respectful tone only. No discounts, no humour, no countdowns. 5. opportunity: propose a greeting or themed post, written separately per account with per_channel. 6. approximate=true: keep a one day buffer, or wait for the local announcement. 7. After schedule_post, read calendar_notes. On a conflict, cancel, reschedule and tell me what changed. ``` Pair it with the timing rules from [scheduling strategy for agents](/en/blog/scheduling-strategy-for-agents), so offsets and holidays are handled in the same pass. ## Checklist before every scheduled run 1. Every account has an audience profile with an explicit list of traditions. 2. One `get_holidays` call covers the full date range of the run. 3. An `avoid` day also blocks the evening before it. 4. A `sensitive` day changes the tone, not only the time. 5. `opportunity` posts are written per audience, never one generic greeting for all. 6. Approximate dates get a buffer day. 7. Mixed audiences on a contested day are split into separate posts. 8. After scheduling, the agent reads `calendar_notes` and reports every change it made. Weekly rest days such as Shabbat are a fixed rule rather than a calendar entry, so put them in the audience profile as blocked time windows. If your agent is not connected yet, the [agent entry point](/en/agents) walks through setup. Once it is, the first useful job is small: add the traditions line to every client profile and run `get_holidays` across the next two months to see what is coming. ## FAQ ### Does Shager block scheduling on an avoid day? No. The advice is information, returned by `get_holidays` and in each post's `calendar_notes`. The decision stays with the agent and whoever approves its work, because the same day can be solemn for one audience and ordinary for another. ### How does the agent know which traditions apply to an account? It should not guess from a business name or a city. Write the traditions into each client's audience profile and instruct the agent to stop and ask when that line is missing. ### Should a global e-commerce brand care about religious holidays at all? Yes, mostly for its larger markets. Group its accounts by market, check each group against the commercial days plus the traditions common in that market, and write greetings per group. A Christmas post is an opportunity in one market and irrelevant or awkward in another. --- Source: https://shager.ai/en/blog/holiday-aware-posting-for-agents # The Agent Content Pipeline, End to End: Brief In, Per-Account Posts Out, Clicks Back, With Every Shager Call in Order _2026-10-11 · A full agent pipeline on Shager in TypeScript: brief, media, per-account captions, draft, client approval, staggered scheduling, delivery checks and clicks._ An end-to-end agent content pipeline on Shager has eight stages: read the brief, prepare media at a public URL, resolve the target accounts, write one caption per account, create a draft with a tracked link, get approval, schedule with staggered dispatch, then verify delivery and pull clicks per account. The agent owns the repetitive stages; a human owns the brief and the approval. Every Shager step is one REST call or one MCP tool with the same name. Below is the whole chain as a single TypeScript program against the REST API, with the reasoning for each stage. If you prefer to drive it from an agent client, the tool calls are identical. ## What are the stages, and who owns each? | Stage | Owner | Shager call | |---|---|---| | 1. Brief | Human | None | | 2. Media | Agent or your asset pipeline | `upload_media_from_url` | | 3. Targets | Agent | `list_channels`, `list_groups` | | 4. Captions | Agent (your model) | None | | 5. Draft | Agent | `create_post` | | 6. Approval | Client | `request_approval` | | 7. Schedule | Agent with `publish`, or human | `schedule_post` | | 8. Verify and measure | Agent | `get_post`, `get_analytics` | Stage 4 is the only one that needs a language model. Everything else is deterministic plumbing, and should be written as code rather than left to the model's improvisation. That split is the biggest reliability lesson in agent distribution: let the model write, let code orchestrate. ## Stage 1: what goes in the brief? A brief the pipeline can act on has eight fields. Anything less and the agent starts guessing. ```typescript type Brief = { workspace: string; // "Cedar Clinics" group: string; // "All clinics" message: string; // the facts, written by a human mediaUrl: string; // public URL of the finished asset media: { width: number; height: number; durationMs?: number }; link: string; // landing page to track campaign: string; // "flu-shots-2026" publishAt: string; // "2026-10-27T08:00:00-05:00" }; ``` `publishAt` carries an offset on purpose. Shager requires ISO 8601 with an offset for `schedule_at`, and writing the offset in the brief means nobody has to remember which timezone "8am" meant. ## Setup: one helper for every call ```typescript const API = "https://app.shager.ai/api/v1"; class ShagerError extends Error { constructor(public status: number, public code: string, message: string) { super(`${status} ${code}: ${message}`); } } async function shager(method: string, path: string, body?: unknown): Promise { for (let attempt = 0; attempt < 3; attempt++) { const res = await fetch(`${API}${path}`, { method, headers: { Authorization: `Bearer ${process.env.SHAGER_API_KEY}`, "Content-Type": "application/json", }, body: body ? JSON.stringify(body) : undefined, }); const json = await res.json(); if (res.ok) return json.data as T; if (res.status === 429) { await new Promise((r) => setTimeout(r, 60_000)); continue; } throw new ShagerError(res.status, json.error.code, json.error.message); } throw new Error("Rate limited three times in a row"); } ``` Only 429 is retried. A 403 or 422 is information, and retrying it just repeats the same refusal. The limit is 120 requests per minute per key, which this pipeline won't approach because one `create_post` covers every account. ## Stage 2: media Shager imports media from a URL, so whatever produced the asset (an editor, a render job, a generation tool) only needs to leave it somewhere publicly reachable. ```typescript const workspaces = await shager>("GET", "/workspaces"); const ws = workspaces.find((w) => w.name === brief.workspace); if (!ws) throw new Error(`No workspace named ${brief.workspace}`); const media = await shager<{ id: string; kind: string }>("POST", `/workspaces/${ws.id}/media`, { url: brief.mediaUrl, width: brief.media.width, height: brief.media.height, duration_ms: brief.media.durationMs, }); ``` Width, height and duration matter for vertical video. With them, Shager validates Reels, Shorts and Stories against each network's rules before scheduling, so a clip that's too long for a format fails now with a readable reason instead of failing on one network at dispatch time. ## Stage 3: resolve targets ```typescript type Channel = { id: string; network: string; name: string; status: string; formats: string[] }; const groups = await shager>( "GET", `/workspaces/${ws.id}/groups`, ); const group = groups.find((g) => g.name === brief.group); if (!group) throw new Error(`No group named ${brief.group}`); const channels = (await shager("GET", `/workspaces/${ws.id}/channels`)) .filter((c) => group.channel_ids.includes(c.id) && c.status === "ACTIVE"); ``` Filtering to `ACTIVE` here lets you report disconnected accounts up front. A page whose token expired is a conversation with the client, not something to discover after the post fails. ## Stage 4: one caption per account This is where your model earns its place. The function below is deliberately a stub; plug in whichever model and SDK your team uses. ```typescript async function writeCaptions(brief: Brief, channels: Channel[]): Promise> { // Prompt your model with: the brief's facts, each channel's name and network, // and these rules: keep facts identical, vary the opening and structure, // use the local detail in the channel name, no raw URLs, network-appropriate length. // Return channel_id -> caption, and validate that every channel got one. throw new Error("connect your model here"); } const captions = await writeCaptions(brief, channels); ``` Two rules belong in that prompt every time. Same facts everywhere, because a price or date that drifts between pages is a real error. And no raw links, because the link is attached separately so each account gets its own tracked version. Our guide on [brand consistency across many accounts](/en/blog/brand-consistency-across-many-accounts) covers where variation helps and where it hurts. ## Stage 5: create the draft ```typescript type PostView = { id: string; status: string; destinations: Array<{ channel_id: string; account: string; network: string; format: string; state: string; url: string | null; error: string | null }>; }; const draft = await shager("POST", `/workspaces/${ws.id}/posts`, { label: `${brief.campaign} ${brief.publishAt.slice(0, 10)}`, caption: brief.message, channel_ids: channels.map((c) => c.id), media_ids: [media.id], per_channel: channels.map((c) => ({ channel_id: c.id, caption: captions.get(c.id)! })), cta_url: brief.link, campaign: brief.campaign, first_comment: `Details: ${brief.link}`, stagger_seconds: [30, 90], }); ``` `cta_url` gives every account its own short link with `utm_content` identifying the account. `first_comment` is posted right after each post goes live. `stagger_seconds` spaces accounts on the same network by a random 30 to 90 seconds, which is also the default. The result is a `DRAFT`. ## Stage 6: approval ```typescript const approval = await shager<{ approval_url: string; emailed: boolean }>( "POST", `/workspaces/${ws.id}/posts/${draft.id}/approval`, { reviewer_name: "Priya Shah", reviewer_email: "priya@cedarclinics.example", send_email: true }, ); console.log("Approval link:", approval.approval_url); ``` The reviewer opens the link and approves without logging in. The pipeline stops here and resumes later; approval takes hours, not milliseconds. Persist `draft.id` and pick it up in a second run that checks `get_post` for `APPROVED`. If you want to know why this checkpoint sits after drafting and not after publishing, [client approval workflows](/en/blog/client-approval-workflow-for-agencies) makes the case. ## Stage 7: schedule ```typescript const post = await shager("GET", `/workspaces/${ws.id}/posts/${draft.id}`); if (post.status !== "APPROVED") { console.log(`Not approved yet: ${post.status}`); } else { try { await shager("POST", `/workspaces/${ws.id}/posts/${draft.id}/schedule`, { schedule_at: brief.publishAt, }); } catch (e) { if (e instanceof ShagerError && e.code === "rejected") { console.error("A network rule failed:", e.message); // fix input, do not loop } else throw e; } } ``` This needs a key with the `publish` scope, granted by a human at https://app.shager.ai/dashboard/agents. Shager validates every destination against its network's rules here, so a 422 `rejected` arrives before anything is queued. ## Stage 8: verify delivery and measure After the publish time, check each destination. Delivery states are `PENDING`, `QUEUED`, `PROCESSING`, `PUBLISHED`, `FAILED` and `SKIPPED`. ```typescript const after = await shager("GET", `/workspaces/${ws.id}/posts/${draft.id}`); for (const d of after.destinations) { if (d.state === "FAILED" || d.state === "SKIPPED") console.warn(d.account, d.state, d.error); } const stats = await shager<{ total_clicks: number; by_account: Array<{ account: string; network: string; clicks: number }> }>( "GET", `/workspaces/${ws.id}/analytics?from=2026-10-27T00:00:00-05:00&to=2026-11-03T00:00:00-05:00`, ); console.table(stats.by_account); ``` Clicks per account are the end of Shager's part and the start of the client's. Joining them to leads through `utm_content` in the CRM is covered in [per-account lead attribution](/en/blog/utm-per-account-lead-attribution). ## FAQ ### Should an agent client run this, or a script? Both work. A script is better for the fixed stages and anything on a timer. An agent client such as Claude Code is better when the brief is fuzzy and you want to iterate on captions interactively. Many teams use the agent for stage 4 and code for everything else. ### What if the brief targets accounts across several clients? Run the pipeline once per workspace. Workspaces separate clients deliberately: their accounts, approvals, links and analytics never mix, which is also what the client expects when they read their report. ### Where do I find the exact field definitions? In the [OpenAPI document](https://app.shager.ai/api/v1/openapi.json), which lists every operation, input and scope. The [agents page](/en/agents) has the same information in a shorter form for agents and their builders. ## Next step Run the pipeline once with a single test account and a draft you never schedule. Read the draft in Shager, check the per-account links, then widen to the full group. Once that holds, wrap the stages in [a weekly routine](/en/blog/skill-weekly-distribution-routine) so the pipeline runs on a schedule instead of on someone's memory. --- Source: https://shager.ai/en/blog/agent-content-pipeline-end-to-end # First-Comment Lead Links With Agents: One Tracked Link per Account, Posted Right After the Post _2026-10-09 · How an agent uses Shager's first comment and per-account tracked links for leads: where links work on each network, which fields to set and how to measure it._ To run first-comment lead links with an agent, set `first_comment` on the post (or per account in `per_channel`) and include the landing page URL in it. Shager publishes the post, adds the comment right after it as the account, and replaces every URL in the caption and comment with a short link unique to that account, tagged with UTM parameters where `utm_content` identifies the account. The agent's job is to write a comment worth clicking and to know where links actually work. That last part decides whether the whole exercise produces leads or decorative text. ## Where does a link in a comment actually work? The networks treat links differently, and an agent applying one rule everywhere wastes half its effort. | Network | Link in caption | Link in first comment | |---|---|---| | Facebook Pages | Clickable | Clickable | | Instagram | Not clickable | Not clickable | | YouTube long-form video | Clickable in the description | Clickable | | YouTube Shorts | Not clickable | Not clickable | For Shorts, Google's help center states plainly that [URLs in Shorts comments and Shorts descriptions are non-clickable](https://support.google.com/youtube/answer/13748639), as a measure against spam and scams. Instagram does not turn URLs in captions or comments into links either, which is why bio links and Story link stickers exist. So the first comment is a lead tool mainly on Facebook Pages and long-form YouTube. On Instagram and Shorts it can still carry a short, typeable address or a "link in bio" pointer, but do not count on clicks from it. On Facebook, a comment by the Page on its own post is a standard Graph API operation: Meta's Pages API documents [creating comments](https://developers.facebook.com/docs/pages-api/comments-mentions) with a POST to the object's comments edge, and the comment's author is the Page. That is what Shager does on your behalf after each account's post goes live, so the agent never needs to time a second call. ## The fields the agent sets Four fields in `create_post` do the work. 1. **`first_comment`**: the post-wide comment, used for every account that does not have its own. 2. **`per_channel[].first_comment`**: a comment for one specific account. It overrides the post-wide one for that account. 3. **`cta_url`** and **`cta_text`**: the link to track, with an optional call to action. If the URL is not already in the caption or the comment, Shager places it for you: appended to the caption on networks where caption links work, and moved into the first comment on Instagram if no comment was set. 4. **`campaign`**: becomes `utm_campaign` on every tracked link in the post. The key behaviour: every URL found in the caption or the first comment is swapped for a tracked short link specific to that account. Forty Pages, forty different short links, all pointing to the same landing page with UTM tags that say which Page sent the visitor. Nobody builds these by hand. The UTM convention behind this is covered in [per-account lead attribution](/en/blog/utm-per-account-lead-attribution). ## A worked example A clinic chain with 24 Facebook Pages and 6 Instagram accounts runs an open day. The agent drafts one post with a per-account caption and a first comment that is also varied, because thirty identical comments are as conspicuous as thirty identical captions. ```json { "tool": "create_post", "arguments": { "workspace_id": "ws_example", "group_ids": ["grp_clinics_all"], "caption": "Open day on Friday: free check-ups, no appointment needed.", "media_ids": ["med_openday"], "cta_url": "https://beacon-dental.example/open-day", "campaign": "open-day-oct", "first_comment": "Register for a time slot here: https://beacon-dental.example/open-day", "per_channel": [ { "channel_id": "ch_fb_riverside", "caption": "Riverside clinic opens its doors on Friday. Free check-ups all day.", "first_comment": "Pick a slot at Riverside before they go: https://beacon-dental.example/open-day" }, { "channel_id": "ch_ig_riverside", "caption": "Friday at Riverside: free check-ups, no appointment. Link in our bio.", "first_comment": "Slots are limited. The registration link is in our bio." } ], "label": "Open day Oct, all clinics" } } ``` A few choices in that payload are deliberate. The Instagram caption points to the bio, because that is where the click can happen. Its own `first_comment` replaces the post-wide one, so Instagram followers get a pointer to the bio instead of a URL they cannot tap. And the Facebook comment names the branch, which reads like a person wrote it. After publishing, the agent checks the run with `get_post` and, a few days later, reads clicks with `get_analytics` for the post's date range. Clicks come back per account and per post, so you can see that Riverside's comment link drew clicks and another branch's did not. ## Writing comments people click The agent will write whatever you ask for, so ask for the right thing. 1. **One link, one action.** "Register for a slot" beats "Learn more, register, or call us." 2. **Specific to the account.** Mention the branch, the city, the team. It is also the cheapest form of per-account variation. 3. **No repetition of the caption.** The comment answers "what do I do now?", not "what is this?". 4. **Short.** On mobile, a long comment is collapsed and the link may be below the fold. Put these into the standing instructions; a ready-made block is in [prompts for a content agent](/en/blog/prompts-for-a-content-agent). ## Does a link in the first comment get more reach than a link in the caption? No network has published an official statement saying it does. The idea is widespread, and some pages are convinced by their own experience, but treat it as a hypothesis for your audience, not a rule. Agents make the test cheap. Split the client's accounts into two groups with `create_group`. Send the same content to both, with the link in the caption for one group and in the first comment for the other. Give each post its own `label` and a `campaign` value that marks the variant. After a few rounds, compare clicks per account from `get_analytics`, and leads from the CRM matched on `utm_content`. Then keep whichever works, for that client. ## Doing it over REST From a script, the same post is a single call: ```bash curl -s https://app.shager.ai/api/v1/workspaces/ws_example/posts \ -H "Authorization: Bearer $SHAGER_API_KEY" \ -H "Content-Type: application/json" \ -d @open-day-post.json ``` And the click data afterwards: ```bash curl -s "https://app.shager.ai/api/v1/workspaces/ws_example/analytics?from=2026-10-01T00:00:00Z&to=2026-10-08T00:00:00Z" \ -H "Authorization: Bearer $SHAGER_API_KEY" ``` Every operation and field is documented in the [OpenAPI document](https://app.shager.ai/api/v1/openapi.json). ## From click to lead Clicks prove interest. Leads prove value. The landing page form should capture the UTM values into hidden fields so each lead in the CRM carries `utm_content`, the account identifier. With that in place, the agent's weekly report can show leads per Page, not just clicks. [Measuring leads from agent content](/en/blog/measuring-leads-from-agent-content) covers that join end to end. ## FAQ ### Can the first comment be different for every account? Yes. Set `first_comment` inside each `per_channel` entry. Accounts without their own comment use the post-wide `first_comment`, so set one per account wherever the wording should change. ### Does the agent need to create the short links? No. Shager replaces every URL in the caption and first comment with a tracked short link unique to that account, with UTM tags, at publish time. The agent writes the plain landing page URL. ### What if the network does not support a first comment? Shager checks each post against each network's rules before sending, and a network without first comment support is flagged at that stage rather than failing silently. Facebook, Instagram and YouTube, the networks live today, all accept a first comment. ## Where to go next Pick one client with Facebook Pages, add a first comment with the landing page URL to next week's posts, and read clicks per account after seven days. The [agent entry point](/en/agents) has the connection details if your agent is not set up yet. --- Source: https://shager.ai/en/blog/first-comment-lead-links-with-agents # Posting at Scale Without Getting Blocked: Pacing, Variety and Original Content _2026-10-07 · How agencies publish to dozens of accounts without restrictions: official APIs, staggered pacing, original content per account, and the networks' own rules._ If you manage dozens of accounts, you know the scenario. A campaign goes out to every page, and a few hours later there's a restriction notice, posts that vanished from the feed, or an account asking for verification. The first instinct is usually to look for a trick to get around the system. That instinct is exactly what leads to the next block. The networks aren't fighting agencies. They're fighting spam, inauthentic behavior and duplicated content, and high-volume publishing can look similar from the outside. This article is about looking like, and being, what you actually are: a business publishing legitimate content on behalf of real clients. ## What the networks call spam Before talking about pacing and tools, read the rules themselves. Meta lays out restricted behavior in its [Community Standards on spam](https://transparency.meta.com/policies/community-standards/spam/), and YouTube explains what counts as spammy or misleading in its [spam, deceptive practices and scams policies](https://support.google.com/youtube/answer/2801973). These documents change from time to time, so revisit them before a large campaign. The common thread across most of them: 1. **Identical or near-identical content distributed repeatedly**, across many accounts or within one 2. **Artificially driven engagement**: likes, comments or shares that don't come from genuine interest 3. **Misleading destinations**: links that lead somewhere other than what the post promises 4. **Automation outside permitted interfaces** Notice that none of these forbid an agency from managing many accounts. They forbid specific behavior. ## Principle one: official interfaces only The single biggest risk reduction is publishing only through each network's official API, with permissions the account owner explicitly granted. ### Why it matters 1. **The network knows who is posting.** A post from a registered, reviewed app is identified as such. A post from an automated browser on a shared IP, logged into dozens of accounts, looks exactly like bot activity. 2. **No password sharing.** The client grants access, can revoke it at any time, and never hands a password to anyone. 3. **Limits are transparent.** Official APIs have documented rate limits and quotas. Meta documents the per-account cap on API-published posts in a rolling 24-hour window in its [Instagram content publishing guide](https://developers.facebook.com/docs/instagram-platform/content-publishing), and YouTube lists the [quota cost of each API operation](https://developers.google.com/youtube/v3/determine_quota_cost). Tools that promise "unlimited posting" or work by impersonating a user in a browser may save time in the short run, but they put your clients' accounts at risk. ## Principle two: original content per account This is the most important principle and the most tiring. The exact same text with the exact same image across dozens of pages is the classic pattern spam systems look for, even when every page belongs to the same client. ### What counts as "original enough" There's no numeric threshold, and you shouldn't go looking for one. The right question is: **was this post written for this account's audience?** Practical ways to get there: 1. **A different opening** per account group 2. **A real local detail**: the location name, a neighborhood, a local event, a staff member 3. **Varied visuals**: several images or video cuts, not one file for everyone 4. **A differently worded CTA** 5. **Not every post for every account**: if a location isn't part of the promotion, it doesn't need the post AI writing assistants can produce variations quickly. They help when they genuinely change the content, not when they just swap in synonyms. A variation that differs by a few words is still a duplicate. ## Principle three: staggered pacing Even original content creates an unusual pattern if it goes out to fifty accounts in the same second. Spreading it over time is a simple way to look like what you are: a team publishing for different clients. ### Scheduling rules of thumb 1. **Spread one campaign** across several hours, and larger campaigns across a day or more 2. **Use variable gaps** between accounts rather than exactly one post per minute 3. **Respect the per-account limit** and your app's overall quota. As you approach them, defer publishing rather than retrying 4. **Treat errors as signals**: if the network returns a rate-limit or restriction error, stop and slow down instead of retrying immediately ## Principle four: genuine engagement only Some blocks don't come from publishing at all, but from what happens afterward. Avoid: 1. Pages of the same client systematically commenting on and sharing each other's posts 2. "Tag three friends" or "comment YES to get it" prompts designed to inflate engagement 3. An identical first comment with a link posted word-for-word across every page 4. Short links that hide the destination or lead to an unrelated page A first comment carrying a link is perfectly legitimate. It should meet the same standard as the post: varied, relevant, and leading where it says it does. ## When an account gets restricted anyway 1. **Stop publishing to that account.** Don't try to work around it. 2. **Read the notice.** It usually states the general reason. 3. **Review recent content** against the rules: duplication, links, wording. 4. **Appeal through the official channel** if the restriction looks wrong. 5. **Update your process** so it doesn't happen on other accounts. ## Checklist for publishing at scale without blocks 1. Every account is connected through an official API with the owner's authorization 2. No password sharing and no browser automation 3. Each account group has its own wording and visuals 4. Every post carries a local or relevant detail 5. Publishing is spread over time with variable gaps 6. Per-account and per-app limits are known and respected 7. Rate-limit errors pause publishing instead of triggering immediate retries 8. No artificial engagement between a client's own pages 9. Links go exactly where the post says they go 10. Someone on the team has read the networks' policies in the last few months ## Wrapping up There's no trick that lets you publish at scale without getting blocked, and you don't need one. What works is the combination of official interfaces, content written for each account's audience, pacing that respects the limits, and genuine engagement. It takes more effort than copy-paste, but it's also what produces results, because audiences respond to content that speaks to them. Shager is built on these principles. It publishes only through each network's official API, staggers dispatch at a pace that respects each network's and each account's limits, and its AI writing assistant produces genuinely different variations for each account group, so every page gets content written for it. --- Source: https://shager.ai/en/blog/avoid-spam-blocks-when-posting-at-scale # How to Choose a Distribution Platform for AI Agents: 12 Criteria _2026-10-07 · Twelve criteria for choosing a social distribution platform an AI agent can run: MCP and API access, scoped keys, audit, per-account variation and pricing._ To choose a distribution platform for AI agents, test whether an agent can do the whole job through it: connect without a human clicking through screens, find the right accounts, build varied posts per account, wait for approval, schedule safely and read results per account. Then check the controls around that: key scopes, an audit log, official network APIs and pricing that does not penalize automation. A platform designed for people with an API added later usually fails on two or three of these, and those gaps are where agent projects stall. The twelve criteria below are what we would use to evaluate any platform, including ours. They are grouped into access, control, distribution quality and business fit, and they end with a short hands-on test you can run in an afternoon. ## Why does "has an API" no longer settle the question? Most social tools have offered an API for years. Those APIs were usually built for developers writing integrations: you read the docs, write code, handle authentication, map fields. An agent works differently. It discovers operations at runtime, reads descriptions to decide what to call, and needs structured errors it can act on. A platform built with agents in mind exposes its operations as tools through a standard such as the [Model Context Protocol](https://modelcontextprotocol.io/docs/getting-started/intro), describes them clearly and limits what each key can do. If you are new to MCP, start with our [explainer for marketers](/en/blog/mcp-explained-for-marketers). ## Access: can the agent reach the platform cleanly? ### 1. A remote MCP server The agent should connect by URL, with no local install. Check the transport. The MCP specification defines [Streamable HTTP](https://modelcontextprotocol.io/specification/2025-06-18/basic/transports) for remote servers. Check also how authentication works and which clients that rules in or out. ### 2. A documented REST API with an OpenAPI description Not every workflow runs inside an assistant. Scheduled jobs and internal tools call APIs directly. An OpenAPI description, for example [Shager's OpenAPI 3.1 file](https://app.shager.ai/api/v1/openapi.json), lets developers and code generators use the same operations as the MCP tools. Look for consistent response and error shapes; an agent recovers far better from `{ "error": { "code", "message" } }` than from an HTML error page. ### 3. Agent self-registration with human claim Can an agent create a trial workspace on its own and hand a human a link to take ownership? This removes the slowest step in evaluation. The safeguard is that the sandbox must be limited until a human claims it. Shager's [registration recipe for agents](/auth.md) works this way: an unclaimed sandbox can create drafts but cannot schedule, publish, send approval requests or create connect links. ## Control: can you limit and observe what the agent does? ### 4. Scoped keys Separate read, write and publish permissions are the most important control in agent-run distribution. Without them, the only thing between a prompt and a public post is the model's interpretation. ### 5. An audit log of agent calls You need to see every call an agent made, with which key, and when. Ask whether the log is visible to the team in the product or only available through support. ### 6. Draft and approval states as first-class objects The agent should be able to create a draft, request approval, check status and schedule only afterwards, all through tools. If client approval requires the client to create an account, expect approvals to stall. Our article on [human approval for agent posts](/en/blog/human-approval-for-agent-posts) explains why the gate belongs between draft and schedule. ## Distribution quality: will the output be safe and effective at scale? ### 7. Per-account variation in one call Look for a way to set a different caption, first comment and format per account inside a single post request. Without it, agents either send identical captions everywhere or make one call per account, which is slower and harder to manage. ### 8. Staggered dispatch and pre-send validation Sending to many accounts at the same second is a pattern platforms watch for. Check whether the platform spaces dispatch across accounts and lets you set the range, and whether it validates each post against the target network's rules before sending. ### 9. Official network APIs only Ask directly how the platform publishes. Browser automation and shared logins put client accounts at risk under network terms. This is a yes or no question, and the answer should be in writing. ### 10. Attribution per account A platform for agencies should generate a tracked link per account and report clicks per account and per post through the API, so the agent can produce the weekly read. ## Business fit: does it work for an agency's economics? ### 11. Client onboarding without passwords The platform should let clients connect their own accounts through a link, without creating an account and without sharing credentials, and an agent should be able to create those links through the API once a human has authorized it. ### 12. Pricing that does not tax automation Check whether API and MCP access are included or reserved for top tiers, whether each human reviewer costs a seat, and how price scales with the number of accounts. Agencies grow by accounts, so per-account pricing with unlimited users usually fits better than per-seat pricing. Shager's plans, with API, MCP and unlimited users on every tier, are on the [pricing page](/en/pricing). ## How do you score the shortlist? Use a simple sheet. Score each criterion 0, 1 or 2, and mark any criterion that is a hard requirement for you. | Criterion | Hard requirement? | Platform A | Platform B | Platform C | |---|---|---|---|---| | 1. Remote MCP server | Yes | | | | | 2. REST API with OpenAPI | | | | | | 3. Self-registration with claim | | | | | | 4. Scoped keys | Yes | | | | | 5. Audit log | Yes | | | | | 6. Draft and approval states | | | | | | 7. Per-account variation | | | | | | 8. Stagger and validation | | | | | | 9. Official APIs only | Yes | | | | | 10. Per-account attribution | | | | | | 11. Client connect links | | | | | | 12. Pricing fit | | | | | Which items are hard requirements depends on your business. The four marked here are the ones we would not compromise on for client work. ## What hands-on test should you run? Documentation tells you what a platform intends. A test tells you what an agent can actually do. Give each candidate the same task, using the same assistant. 1. **Connect.** Add the MCP server to your assistant. Time it. 2. **Discover.** Ask: "What can you do in this platform?" A good server's tool descriptions let the assistant answer accurately. 3. **Build.** Ask the agent to create a draft for three accounts with a different caption for each, a first comment with a link and a video in vertical format. 4. **Break it.** Give it a video with the wrong dimensions for a Reel. Watch whether the error is clear enough for the agent to explain and fix. 5. **Gate it.** With a key that lacks publish rights, ask the agent to schedule. It should be refused cleanly. 6. **Approve.** Send an approval request to a colleague acting as the client. Note whether they needed an account. 7. **Read.** Ask for clicks per account for a past date range. 8. **Audit.** Find the record of everything the agent just did. For Shager, steps 1 to 8 map onto `whoami`, `list_workspaces`, `list_channels`, `upload_media_from_url`, `create_post` with `per_channel`, `request_approval`, `schedule_post` and `get_analytics`, with the audit log on the agents dashboard. ## FAQ ### Should we build our own distribution layer on the networks' APIs instead? You can, and some large teams do. Weigh the cost of app review with each network, token management, format validation, rate limits and ongoing API changes against a platform that already handles them. For most agencies the build cost is hard to justify. ### How long should an evaluation take? The hands-on test above takes an afternoon per platform. Follow it with two weeks of real drafts for one client before committing. ### Does a platform need to support every network on day one? It needs to support the networks your clients use now, with a credible plan for the rest. Shager publishes to Facebook Pages, Instagram professional accounts and YouTube today, with TikTok and LinkedIn in development. If Shager is on your shortlist, an agent can start the test itself by registering a sandbox, and the [agent entry point](/en/agents) has setup steps for each client. --- Source: https://shager.ai/en/blog/choosing-a-distribution-platform-for-agents # Multilingual Content Agents: Localising for Hebrew, Arabic and English Accounts Without Translating _2026-10-06 · Running content in several languages with AI agents: localisation versus translation, Hebrew and Arabic right-to-left pitfalls, and per-account captions._ A multilingual content agent should write each account's caption natively in that account's language from a shared brief, not translate an English master line by line. In Shager that means one post per language group, with a separate caption per account in `per_channel`, and a language-specific link, YouTube title and first comment. For right-to-left languages like Hebrew and Arabic, the agent also has to handle mixed-direction text: numbers, URLs, brand names and hashtags inside RTL sentences. The second half of that answer is where most multilingual runs go wrong, and it is invisible until the post is live on a phone. ## Localisation versus translation The W3C's definition is useful because it is precise. Its internationalisation FAQ describes [localisation](https://www.w3.org/International/questions/qa-i18n) as adapting content to a specific target market, a locale, and notes that it goes well beyond translating text: formats for dates and numbers, currency, conventions, culture. For social content, that gap is enormous. A translated caption keeps the English structure, the English joke and the English call to action, rendered in another language. A localised caption starts from what the post is for, then writes what a native copywriter in that market would write. Concrete examples of what a translation misses: 1. **Hebrew addresses the reader by gender.** An English "Book your table" has no gender. In Hebrew, the imperative is masculine, feminine or plural, and brands make deliberate choices about it. An agent translating mechanically will pick one at random per post, which reads as inconsistent across forty pages. 2. **Arabic has register choices.** Modern Standard Arabic and regional dialects coexist, and the right choice depends on the brand and the audience. A brief should state which one, and the agent should not drift between them. 3. **Dates and prices.** "11/10" means different days in different countries. Currency symbols sit on different sides of the number. Write dates in words when in doubt. 4. **Holidays and rhythm.** The working week, public holidays and quiet periods differ by market. An Israeli audience on the eve of a major holiday, or an audience in a Muslim-majority country during Ramadan evenings, behaves differently from a generic Tuesday. The practical rule for the agent: the brief is the source of facts, never the source of sentences. ## How to structure a multilingual client in Shager Shager is built Hebrew-first with a right-to-left interface and a full English site, and it treats each account's caption as its own text. That fits how multilingual work should be organised. 1. **Group accounts by language.** Use `create_group` to make one group per language, for example "Aurora HE", "Aurora AR", "Aurora EN". Groups belong to the client's workspace. 2. **One post per language group.** Some fields are set once per post: `cta_url`, `youtube_title`, `campaign`. Language-specific landing pages and YouTube titles therefore need separate posts per language. This also keeps reporting per language clean. 3. **Captions per account inside each post.** `per_channel` takes a `caption` and a `first_comment` for each `channel_id`. Even within one language, vary the wording per account, as covered in [caption variation per account with AI](/en/blog/caption-variation-per-account-with-ai). A Hebrew post for a three-branch client looks like this: ```json { "tool": "create_post", "arguments": { "workspace_id": "ws_example", "group_ids": ["grp_aurora_he"], "caption": "הקולקציה החדשה מגיעה לסניפים ביום חמישי.", "cta_url": "https://aurora-example.co.il/he/new-collection", "campaign": "new-collection-he", "youtube_title": "הקולקציה החדשה של אורורה", "label": "Aurora new collection HE", "per_channel": [ { "channel_id": "ch_fb_haifa", "caption": "חיפה, הקולקציה החדשה כבר בדרך. ביום חמישי היא אצלנו בסניף.", "first_comment": "לכל הפרטים ולתיאום ביקור:\nhttps://aurora-example.co.il/he/new-collection" }, { "channel_id": "ch_fb_beersheva", "caption": "באר שבע, ביום חמישי נפתח את הארגזים. בואו לראות ראשונים." } ] } } ``` The Arabic and English posts are created the same way, with their own landing pages and campaigns. Because Shager gives every account its own short link and UTM tags, with `utm_content` identifying the account, click data stays per account and per language without any extra work. ## The right-to-left problems your agent will not see A language model produces a string of characters in logical order. The phone renders it with the [Unicode Bidirectional Algorithm](https://www.unicode.org/reports/tr9/), which decides visually where each run of left-to-right and right-to-left text sits. When a Hebrew or Arabic sentence contains English words, digits, URLs or punctuation, the result can differ from what the writer intended. The W3C's [internationalisation glossary](https://www.w3.org/TR/i18n-glossary/) points out that numbers in RTL scripts are displayed left to right and that bidirectional text is the source of many difficulties with RTL scripts. The usual symptoms in social captions: 1. **Punctuation jumps to the wrong end.** A Hebrew sentence that ends with an English brand name and a full stop can show the full stop on the left of the brand, in the middle of the line. 2. **The base direction flips.** If a caption starts with an English word or a number, a platform that sets direction by the first strong character will lay out the whole paragraph left to right. The W3C's notes on [bidi in social media](https://www.w3.org/International/wiki/Bidi_in_social_media), based on older tests, observed Facebook using first-strong detection for comments. Platforms change, so verify on current apps. 3. **Prices and ranges reorder.** "50 to 100" written with a hyphen between digits inside Hebrew text can display reversed relative to the reader's expectation. 4. **Hashtags in mixed scripts.** A hashtag that mixes Latin and Hebrew characters may break or render oddly. ## Rules to give the agent for RTL captions These go into the standing instructions for any client with Hebrew or Arabic accounts. 1. Start every RTL caption with a word in the RTL script, never with a number, a brand name in Latin letters or an emoji. 2. Do not end an RTL caption with a Latin word followed by punctuation. Rephrase so the sentence ends in the RTL script. 3. Put URLs on their own line, never in the middle of an RTL sentence. 4. Write ranges and prices in words or restructure the sentence, rather than relying on symbols between numbers. 5. Where a Latin brand name must sit mid-sentence and display breaks, a right-to-left mark (U+200F) after the Latin run usually restores the order. Use it sparingly, and only after testing, since invisible characters make text harder to edit later. 6. Before scheduling, have a native speaker check one rendered example per network on a phone. A screenshot review catches what no string check will. Shager's Hebrew writing assistant helps on the human side of this, for teams that edit or approve Hebrew captions in the interface. The agent still needs the rules above, because it writes before anyone looks. ## Approval in the client's language When a client in a different market approves content, they should see their own language. Shager's approval links let a reviewer approve without logging in; the agent sends them with `request_approval`, giving a `reviewer_name` and, optionally, an email or phone number. Send the Hebrew post to the Hebrew-speaking marketing manager and the Arabic post to the person who actually reads Arabic. A single English reviewer approving three languages is approving only one of them. The approval flow is described in [human approval for agent posts](/en/blog/human-approval-for-agent-posts). ## Time zones and calendars A client whose Arabic-speaking audience sits in a different country from its Hebrew-speaking one may need different posting times per language. Since each language is a separate post, each can have its own `schedule_at`, with the offset computed for the right zone. Shager's calendar includes Israeli holidays; for other markets, put the relevant holidays into the client's context file. The scheduling rules are in [scheduling strategy for agents](/en/blog/scheduling-strategy-for-agents). ## FAQ ### Can one post contain captions in different languages for different accounts? Yes. `per_channel` captions are free text per account, so a single post can mix languages. I would still split by language whenever the link, YouTube title or posting time should differ, because those fields are set once per post. ### Should the agent write the master in English and localise from it? Only if the brief is in English. A better pattern is a brief of facts and goals in whatever language the client uses, and native captions written from that brief for each language. Translating an English caption imports English structure into every other language. ### Does Shager handle right-to-left text correctly? Shager's own interface is right-to-left first, and captions go to the networks as the agent wrote them, apart from links, which are swapped for each account's tracked short link, and the call to action line when you set `cta_url`. How a caption renders is decided by each network's apps, so the rules above, and a quick check on a phone, still apply. ## Where to go next Set up language groups in one client's workspace and run a single post in each language before scaling. The [agent entry point](/en/agents) covers connecting your agent if you have not yet. --- Source: https://shager.ai/en/blog/multilingual-content-agents # A Weekly Distribution Routine as a Claude Skill: Monday Drafts, Client Approvals, Friday Click Report _2026-10-06 · A Claude Code skill that runs an agency week in Shager: drafts from plan files, client approvals, scheduling only what's approved, and a Friday click report._ A weekly distribution routine is a skill that runs the same three jobs every week: on Monday it turns each client's content plan into Shager drafts with per-account captions, then sends them for approval; midweek it schedules whatever was approved; on Friday it pulls clicks by account and writes the report. In Claude Code you trigger it with `/shager-weekly plan` or `/shager-weekly report`, or headless from a scheduler with `claude -p`. The human checkpoints sit between drafting and scheduling, which is where they cost least and catch most. This builds on [the basic Shager skill](/en/blog/build-a-claude-skill-for-shager). Here the focus is the routine: inputs, modes, safeguards, and how to run it without someone at the keyboard. ## What does a week actually look like? Take an agency with eight clients and around 150 connected accounts. A workable week looks like this. | When | Mode | What the skill does | Human role | |---|---|---|---| | Monday 09:00 | `plan` | Reads each client's plan file, uploads media, creates drafts, requests approval | None during the run | | Monday to Wednesday | | Clients approve or request changes through approval links | Client reviews | | Wednesday 14:00 | `schedule` | Schedules every approved post at its planned time | Account manager glances at the summary | | Friday 15:00 | `report` | Pulls clicks per account and per post, writes a report per client | Account manager sends it | The routine never invents the week's topics. It works from a plan file a human writes, because the strategy is the agency's job. What it removes is the mechanical part: forty caption variants, tracked links, format choices, follow-up. ## What does the plan file look like? One Markdown file per client per week, in a repo the skill can read: ```markdown # Harbor Fitness, week 2026-W43 workspace: Harbor Fitness timezone: America/New_York ## Post 1 when: 2026-10-20 07:00 target: group "All studios" format: REEL media: https://cdn.harborfitness.example/w43/6am-class.mp4 (1080x1920, 28s) brief: New 6am strength class starts Monday. Free first session. link: https://harborfitness.example/6am first comment: Book your free first session ## Post 2 when: 2026-10-23 12:00 target: group "Downtown studios" format: FEED media: https://cdn.harborfitness.example/w43/smoothie-bar.jpg brief: Smoothie bar reopens after renovation. 20% off this week. link: https://harborfitness.example/smoothie ``` Plain text the skill parses, and a file any account manager can edit without learning a tool. ## The SKILL.md ```markdown --- name: shager-weekly description: Run the agency's weekly Shager distribution routine. Use for "/shager-weekly plan", "/shager-weekly schedule" or "/shager-weekly report", or when asked to prepare, schedule or report this week's client posts from the plans folder. argument-hint: "plan | schedule | report [client]" disable-model-invocation: true allowed-tools: Read Glob Write mcp__shager__whoami mcp__shager__list_workspaces mcp__shager__list_channels mcp__shager__list_groups mcp__shager__list_posts mcp__shager__get_post mcp__shager__get_analytics mcp__shager__upload_media_from_url mcp__shager__create_post mcp__shager__request_approval mcp__shager__schedule_post --- # Shager weekly routine Plans live in plans//.md. Reports go to reports//. Mode is the first argument. Process every client unless one is named. ## plan For each post in each plan file: 1. Resolve workspace, group and channels. Skip channels not ACTIVE and list them. 2. upload_media_from_url with width, height and duration_ms from the plan. 3. create_post WITHOUT schedule_at: per_channel captions written from the brief (same facts, different wording, local detail from channel name), cta_url = link, campaign = "--", first_comment = ": ", label = "W43 Post 1". 4. request_approval with the client's reviewer from plans/reviewers.md. Write a summary: client, post label, post id, accounts, approval_url. ## schedule For each client: list_posts with status APPROVED. For each, find its planned time in the plan file by label and call schedule_post with schedule_at in ISO 8601 with the workspace offset. Never schedule a post that is not APPROVED. Never schedule a time in the past; list it instead. ## report For each client: get_analytics from last Monday 00:00 to now (with offset). Write reports//.md with a table of clicks by account, highest first, and the top three posts with their labels. State plainly that these are link clicks, not leads. ## Errors Stop the current client on 401 or 403 and record the code. On 422, record the message against the post and continue. On 429, wait 60 seconds. ``` ### Why each safeguard is there `disable-model-invocation: true` means Claude never starts this routine on its own because a conversation mentioned "this week's posts." Per the [Claude Code skills docs](https://code.claude.com/docs/en/skills), that field prevents automatic loading, so the routine only runs when someone or something types the command. The `allowed-tools` list is complete for the job and nothing more. There's no `cancel_post`, no `create_connect_link`, no `create_workspace`. A routine that runs headless should not be able to do things a human didn't plan for. Scheduling only touches posts in `APPROVED` status, and that status only exists once the client approved through their link. If a client never approves, the post just doesn't go out, and the Wednesday summary says so. The reasoning behind putting approval exactly here is in [the client approval workflow for agencies](/en/blog/client-approval-workflow-for-agencies). ## Which key should the routine use? This is the decision that defines how much you trust the routine. | Setup | Key scopes | Result | |---|---|---| | Drafts only | `read`, `write` | `plan` and `report` run; a human schedules in Shager | | Approval-gated | `read`, `write`, `publish` and approval required on every workspace | The routine schedules only what clients approved | | Full autopilot | `read`, `write`, `publish`, no approval | Only for low-risk recurring content you'd post without review anyway | The second row is the one we recommend for most agencies. The `publish` scope is granted to one key, created for this routine alone at https://app.shager.ai/dashboard/agents, so the audit log there shows every call the routine made and nothing else. If something looks wrong, you revoke that key and every other integration keeps working. ## How do you run it without opening a terminal? Claude Code's non-interactive mode runs a skill from a script. The [headless docs](https://code.claude.com/docs/en/headless) state that user-invoked skills work in `-p` mode when you include `/skill-name` in the prompt, and that `--allowedTools` pre-approves tools using permission rule syntax. They also describe `--permission-mode dontAsk`, which denies anything that would otherwise prompt, so an unexpected tool call fails rather than hangs. ```bash #!/usr/bin/env bash # run-weekly.sh (called by cron or your CI scheduler) set -euo pipefail cd /srv/agency-content export SHAGER_API_KEY="$(cat /run/secrets/shager_weekly_key)" claude -p "/shager-weekly $1" \ --permission-mode dontAsk \ --allowedTools "Read,Glob,Write(reports/**),mcp__shager__whoami,mcp__shager__list_workspaces,mcp__shager__list_channels,mcp__shager__list_groups,mcp__shager__list_posts,mcp__shager__get_post,mcp__shager__get_analytics,mcp__shager__upload_media_from_url,mcp__shager__create_post,mcp__shager__request_approval,mcp__shager__schedule_post" \ --output-format json > "logs/weekly-$1-$(date +%F).json" ``` And the crontab, in the server's local time: ```text 0 9 * * 1 /srv/agency-content/run-weekly.sh plan 0 14 * * 3 /srv/agency-content/run-weekly.sh schedule 0 15 * * 5 /srv/agency-content/run-weekly.sh report ``` This assumes the Shager MCP server is registered in the project's `.mcp.json` with the key read from `SHAGER_API_KEY`, as shown in [connecting Shager to Claude Code](/en/blog/connect-shager-to-claude-code). The JSON output gives you the session id and the final summary, which is what you'd forward to the team channel. ## What still needs a human every week? Three things, and the routine is designed around them rather than against them. 1. Writing the plan file. Topics, offers and timing are strategy. 2. Reading the Wednesday summary. It lists anything not approved, skipped channels and 422 rejections. Five minutes. 3. Sending the Friday report with context. Clicks per account are a fact; what they mean for the client is a conversation. Remind clients that link clicks aren't leads, and point them at [per-account lead attribution](/en/blog/utm-per-account-lead-attribution) if they want to close that gap in their CRM. ## FAQ ### What if a client approves after Wednesday? Run `/shager-weekly schedule` again, by hand or from a second cron line on Thursday. The mode only schedules `APPROVED` posts that aren't already scheduled, and it refuses times in the past, so running it twice is safe. ### Can the routine connect new accounts when a client adds a location? Not by design. `create_connect_link` is left out of the allowed tools because connecting accounts involves the client and should be a deliberate human action. When a location is added, the account manager sends a connect link and adds the new channel to the right group; the next run picks it up automatically. ### Does this work with Codex or Cursor instead of Claude Code? The plan files, modes and safeguards translate directly, since the Shager tools are the same in every MCP client. The `SKILL.md` frontmatter and `claude -p` invocation are specific to Claude Code; elsewhere you'd keep the instructions as a prompt file and drive it with that client's own automation. ## Next step The routine handles the week; the [end-to-end agent content pipeline](/en/blog/agent-content-pipeline-end-to-end) shows the full chain around it, from a client brief through generated media and captions to published posts and measured clicks, with every Shager call in order. --- Source: https://shager.ai/en/blog/skill-weekly-distribution-routine # Making a Website Agent-Ready: llms.txt, Markdown Pages, OpenAPI, api-catalog and MCP Server Cards _2026-10-03 · What an agent-ready website publishes: llms.txt, Markdown page versions, OpenAPI, the RFC 9727 api-catalog and an MCP server card, with shager.ai as example._ An agent-ready website gives software a short, predictable path from "what is this?" to "how do I use it?". In practice that means five files or conventions: an `/llms.txt` summary, clean Markdown versions of each page, an OpenAPI description of the API, an RFC 9727 `/.well-known/api-catalog` that points to it, and an MCP server card describing how to connect. None of them is hard to publish. Together they let an agent find, understand and start using a product without a human copying URLs into a chat. I will use shager.ai as the worked example throughout, because every piece described here is live on it and you can fetch each one with `curl` as you read. ## Why bother, if no engine promises to read these files? Honesty first. `llms.txt` is a proposal, not a ratified standard, and I am not aware of any major model provider publicly committing to use it in retrieval. The api-catalog is a real IETF RFC, and MCP server cards are an accepted MCP extension, but adoption by crawlers and clients is still early. The case for doing it anyway is practical. Agents increasingly arrive at a site because a person told them to, as in "sign up for this and connect it." At that moment the agent fetches pages directly. A site that answers in clean Markdown, with an explicit API description and a connection recipe, gets used correctly. A site that answers with 400 KB of JavaScript gets guessed at. ## llms.txt: the front door The format is defined at [llmstxt.org](https://llmstxt.org/). It is a Markdown file at `/llms.txt` with an H1 naming the site (the only required part), a blockquote summary, optional free text, and H2 sections containing lists of links with short notes. A section titled "Optional" marks links an agent can skip when it needs a shorter context. Shager's file follows that shape. The top looks like this: ```markdown # Shager > Shager (שגר) is agent-first distribution infrastructure for agencies and > marketers: your agent creates, Shager ships it everywhere. ... ## For AI agents - MCP server: https://app.shager.ai/api/mcp (Authorization: Bearer ; OAuth sign-in is coming) - REST API: https://app.shager.ai/api/v1 ... - Self sign-up: POST https://app.shager.ai/api/v1/agent/signup ... ``` A few choices worth copying. The agent section comes before marketing pages, because an agent reading the file usually wants to act. Pricing is stated in plain numbers in the file itself rather than behind a link. Things that are not live are labelled as coming, so an agent does not promise a user a feature that does not exist. And there is a companion `/llms-full.txt` with all content in one file for agents that prefer a single fetch. ## Markdown versions of every page The same proposal suggests serving a clean Markdown version of each page, and recommends advertising it with `rel="alternate"` and `type="text/markdown"`, plus `rel="describedby"` pointing at the `llms.txt` that covers the page. Both can be HTML `` elements or an HTTP `Link` header. Shager does this in two ways. Every page has a Markdown twin under `/md/`, so `/en/pricing` is also at `/md/en/pricing`. And a request for the normal URL with `Accept: text/markdown` gets the Markdown directly: ```bash curl -s -H "Accept: text/markdown" https://shager.ai/en/pricing | head -5 ``` Every HTML page also sends a `Link` header announcing its alternates: ```http link: ; rel="api-catalog", ; rel="describedby"; type="text/plain", ; rel="alternate"; type="text/markdown" ``` One detail that matters for search: the Markdown responses carry `x-robots-tag: noindex`, so search engines do not index two copies of every page. The Markdown is for agents; the HTML remains the canonical page for people and search results. ## OpenAPI: the contract For anything an agent will call, an [OpenAPI](https://spec.openapis.org/oas/v3.1.0) document is still the most useful thing you can publish. It gives operation IDs, parameters, schemas and authentication in a form agents and code generators both read. Shager's is at [app.shager.ai/api/v1/openapi.json](https://app.shager.ai/api/v1/openapi.json), version 3.1. Three conventions in it help agents specifically. Operation IDs match the MCP tool names (`create_post`, `get_analytics`), so an agent that learned one interface knows the other. Each operation declares its required key scope in an `x-scope` extension. And field descriptions are written as instructions, for example the `per_channel` caption override says it is recommended to vary wording per account. Descriptions are prompt space; use them. ## api-catalog: telling software where the APIs are [RFC 9727](https://www.rfc-editor.org/rfc/rfc9727), published by the IETF in June 2025, defines a well-known URI, `/.well-known/api-catalog`, and an `api-catalog` link relation. A request to it returns a document listing a publisher's APIs with links to their descriptions and documentation. The RFC requires the `application/linkset+json` media type for the document and uses link relations such as `service-desc` for machine-readable descriptions like OpenAPI and `service-doc` for human documentation. This is Shager's catalog, complete: ```json { "linkset": [ { "anchor": "https://app.shager.ai/api/v1", "service-desc": [ { "href": "https://app.shager.ai/api/v1/openapi.json", "type": "application/openapi+json" } ], "service-doc": [ { "href": "https://shager.ai/en/agents", "type": "text/html" }, { "href": "https://shager.ai/md/en/agents", "type": "text/markdown" } ] } ] } ``` It is short because Shager has one API. A company with several would list one entry per API. The `rel="api-catalog"` link in every page's `Link` header, shown above, is how a client that lands on any page finds the catalog without guessing the path. ## MCP server cards: how to connect before connecting An MCP client needs to know where a server lives and how to authenticate before it can call `tools/list`. [SEP-2127](https://modelcontextprotocol.io/seps/2127-mcp-server-cards) defines MCP Server Cards for exactly this: a static JSON document describing a remote server's identity, its transport endpoints, required headers and supported protocol versions. The SEP reserves `/server-card` as the recommended location and describes domain-level discovery through an AI Catalog that links to cards. The detailed schema lives in the extension's repository. Shager serves its card at the recommended location, `https://app.shager.ai/api/mcp/server-card`, and also at `https://shager.ai/.well-known/mcp/server-card.json`, a path some discovery tools probe. The connection part reads: ```json { "name": "ai.shager/shager", "title": "Shager", "version": "1.0.0", "remotes": [ { "type": "streamable-http", "url": "https://app.shager.ai/api/mcp", "headers": [ { "name": "Authorization", "isRequired": true, "isSecret": true, "description": "Bearer shgr_… API key (self-signup: POST /api/v1/agent/signup)" } ] } ] } ``` The card also lists Shager's tools with one-line descriptions. Note that the SEP deliberately keeps tools out of the standard card fields, because what a server exposes can vary by user and session. Treat any tool list in a card as a preview; the live `tools/list` call is the source of truth. ## Two extras: auth.md and a skill file Discovery tells an agent what exists. Two more files tell it what to do. [/auth.md](/auth.md) is a plain recipe for how an agent gets access: discover, register with the self-signup call, use the key, hand the claim link to a human, and how the human revokes. It also states the rules: rate limit, error shape, caption variation, official APIs only. An agent can follow it top to bottom. `https://shager.ai/skills/shager/SKILL.md` is a skill file in the format Claude Code uses for [skills](https://code.claude.com/docs/en/skills): YAML frontmatter with a `name` and a `description` that tells the model when to use it, then numbered instructions. Install it and the agent knows the Shager workflow without a long prompt. Building your own version is covered in [build a Claude skill for Shager](/en/blog/build-a-claude-skill-for-shager). ## A checklist for your own site 1. `/llms.txt` with an H1, a one-paragraph summary, an agent section first, and honest labels for anything not live. 2. A Markdown version of each page, advertised with `rel="alternate"` and `type="text/markdown"`, marked `noindex`. 3. An OpenAPI document with operation IDs that match your MCP tools and descriptions written as instructions. 4. `/.well-known/api-catalog` as `application/linkset+json`, linked from every page with `rel="api-catalog"`. 5. An MCP server card at `/server-card`. 6. A plain-language access recipe like `auth.md`, if agents can sign up. ## FAQ ### Is llms.txt the same as robots.txt? No. `robots.txt` tells crawlers what they may fetch. `llms.txt` is a curated guide to what is worth reading, written for language models. It grants or denies nothing. ### Does publishing these files improve search rankings? There is no published evidence that it does, and no search engine has said it uses `llms.txt` as a ranking signal. The value is in agents using your product correctly once they arrive. Keep the HTML pages strong for search on their own merits. ### Do I need an MCP server to benefit from this? No. `llms.txt`, Markdown pages, OpenAPI and an api-catalog are useful for any site with documentation or an API. The server card only applies if you run a remote MCP server. ## Where to go next Fetch Shager's files with `curl` and compare them with your own site. For what an agent does after discovery, the [agent entry point](/en/agents) is the next stop. --- Source: https://shager.ai/en/blog/agent-ready-websites-llms-txt # API Keys for Agents: Read, Write, Publish, and an Audit Trail You Will Actually Check _2026-10-01 · Giving AI agents Shager API keys safely: what read, write and publish allow, the sandbox claim, key storage, rate limits, key rotation and the audit log._ Give each agent the narrowest Shager key that covers its job: `read` for reporting, `write` for drafting, and `publish` only for the step that schedules posts. Keep keys in environment variables or the MCP client's configuration, never in prompts. Revoke and rotate from the agents dashboard, and read its audit log, which lists every call an agent makes, at least weekly while a new agent is bedding in. That is the policy. The rest of this article is the reasoning and the mechanics, because a policy nobody understands gets bypassed the first time it is inconvenient. ## What can each scope do? Every Shager key carries one or more of three scopes. Each operation in the API declares the scope it needs; you can see it as `x-scope` on each operation in the [OpenAPI document](https://app.shager.ai/api/v1/openapi.json). The MCP tools are the same operations, so the same rules apply over MCP. | Scope | Operations | |---|---| | read | whoami, list_workspaces, list_channels, list_groups, list_posts, get_post, get_analytics | | write | create_workspace, create_connect_link, create_group, upload_media_from_url, create_post, request_approval, cancel_post | | publish | schedule_post | Two things in that table deserve attention. First, `publish` contains a single operation, and it is the one that makes content go live on client accounts. Isolating it is the point. An agent can do almost all of the work, from uploading media to drafting per-account captions to sending approval links, without ever being able to put a post on a Page. Second, `cancel_post` sits under `write`. A drafting agent can pull a scheduled post back to draft. That is deliberate: stopping a mistake should be easier than making one. A key used without the required scope gets an error in the standard shape, `{ "error": { "code", "message" } }`, with HTTP 403. Agents should report that error rather than look for another way around it, and your standing instructions should say so. ## Where keys come from There are two paths. **A human creates the key** at `app.shager.ai/dashboard/agents`, choosing the scopes. This is the normal path for an agency adding an agent to an existing account. **The agent signs itself up.** An agent with no account calls `POST https://app.shager.ai/api/v1/agent/signup` with an `agent_name` and, ideally, a `contact_email` for its human. It receives an `api_key`, shown once, and a `claim_url`. That key works immediately in a sandbox, which can create up to five workspaces, upload media, create drafts and read. It cannot schedule or publish, create client connect links, or send approval requests. ```bash curl -s https://app.shager.ai/api/v1/agent/signup \ -H "Content-Type: application/json" \ -d '{"agent_name":"Northwind content agent (Claude Code)", "contact_email":"ops@northwind-agency.example", "purpose":"Draft weekly posts for 3 retail clients"}' ``` Those restrictions lift only when a human opens `claim_url`, signs in and claims the organization. At that moment the human decides whether the agent's key also gets `publish`. If nobody claims it, the sandbox expires after seven days. The full recipe is published at [/auth.md](/auth.md), and the walkthrough is in [agent self-signup and claim](/en/blog/agent-self-signup-and-claim). The design choice behind this is simple: an agent can explore and prepare on its own, but connecting real accounts and publishing to them always passes through a person. ## How should agents store and send keys? Shager keys are bearer tokens sent as `Authorization: Bearer shgr_live_...`. The defining property of a bearer token, as [RFC 6750](https://www.rfc-editor.org/rfc/rfc6750) puts it, is that any party in possession of it can use it. Nothing else proves identity. So the whole job is not leaking it. In practice: 1. **Environment variables, referenced by config.** Claude Code supports `${VAR}` expansion in the headers of `.mcp.json`, per its [MCP documentation](https://code.claude.com/docs/en/mcp). The file can be committed; the key stays in the environment. 2. **Never in a prompt.** A key pasted into chat ends up in transcripts and logs, and sometimes in shared conversations. 3. **Never in a client's folder.** If you keep per-client context folders, keys do not belong in them. Those folders get shared and zipped. 4. **One key per agent role.** A reporting job, a drafting agent and a scheduling step should not share a key. When one leaks, you revoke one. ```json { "mcpServers": { "shager": { "type": "http", "url": "https://app.shager.ai/api/mcp", "headers": { "Authorization": "Bearer ${SHAGER_DRAFT_KEY}" } } } } ``` Today Shager's MCP server authenticates with this API key header. OAuth sign-in for MCP is coming; until then, clients that only support OAuth connectors need to wait or call the REST API from code. [Shager and ChatGPT](/en/blog/shager-and-chatgpt) explains what that means for ChatGPT specifically. ## Rotation without downtime Keys should be rotated when a person with access leaves, when a key may have been exposed, and on a schedule you can stick to. The sequence that avoids a gap: 1. Create a new key with the same scopes in the dashboard. 2. Update the environment variable where the agent runs. 3. Run `whoami` with the new key to confirm it works and shows the expected scopes. 4. Revoke the old key. Revocation takes effect for every call made with that key, MCP and REST alike. ## Rate limits are part of safety Each key is limited to 120 requests per minute. A well-behaved agent never gets near it: a full weekly draft for a client is a few dozen calls. When an agent does hit HTTP 429, it usually means a loop, an agent retrying the same failing call over and over. Your instructions should treat 429 as a stop signal, not a reason to retry faster. Back off, report, and let a human look. ## Reading the audit log The agents dashboard shows an audit log of every agent call. It is only useful if someone reads it. What to look for in the first weeks with a new agent: 1. **Calls you did not expect.** A reporting agent calling `create_post` means its instructions or its key are wrong. 2. **Workspace drift.** Calls touching a client the task was not about. This is the early warning for the cross-client mistake discussed in [one agent, many clients](/en/blog/one-agent-many-clients). 3. **Error bursts.** Repeated 403s mean the agent keeps attempting something outside its scope. Fix the instructions, not the scope. After a few clean weeks, a quick weekly skim is enough. ## FAQ ### Should the agent ever hold the publish scope? It can, once you trust its drafting and you have a review step, either client approval links or an internal reviewer. A pattern that works well is to keep `publish` on a separate key used only by a short, scripted scheduling step, so the agent that writes is not the agent that ships. ### What happens to an agent's key when the sandbox is claimed? The organization becomes the human's, and the key keeps working inside it. The human chooses at claim time whether that key may also schedule and publish. They can revoke it or create new ones from the dashboard at any time. ### Can a key be limited to one client workspace? Scopes limit what a key can do, not which workspace it acts on. Separate clients through workspaces, per-client context and a habit of resolving the workspace by name before every write, and use separate keys per role so revocation stays surgical. ## Where to go next If you are setting up your first agent, the [agent entry point](/en/agents) shows both paths to a key. Start with a `write` key and add `publish` only when the drafts have earned it. --- Source: https://shager.ai/en/blog/api-keys-scopes-and-audit # Build a Claude Skill for Shager: SKILL.md, Folder Layout and the Rules That Make Multi-Account Posting Repeatable _2026-09-30 · Package Shager distribution as a Claude Agent Skill: frontmatter that triggers well, reference files, a REST helper script, and where the skill should live._ A Claude skill for Shager is a folder with a `SKILL.md` file whose YAML frontmatter has a `name` and a `description`, followed by instructions that tell Claude how to run distribution through Shager's tools: which calls to make, in what order, and which rules never bend. Put it in `~/.claude/skills/shager-distribution/` for yourself or `.claude/skills/shager-distribution/` in a repo for your team, and Claude Code loads it when a request matches, or when you type `/shager-distribution`. The connection to Shager is the easy part. The skill is where you encode the judgment: caption variation, tracked links, drafts by default, and what to do when the API says no. ## Why write a skill instead of a long prompt? Because the prompt you perfect on Tuesday is gone by Thursday, and the teammate who didn't see it writes a worse one. Anthropic's [Agent Skills overview](https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview) describes skills as filesystem resources that load on demand. Only the name and description sit in context until the skill triggers. Then `SKILL.md` is read, and any extra files it points to are read only when needed. So you can afford detailed instructions without paying for them in every conversation. For Shager specifically, the procedure is stable while the content changes every week. That's the profile of a good skill. ## What are the rules for SKILL.md frontmatter? From the same overview page, `name` and `description` are required. `name` is at most 64 characters, lowercase letters, numbers and hyphens only, and can't contain the reserved words "anthropic" or "claude". `description` is non-empty, at most 1,024 characters, and must say both what the skill does and when to use it, because that's what Claude matches requests against. Claude Code adds optional fields, documented in [Use Skills in Claude Code](https://code.claude.com/docs/en/skills): `allowed-tools` for tools Claude may use without asking while the skill is active, `disable-model-invocation` to make it manual only, `argument-hint` for autocomplete, and others. The directory name, or `name` when set, becomes the slash command. ## What should the folder look like? ```text shager-distribution/ SKILL.md reference/ tools.md errors.md scripts/ shager.py ``` `SKILL.md` holds the procedure. `reference/tools.md` holds the field-level detail for `create_post` and `upload_media_from_url`, read only when Claude needs it. `scripts/shager.py` is an optional REST fallback for environments without the MCP server. The Claude Code docs recommend keeping `SKILL.md` under 500 lines and moving detail into separate files, which is exactly this split. Shager also publishes a maintained skill file at https://shager.ai/skills/shager/SKILL.md. It's a good starting point to read before writing your own; the version below adds agency-specific rules. ## The SKILL.md ```markdown --- name: shager-distribution description: Distribute a post or video to many social accounts through Shager (Facebook Pages, Instagram professional accounts, YouTube channels). Use when the user asks to post, schedule, draft or distribute content to client accounts, account groups or "all locations", or asks which account drove clicks. argument-hint: "[workspace] [brief or media URL]" allowed-tools: mcp__shager__whoami mcp__shager__list_workspaces mcp__shager__list_channels mcp__shager__list_groups mcp__shager__get_post mcp__shager__list_posts mcp__shager__get_analytics --- # Shager distribution ## Before anything 1. Call whoami. Note the scopes and whether this is a sandbox. 2. Resolve the workspace by name with list_workspaces. If two match, ask. 3. Call list_channels and list_groups. Only target channels with status ACTIVE. ## Building the post 1. Media: call upload_media_from_url. For vertical video pass width, height and duration_ms so Shager can validate Reels, Shorts and Stories. 2. Captions: write one caption per channel in per_channel. Keep facts, prices and dates identical; vary the opening line, structure and the local detail (city, branch, presenter) taken from the channel name. 3. Links: never paste a raw URL into captions. Pass it as cta_url so each account gets its own short link and UTM tags. Put the call to action in first_comment for Facebook and YouTube. Instagram does not make comment links clickable, so for Instagram channels mention "link in bio". 4. Set campaign to a lowercase slug, e.g. "spring-open-day-2026". 5. Set label to something a human will recognize in the calendar. ## Drafts by default Create the post WITHOUT schedule_at unless the user gave an explicit date and time in this conversation. Show a table of channel, network, format and the first line of each caption, and wait for confirmation. ## Scheduling Only when confirmed: call schedule_post with schedule_at in ISO 8601 with the workspace's UTC offset. If the workspace requires approval, call request_approval instead and return the approval_url to the user. ## When Shager says no Read error.code, do not retry blindly. See reference/errors.md. ## Reporting For "how did it do", call get_analytics for the date range and present clicks by account, highest first, plus the top posts. Field details for create_post: reference/tools.md ``` A few decisions in there are worth defending. The `allowed-tools` list contains only read operations. `create_post`, `schedule_post`, `request_approval` and `cancel_post` still prompt for permission in Claude Code, so a human sees each write. MCP tools are named `mcp____`, which assumes you registered the server as `shager` as in [connecting Shager to Claude Code](/en/blog/connect-shager-to-claude-code). The Instagram line reflects how the network behaves: links in captions and comments aren't clickable there. The first comment with the tracked link earns its keep on Facebook Pages and YouTube. "Drafts by default" is enforced twice. Once in the instructions, and again by giving the skill's environment a key without the `publish` scope. Instructions guide; scopes enforce. ## reference/errors.md ```markdown # Shager error codes 401 unauthorized: key missing or malformed. Stop and tell the user. 403 forbidden: key lacks a scope. If scheduling, say a human must schedule or grant publish at app.shager.ai/dashboard/agents. 403 sandbox_unclaimed: show the claim link from signup; nothing else to do. 404 not_found: re-list channels or posts; ids are per workspace. 409 not_scheduled: the post is not scheduled; get_post and report status. 422 rejected: a network rule failed. Quote the message, fix the input (length, format, media), and try once more. 429 rate_limited: wait 60 seconds, then continue. Never loop per account. ``` ## scripts/shager.py: the REST fallback When MCP isn't configured, the skill can still work through the REST API, described in the [OpenAPI document](https://app.shager.ai/api/v1/openapi.json). A small helper keeps Claude from improvising HTTP code each time: ```python #!/usr/bin/env python3 """Usage: shager.py METHOD PATH [JSON_BODY] Example: shager.py GET /workspaces shager.py POST /workspaces/WS_ID/posts '{"caption": "..."}'""" import json, os, sys, requests API = "https://app.shager.ai/api/v1" def main(): method, path = sys.argv[1].upper(), sys.argv[2] body = json.loads(sys.argv[3]) if len(sys.argv) > 3 else None r = requests.request( method, f"{API}{path}", headers={"Authorization": f"Bearer {os.environ['SHAGER_API_KEY']}"}, json=body, timeout=90, ) payload = r.json() if not r.ok: e = payload["error"] print(json.dumps({"status": r.status_code, "code": e["code"], "message": e["message"]})) sys.exit(1) print(json.dumps(payload["data"], indent=2)) if __name__ == "__main__": main() ``` Add one line to `SKILL.md` such as "If the shager MCP tools are unavailable, run scripts/shager.py with the same operation paths", and list the paths in `reference/tools.md`. The overview page notes that when Claude runs a bundled script, only its output enters context, not the code. ## Where should the skill live? | Surface | Location | Can it reach Shager? | |---|---|---| | Claude Code, personal | `~/.claude/skills/shager-distribution/` | Yes, via MCP or the script. Skills there have the same network access as any program on your machine | | Claude Code, team | `.claude/skills/shager-distribution/` committed to a repo | Yes, same as above | | claude.ai | Uploaded as a zip in Settings, Features | Network access varies by user and admin settings | | Claude API | Uploaded through the Skills API | No: skills on the API run without network access | That last row comes straight from the overview's runtime constraints, and it surprises people. On the API, use Shager's MCP server or your own tool calls for the network side, and keep the skill to instructions. Also note that custom skills don't sync between surfaces; a skill uploaded to claude.ai isn't in Claude Code. ## How do you test it? 1. Ask something that should trigger it without naming it: "Draft this week's open-day post for all Harbor Fitness locations." Check that Claude reads the skill. 2. Ask something that shouldn't: "What's a good caption length for Reels?" The skill should stay out. 3. Run `/shager-distribution Harbor Fitness https://example.com/clip.mp4` and check that it stops at the draft table. 4. Use a key without `publish` and ask it to schedule. It should explain the 403 instead of looping. ## FAQ ### Can the skill's name include "claude"? No. Anthropic's skill rules reserve the words "anthropic" and "claude" in the `name` field. Use something like `shager-distribution`; the title of your docs can still say it's a Claude skill. ### Should the skill store the API key? No. Keep the key in the MCP client config or an environment variable such as `SHAGER_API_KEY`. A skill is a shareable folder and often ends up in git; a key inside it ends up leaked. ### Does the same skill work in Cursor or Codex? The `SKILL.md` format is Anthropic's, but the instructions inside are plain text. Teams often paste the body into Cursor rules or a Codex prompt file. The tool names are the same in every client because they come from Shager's MCP server. ## Next step A skill that drafts on request is the foundation. The next article turns it into a [weekly distribution routine](/en/blog/skill-weekly-distribution-routine) that plans the week, drafts every client's posts, routes approvals and reports clicks, with the human checkpoints in the right places. --- Source: https://shager.ai/en/blog/build-a-claude-skill-for-shager # A Client Approval Workflow That Doesn't Stall Your Content Calendar _2026-09-30 · How agencies build client approvals that work: what needs sign-off, clear deadlines, approval links instead of email threads, and rules for silent clients._ Every agency knows the moment. The calendar is built, the videos are cut, the captions are written, and everything waits on "the approver" on the client side. A day passes, then another, and finally a message arrives at 10 p.m. with three changes, one of which contradicts what was agreed last week. Client approval is a legitimate and necessary part of the work. The problem isn't approval itself. It's a process nobody defined. This article lays out an approval workflow that protects the client and their brand without holding the agency hostage. ## Why approvals stall Usually it's not reluctance. Approvals stall because: 1. **It's unclear what needs approving.** The client gets a spreadsheet with forty posts and doesn't know where to start. 2. **Feedback is scattered across channels.** Some in email, some in chat, some on a call. Nobody knows which version is current. 3. **There's no deadline.** "Approve when you can" means "not now." 4. **There are too many approvers.** Everyone adds a comment, nobody decides. 5. **The client can't see the post as it will appear.** Copy in a doc and an image in a folder don't feel like a post, so it's hard to commit. Each of these is a process problem, not a willpower problem. ## What the client should approve, and what they shouldn't This is the most important question and the one least often asked. When an agency publishes to dozens of accounts, approving every post individually doesn't scale. Decide the level of approval up front. ### Three common approval levels | Level | What gets approved | Best for | |---|---|---| | Campaign | Message, offer, CTA, core creative | Clients with many similar accounts | | Weekly calendar | All posts for the week in one view | Mid-volume clients | | Post by post | Every post individually | Sensitive or regulated industries | For most lead-gen agency work, campaign-level approval is right: the client signs off on message and creative, and the agency owns the variations and per-account adaptation. Put this in writing at the start of the engagement. ### What always needs explicit sign-off 1. Prices, discounts and offer terms 2. Claims about results, quality or competitors 3. Images of real people, staff or customers 4. Content in regulated categories such as health, finance or real estate ## One approval link instead of a message thread The single biggest improvement is getting approvals out of email and chat. A dedicated approval link, where the client sees posts as they'll actually appear, with the image or video, the caption and the scheduled date, changes the dynamic. What it needs: 1. **A real preview** of the post, not copy separated from the media 2. **Approve and "needs changes" buttons**, with comments attached to the specific post 3. **No sign-up or password** for the client. Every extra step lowers the response rate 4. **An audit trail**: who approved, when, and which version All feedback lives in one place, attached to the post it refers to, and there's no argument later about "but I told you." ## Deadlines that hold An approval deadline isn't rude. It's the only way a content calendar survives contact with reality. ### A practical rule of thumb 1. **Send for approval**: at least three business days before the first post in the batch 2. **Approval cutoff**: one business day before publishing, at a set time 3. **Revision rounds**: one included; a second round moves the schedule accordingly Every agency should tune these numbers. What matters is that they're written down, agreed and visible on every approval request. ## What happens when the client goes quiet This is where most processes collapse. Decide in advance, and agree with the client, what happens when the cutoff passes. Common options: 1. **The post doesn't go out.** Safest, but leaves accounts silent and hurts the campaign. 2. **The post goes out as is.** Only appropriate when the campaign was approved and the posts are variations of it. 3. **Pre-approved fallback content goes out instead.** "Evergreen" posts with no prices or claims that the client approved once for use as backup. Option three is usually the best compromise. The calendar never goes empty, and the client is never surprised by content they haven't seen. ## One approver, not a committee When five people on the client side comment on the same post, the agency ends up mediating between opinions. Ask the client to name one approver per account or account group, responsible for collecting internal feedback and returning one answer. Other stakeholders can get the approval link to view, but the final call stays with one person. ## Checklist for setting up approvals 1. Approval level agreed in writing per client 2. Content types that always need explicit sign-off are defined 3. One approver per client or account group 4. Approval happens through a preview link, not in messages 5. Every approval request carries a clear deadline 6. A defined rule for what happens after the deadline 7. A bank of pre-approved fallback content 8. A record of who approved each version ## Wrapping up A good approval process doesn't slow the work; it speeds it up. When it's clear what gets approved, where, by when and what happens without an answer, the client feels in control of their brand and the agency can plan weeks ahead. Most of the friction disappears once approvals leave the message thread. With Shager you can send the client an approval link where they see posts as they'll appear and approve or request changes on each one, with no account needed. Posts wait for approval before going out to any account, and you keep a record of who approved what and when. --- Source: https://shager.ai/en/blog/client-approval-workflow-for-agencies # MCP Explained for Marketers: What It Is and Why Your Tools Need It _2026-09-30 · A plain-language guide to the Model Context Protocol for marketers: what MCP is, what servers and tools mean, how agents use them, and what to ask vendors._ MCP, the Model Context Protocol, is an open standard that lets AI assistants such as Claude or ChatGPT use outside software: read data from it and take actions in it. For a marketer, it means you can ask an assistant to "draft next week's posts for the northern stores and send them to the client for approval," and the assistant can actually do that inside your publishing platform, rather than just writing text for you to copy. If a marketing tool has no MCP server or API, agents cannot work with it. You do not need to understand the protocol's internals to make good decisions about it. You do need to understand a few concepts well enough to evaluate vendors and to set safe limits on what agents can do. ## What problem does MCP solve? Language models are good at reading and writing. On their own, they cannot open your scheduling tool, look up which Pages belong to which client, or put a post in the calendar. Until recently, giving them those abilities meant a developer building a custom integration for each assistant and each tool, which few marketing teams could justify. MCP standardizes the connection. The project's own documentation describes it as [an open-source standard for connecting AI applications to external systems](https://modelcontextprotocol.io/docs/getting-started/intro) and compares it to a USB-C port: one shape of plug, many devices. A tool vendor builds one MCP server, and any assistant that supports MCP can use it. The same page lists support across Claude, ChatGPT, Visual Studio Code, Cursor and others. ## What are servers, clients and tools? Three words carry most of the meaning. | Term | What it is | Marketing example | |---|---|---| | MCP client | The AI application you talk to | Claude Desktop, Claude Code, Cursor, Codex | | MCP server | The connector a software vendor provides | Shager's server at `https://app.shager.ai/api/mcp` | | Tool | One action the server offers | `list_channels`, `create_post`, `get_analytics` | When you connect a client to a server, the client asks the server which tools it offers, and the model decides which to call based on your request. The specification describes tools as [model-controlled](https://modelcontextprotocol.io/specification/2025-06-18/server/tools): the model discovers and invokes them based on context and your prompt. Each tool has a name, a description and a defined set of inputs, which is why the model can use it correctly without you specifying every field. ## What does that look like in practice? Say you type this into Claude Desktop with Shager connected: ```text How many accounts are in the "Southwest" group for Rivera Auto, and which of them got the most clicks from last week's service-special posts? ``` Behind the scenes, the assistant calls tools in sequence: ```text list_workspaces find "Rivera Auto" list_groups find "Southwest" and its accounts get_analytics last week, clicks per account and per post list_posts match posts to the "service-special" campaign ``` Then it answers in plain language. You did not open a dashboard or export a spreadsheet. The same mechanism lets the assistant create drafts with `create_post`, request client approval with `request_approval`, or upload a video with `upload_media_from_url`. ## Where is the human in all this? This is the part marketers should care about most. The MCP specification says that for trust and safety [there should always be a human in the loop with the ability to deny tool invocations](https://modelcontextprotocol.io/specification/2025-06-18/server/tools), and recommends that applications show which tools are available and ask for confirmation on sensitive operations. Clients differ in how they implement this, so check how yours asks for permission before you rely on it. The vendor side matters as much. A good marketing platform does not rely only on the assistant asking politely. Shager's API keys carry scopes, `read`, `write` and `publish`, so you can give an assistant a key that can draft but cannot publish. Every call is logged in an audit trail. Our article on [human approval for agent posts](/en/blog/human-approval-for-agent-posts) covers how to set that up. ## How do you connect an assistant to an MCP server? For remote servers, the assistant connects over the web. The specification defines [Streamable HTTP](https://modelcontextprotocol.io/specification/2025-06-18/basic/transports) as the standard transport for this, and Shager's server uses it with an API key passed in an `Authorization` header. In Claude Code, for example, the [documented command](https://code.claude.com/docs/en/mcp) for a remote server with a bearer token looks like this: ```bash claude mcp add --transport http shager https://app.shager.ai/api/mcp \ --header "Authorization: Bearer shgr_live_your_key_here" ``` Other clients use a settings screen or a config file. We have step-by-step guides for [Claude Code](/en/blog/connect-shager-to-claude-code), [Cursor](/en/blog/connect-shager-to-cursor) and the other major clients. One limitation to know: some assistants only accept MCP servers that sign in with OAuth rather than an API key. Shager's OAuth sign-in for MCP is coming; until then, those clients need to wait or use the REST API from code. Our page on [Shager and ChatGPT](/en/blog/shager-and-chatgpt) explains the current options. ## What should you ask a marketing vendor about MCP? When you evaluate a tool for agent use, these questions separate a real integration from a checkbox: 1. **Is there a remote MCP server, and which transport does it use?** A hosted server you connect by URL is far easier than one you have to install and run locally. 2. **Which actions are exposed as tools?** Read-only access is useful for reporting but cannot run distribution. Look for create, schedule, approval and analytics actions. 3. **Can I limit what an agent may do?** Ask about key scopes and whether publishing can be withheld. 4. **Is there an audit log of agent actions?** You need to know what an agent did, when and with which key. 5. **Is there a documented REST API too?** An OpenAPI description, such as [Shager's](https://app.shager.ai/api/v1/openapi.json), lets developers build on the same operations from code. 6. **Can an agent discover and register by itself?** Some platforms, Shager included, let an agent create a sandbox and wait for a human to claim it, which makes trials much faster. ## What MCP does not do MCP does not make an assistant good at marketing. It gives the assistant hands, not judgment. Your brief, your brand rules and your review process still decide whether the output is worth publishing. It also does not bypass any network's rules: a platform that publishes through official APIs keeps doing so whether a person or an agent pressed the button. ## FAQ ### Do I need to be technical to use MCP? Not for day-to-day use. Connecting a server is a one-time setup, usually a URL and a key. After that you work in plain language and review what the assistant proposes. ### Is MCP specific to one AI company? No. It is an open standard supported by many clients, including Claude, ChatGPT, Visual Studio Code and Cursor, according to the [MCP documentation](https://modelcontextprotocol.io/docs/getting-started/intro). ### Is it safe to let an assistant act in my publishing tool? It is as safe as the limits you set. Use a key without publish rights at first, keep drafts as the default, and review the audit log. Expand access only once you trust the output. If you want to see MCP working with real publishing tasks, the [agent entry point](/en/agents) has the server address and setup for each client. Connect it in draft mode and ask it a question about your accounts first. --- Source: https://shager.ai/en/blog/mcp-explained-for-marketers # One Agent, Twelve Clients: Keeping Brands, Accounts and Links From Bleeding Into Each Other _2026-09-29 · How an agency runs one AI agent across many clients in Shager: a workspace per client, per-client context folders, naming rules and guards against cross-posts._ One agent can serve many clients safely if every client lives in its own Shager workspace, every task starts by resolving and naming the workspace, and the client's voice, facts and rules live in a separate context folder the agent loads per session. The danger is not that the agent is incapable. It is that a single key can see every workspace in the organization, so the separation has to come from structure and habit. The failure mode everyone fears is posting client A's offer on client B's pages. That mistake is not unique to agents; human operators make it too. The fixes below catch it either way. ## Why a workspace per client? In Shager, a workspace is a client or a brand. Every connected account, account group, post and tracked link lives inside exactly one workspace. Nothing crosses workspace lines by accident: a `create_post` call names one `workspace_id`, and the channels and groups it targets come from that workspace's own lists. Creating one is a single call. The fields are `name`, an IANA `timezone` (default `Asia/Jerusalem`) and `approval_required`, which forces client approval before anything in that workspace can be scheduled. ```json { "tool": "create_workspace", "arguments": { "name": "Aurora Furniture", "timezone": "Europe/London", "approval_required": true } } ``` Setting `approval_required` per client is the right granularity. Some clients want to see every post. Others signed off on a content plan and do not want twenty approval emails a week. The agent does not need to remember which is which, because the workspace enforces it. An agent in an unclaimed sandbox can create up to five workspaces, which is enough to set up a pilot with a few clients before a human claims the organization. The flow is in [agent self-signup and claim](/en/blog/agent-self-signup-and-claim). ## Getting each client's accounts in without passwords For each workspace, the agent calls `create_connect_link` with a `label` naming who it is for. The client opens the link, signs in to Facebook, Instagram or YouTube themselves, picks the accounts, and those accounts appear in `list_channels` for that workspace only. No Shager account for the client, no shared passwords. ```bash curl -s https://app.shager.ai/api/v1/workspaces/ws_aurora/connect-links \ -H "Authorization: Bearer $SHAGER_API_KEY" \ -H "Content-Type: application/json" \ -d '{"label":"Aurora marketing manager"}' ``` Connect links require a claimed organization. [Client connect links](/en/blog/client-connect-links) covers what the client sees and what to send them with the link. ## The context folder: where each client's brain lives The workspace separates data. It does not separate knowledge. The agent's understanding of Aurora's tone, prices and forbidden phrases has to live somewhere, and if it lives in one long instruction file with twelve clients in it, it will leak. My structure, for Claude Code or Codex: ```text agency/ CLAUDE.md # agency-wide hard rules, no client facts clients/ aurora/ CLAUDE.md # workspace name, voice, facts, do-not-say list brief-2026-w40.md crm/leads.csv beacon-dental/ CLAUDE.md ... ``` Claude Code loads `CLAUDE.md` files hierarchically, and files in subdirectories are loaded when Claude works in those directories, as its [memory documentation](https://code.claude.com/docs/en/memory) describes. Starting a session inside `clients/aurora/` gives the agent the agency rules plus Aurora's file, and nothing about Beacon Dental. Codex has a similar hierarchy with [`AGENTS.md`](https://developers.openai.com/codex/guides/agents-md), concatenated from the project root down to the working directory. The first line of each client file is the most important one: ```text Shager workspace: "Aurora Furniture". Act on this workspace only. If any tool call would use a different workspace_id, stop and ask. ``` ## Guards that catch the cross-posting mistake Structure reduces risk. These habits close the rest of the gap. 1. **Resolve and echo.** Every task begins with `list_workspaces`, resolves the client by name, and prints the name and ID before the first write. A human skimming the transcript sees "Aurora Furniture (ws_aurora)" and can stop it. 2. **One client per session.** Do not ask an agent to "do this week for Aurora and Beacon." Two sessions, two folders. The marginal cost is nothing and context stays clean. 3. **Labels with the client name.** Every `create_post` carries a `label` such as "Aurora w40 sofa sale". In `list_posts` and in the dashboard, a wrong label in the wrong workspace stands out immediately. 4. **Campaign per client.** The `campaign` field becomes `utm_campaign`. Prefix it with the client slug (`aurora-sofa-sale`), so a misplaced post also shows up as an odd row in the client's analytics. 5. **A separate review pass.** A reviewer session with read-only tools checks drafts against the client's do-not-say list before anything is approved. The prompt is in [prompts for a content agent](/en/blog/prompts-for-a-content-agent). ## Should each client have its own API key? Keys in Shager belong to the organization and carry scopes: `read`, `write` and `publish`. A key does not limit which workspaces it can reach. So a key per client does not create a hard wall, but it still helps in two ways. Revoking one key does not stop work on the others, and the audit log of agent calls at the agents dashboard is easier to read when each client's sessions run on their own key. What I would not do is give every client session a `publish` key by default. Most sessions draft. The scheduling step can run with a different key that a human controls. The scope model is explained in [API keys, scopes and audit](/en/blog/api-keys-scopes-and-audit). ## Groups inside a client Within a workspace, account groups let the agent target a set of accounts in one field. A franchise client might have groups by region, by language or by store format. `create_group` takes a `name` and `channel_ids`; `create_post` accepts `group_ids` and adds every active channel in those groups. Groups belong to a workspace like everything else, so the agent should always list them inside the client's workspace rather than reuse IDs from memory. ## Capacity and plans Shager plans are priced by the number of connected accounts across the organization, with API, MCP access and unlimited users on every plan. For an agency running a dozen clients, the account count is the number to watch, not the number of agents or seats. The tiers are on the [pricing page](/en/pricing). ## FAQ ### Can two agents work on the same client at once? Yes, technically. Both see the same workspace and both can create drafts. In practice, give each a clear lane: one drafts, the other reviews, or one handles video and the other text posts. Two agents both drafting the same week will produce duplicate content. ### What if a client manages their own posts in Shager too? They can be added as users in your organization, since every plan includes unlimited users. Make sure the agent calls `list_posts` before drafting, so it sees what the client has already scheduled and does not stack posts on the same day. ### How do I offboard a client? Stop the agent's work in that workspace, cancel any scheduled posts with `cancel_post`, and have the client disconnect their accounts. Archive the context folder outside the agent's working directory so it is not loaded by accident later. ## Where to go next Set up the folder structure first, even with two clients. It is much harder to separate twelve clients' knowledge after the fact than to start clean. The [agent entry point](/en/agents) has the connection details for every client you will need. --- Source: https://shager.ai/en/blog/one-agent-many-clients # Per-Account Lead Attribution: UTMs, Short Links and the First Comment _2026-09-26 · A practical guide to attributing leads to each page and profile: a consistent UTM scheme, one short link per account, first-comment links, and CRM handoff._ An agency that runs the same campaign across forty pages eventually gets one question from the client: "Where did the leads come from?" If the answer is "social," it isn't worth much. The client wants to know which location, which page and which post produced inquiries, so they can decide where to spend. That answer isn't built in the report. It's built when the link is created, before the post goes out. This guide walks through account-level attribution from the link all the way to the lead record in the client's CRM. ## Why "traffic from Facebook" isn't enough Analytics tools can usually tell a visitor came from Facebook or Instagram. They can't tell which Page, because every Page shares the same referring domain. On top of that, some in-app clicks arrive with no referrer at all and get filed as direct traffic. The result: forty pages, one blended line in the report, and no way to say which page has an audience that actually converts. To split it, every link has to be tagged before it ships. ## Layer one: a consistent UTM scheme per account UTM parameters are additions to a URL that analytics tools like Google Analytics read and attach to the session. Google documents the supported parameters in its [guide to collecting campaign data with custom URLs](https://support.google.com/analytics/answer/10917952). ### A workable structure | Parameter | What goes in it | Example | |---|---|---| | utm_source | The network | facebook | | utm_medium | Traffic type | social | | utm_campaign | Campaign name | spring-sale-2026 | | utm_content | Account identifier | location-denver | Using utm_content for the account is a practical choice. Source and medium stay clean so you can compare networks, campaign lets you compare campaigns, and content splits by page. Some agencies put the account ID in utm_term or fold it into the campaign name. Which one you pick matters less than picking one and sticking to it. ### Rules that prevent broken reports 1. **Lowercase, no spaces.** Values are case sensitive; "Facebook" and "facebook" count as two sources. 2. **Stable account IDs.** Not "Denver Store" one week and "denver" the next. 3. **One central list of IDs** that everyone works from. 4. **Never hand-build them.** UTMs typed manually per post break within a week. Generate them from account settings. ## Layer two: one short link per account UTMs alone aren't enough, for two reasons. First, they only measure what the analytics tool sees. Visitors who decline cookies, ad blockers and privacy-focused browsers can make a share of visits disappear. The analytics number is an indicator, not a full count. Second, a long URL with four parameters looks bad in a post and puts people off. A dedicated short link per account fixes both. Each click is counted on the link service's server before the redirect, independent of cookies on the site, and the link itself is short and clean. With a separate link for every account, you have a click count per page even when the client's analytics setup is incomplete. ### What to check in a link service 1. It preserves UTM parameters on the final destination 2. It can generate a link per account automatically, not one at a time 3. It filters bot traffic and link-preview fetches 4. Who owns the domain and the click data if you switch tools ## Layer three: the link in the first comment Many business pages put the link in the first comment rather than in the post body, keeping the post clean and pointing the CTA to the comment. Treat this as a style choice to test, not a rule. No network has officially stated that it improves reach, so measure what works for your audience. A few things to know: 1. **Instagram doesn't make links in captions or comments clickable.** There, the link belongs in the bio, a Story link sticker or a link-in-bio page. First-comment links are mainly useful on Facebook Pages and YouTube. 2. **The comment has to go out right after the post**, or the first wave of viewers won't find the link. 3. **Use that account's own short link in the comment**, with its UTMs. Otherwise every lead from comments blends together. ## The step most agencies skip: carrying the source into the lead Clicks aren't leads. To know how many inquiries each account produced, the source data has to land on the lead record itself. ### How to do it 1. **Hidden form fields**: on the landing page, add hidden fields for utm_source, utm_campaign, utm_content and so on, populated from the URL. 2. **Persist across the visit**: if the visitor browses a few pages before converting, keep the parameters (for example in a first-party cookie, subject to your privacy policy and any required consent). 3. **CRM mapping**: make sure the fields map to dedicated CRM properties, not a free-text notes field. 4. **Manual test**: submit a test lead from one link in each account group and confirm it arrives with the right source. ### What about calls and messaging apps Phone calls and WhatsApp messages don't pass through a form. You can narrow the gap with a prefilled message in the WhatsApp link that includes a short account code, or with separate tracking numbers for larger campaigns. It's imperfect, but better than guessing. ## What a useful client report looks like With all three layers connected, the client gets a simple table: | Account | Posts | Clicks (short link) | Sessions (analytics) | Leads (CRM) | |---|---|---|---|---| | Denver | ... | ... | ... | ... | | Boulder | ... | ... | ... | ... | The gaps between columns are information in their own right. Many clicks but few sessions suggests a landing page or consent problem. Many sessions but few leads points at the offer or the form. ## Pre-launch checklist for a measurable campaign 1. A written UTM convention the whole team follows 2. A stable ID for every account 3. Links generated automatically per account 4. Short links preserve UTMs at the destination 5. First-comment links use that account's own short link 6. Landing page hidden fields map into the CRM 7. At least one test lead per account group verified end to end 8. A plan for phone and messaging-app inquiries ## Wrapping up Account-level attribution isn't a reporting-tool problem. It's the result of discipline: one convention, links generated automatically, and source data that travels from the click to the CRM. An agency that holds this line can show the client exactly which pages drive business, and stop arguing about impressions. In Shager this is part of publishing itself: each account automatically gets its own UTM tags and a Shager short link, the link can go out in the post's first comment, and clicks are counted per account so you can line them up against the leads that came in. --- Source: https://shager.ai/en/blog/utm-per-account-lead-attribution # The Weekly Client Report, Written by an Agent Every Monday Before You Wake Up _2026-09-25 · Build a weekly client report that an agent compiles from Shager: what was published, what failed, clicks per account and post, and how to join it to CRM leads._ An agent can write a client's weekly distribution report by pulling three things from Shager: the posts published in the week and their per-account outcome, clicks per account and per post from `get_analytics`, and the list of anything that failed. It then joins those clicks to leads from the client's CRM using the `utm_content` value that identifies each account. Run it on a schedule with a read-only key, and the report is waiting in a folder on Monday morning. The part that takes thought is not the code. It is deciding what the client actually needs to see, and being honest about what the numbers measure. ## What should a weekly distribution report contain? Four sections are enough. Anything else belongs in the monthly review. 1. **Delivery.** How many posts went out, to how many accounts, and which accounts failed. Clients rarely ask about this until something goes missing, and then it is the only thing they ask about. 2. **Clicks by account.** Which pages, branches or channels sent people to the site. This is the section that changes budgets. 3. **Clicks by post.** Which content worked, across all accounts. 4. **Actions.** What the client needs to do: reconnect an account, approve next week's drafts, send missing assets. Notice what is missing: reach, impressions, likes. Shager measures clicks on its own tracked links, per account and per post. It does not claim to be a social analytics suite, and the report should not pretend otherwise. ## The data calls For a client workspace, the agent runs this sequence. The tool names are the real MCP tools; the REST equivalents are in the [OpenAPI document](https://app.shager.ai/api/v1/openapi.json). 1. `list_workspaces` to resolve the client's workspace by name. 2. `list_posts` with `status` set to `PUBLISHED`, then again with `PARTIALLY_PUBLISHED` and `FAILED`. `limit` goes up to 100. 3. `get_post` for each post from the week, to get per-account state, live URLs and error messages. 4. `get_analytics` with `from` and `to` covering the week. 5. `list_channels`, to map channel IDs to readable account names and to spot accounts whose connection status has changed. The analytics call over REST: ```bash curl -s "https://app.shager.ai/api/v1/workspaces/ws_example/analytics?from=2026-09-14T00:00:00%2B03:00&to=2026-09-20T23:59:59%2B03:00" \ -H "Authorization: Bearer $SHAGER_READ_KEY" ``` Two details in that URL bite people. The `+` in the offset must be encoded as `%2B` in a query string, or the server reads it as a space. And the week boundaries should be computed in the client's time zone, not the server's. If `from` is omitted, `get_analytics` defaults to the last 30 days, which is not what a weekly report wants. ## Clicks are not leads, so join them Shager gives every account its own short link and UTM tags, with `utm_content` identifying the account. That is what makes the join possible. The CRM records leads with the UTM values captured on the landing page form; the agent matches them to Shager's per-account click counts on the same `utm_content`. The resulting table is the heart of the report: | Account | Posts | Clicks (Shager) | Leads (CRM) | Note | |---|---|---|---|---| | Aurora Downtown | 4 | ... | ... | | | Aurora Northside | 4 | ... | ... | reconnect needed | The gaps between columns are information. Many clicks and no leads is a landing page or offer problem, not a distribution problem. Our older guide on [per-account lead attribution](/en/blog/utm-per-account-lead-attribution) covers the form fields and CRM mapping that make the leads column trustworthy, and [measuring leads from agent content](/en/blog/measuring-leads-from-agent-content) covers the agent side. If you do not have CRM access, the report still works with clicks only. Say so in the report header. A report that labels clicks as "results" is how agencies lose trust a quarter later. ## Running it unattended with Claude Code Claude Code can run non-interactively with `claude -p`, as described in its [headless documentation](https://code.claude.com/docs/en/headless). That makes a weekly report a cron job. First, a project folder for reports with a `.mcp.json` that reads the key from the environment. Claude Code's [MCP documentation](https://code.claude.com/docs/en/mcp) supports `${VAR}` expansion in headers: ```json { "mcpServers": { "shager": { "type": "http", "url": "https://app.shager.ai/api/mcp", "headers": { "Authorization": "Bearer ${SHAGER_READ_KEY}" } } } } ``` Then the instructions, saved as a skill so the logic lives in one file rather than in a crontab line. Claude Code loads project skills from `.claude/skills//SKILL.md`, per its [skills documentation](https://code.claude.com/docs/en/skills): ```markdown --- name: weekly-report description: Compile the weekly distribution report for one client workspace from Shager. Use when asked for a weekly client report. --- The argument is the client workspace name: $ARGUMENTS 1. Resolve the workspace with list_workspaces. Read its timezone. 2. Compute last Monday 00:00 to Sunday 23:59:59 in that timezone, with offsets. 3. Collect posts with list_posts (PUBLISHED, PARTIALLY_PUBLISHED, FAILED) and keep those published in the window. Call get_post for each. 4. Call get_analytics for the window. Map channel ids to names with list_channels. 5. If crm/.csv exists, join leads on utm_content. 6. Write reports//.md with four sections: Delivery, Clicks by account, Clicks by post, Actions. Use tables. No adjectives about performance; numbers and one plain sentence per section. 7. Never call any tool that creates, schedules or cancels anything. ``` And the scheduled command, which pre-approves only the read tools and file writing: ```bash cd ~/agency-reports && claude -p "/weekly-report Aurora" \ --allowedTools "mcp__shager__list_*,mcp__shager__get_*,mcp__shager__whoami,Write" \ --output-format json > logs/aurora-$(date +%F).json ``` The allow rule syntax with a `mcp____` prefix and a trailing glob is documented in Claude Code's [permissions reference](https://code.claude.com/docs/en/permissions). Anything not on that list will not be auto-approved in an unattended run. ## Why a read-only key matters here The skill tells the model not to write. The key makes it impossible. Create a separate key with only the `read` scope for reporting at the agents dashboard, and use it nowhere else. If that key ever leaks, the worst outcome is someone reading click counts. We go through the full scope model in [API keys, scopes and audit](/en/blog/api-keys-scopes-and-audit). Every call the reporting agent makes also shows up in the audit log on that dashboard, which is a good way to confirm on the first few Mondays that it calls what you expect and nothing more. ## Writing the narrative part Let the agent write one or two sentences per section, but constrain it. Without rules, models describe a 4 percent change as "a significant increase." My instruction is blunt: state the number, compare it to the previous week if available, and say nothing about cause unless the data shows it. If a branch page had zero clicks because its connection expired on Tuesday, that is a cause the data shows. "Audience fatigue" is not. ## FAQ ### Can the agent send the report to the client directly? It can if you give it an email tool, but I would not on day one. Have it write the file, review a few weeks of output, then automate delivery. The report is the client's view of your work, and a wrong number sent automatically costs more than the time saved. ### Does get_analytics include leads? No. It returns clicks on Shager's tracked links, per account and per post, in a date range. Leads come from the client's CRM or form tool, matched on `utm_content`. The report should keep the two sources visibly separate. ### How far back can the report look? `get_analytics` accepts any `from` and `to` you send, with a default of the last 30 days when `from` is omitted. For month-over-month comparisons, run the same skill with a different window rather than storing past reports as the source of truth. ## Where to go next If you do not have a key yet, the [agent entry point](/en/agents) shows how to create one or let an agent sign itself up. Start with one client, read three Mondays of reports yourself, and only then add the rest. --- Source: https://shager.ai/en/blog/weekly-client-report-by-agent # Client Connect Links: Access to Client Social Accounts Without Passwords _2026-09-23 · How agencies get publishing access to client Facebook, Instagram and YouTube accounts with a connect link: no shared passwords and no Shager account needed._ A client connect link is a link the agency sends to a client so the client can connect their own Facebook Page, Instagram professional account or YouTube channel to the agency's workspace. The client signs in directly with the network and grants access; they never share a password, and they do not need a Shager account. For agencies running AI agents, it also means an agent can prepare the onboarding while the client stays in control of their credentials. Onboarding is where agency relationships often start badly. Week one is spent on calls about who is admin on which Page, a password sent over chat, and a two-factor code that went to someone's old phone. Connect links exist to make that week a single message. ## Why are shared passwords a problem, even with trusted clients? The security argument is old and well documented. The OAuth 2.0 specification, [RFC 6749](https://datatracker.ietf.org/doc/html/rfc6749#section-1), opens by listing what goes wrong when third parties hold a user's password: they have to store it, they get broader access than they need, and the owner cannot revoke one third party's access without changing the password for everyone. For an agency there are practical problems on top. Passwords leave with departing staff. Logins from new devices and locations can trigger network security checks that lock the client out. And when something goes wrong, nobody can tell who did what, because everyone used the same login. Delegated authorization solves these. Google's documentation describes how its APIs use OAuth 2.0 and that [access tokens are valid only for the operations and resources in their scope](https://developers.google.com/identity/protocols/oauth2). The client approves specific access, and can withdraw it from their own account settings. ## How does a connect link work, step by step? From the client's side the flow is short: 1. The client opens the link the agency sent. 2. They choose the network: Facebook, Instagram or YouTube. 3. They sign in on the network's own page, not on a form run by the agency. 4. They pick which Pages, accounts or channels to connect and approve the permissions. 5. The connected accounts appear in the agency's workspace for that client. From the agency's side, there is nothing to type on the client's behalf. The accounts show up as channels, ready to be grouped and targeted. ## How does an agent create connect links? Shager exposes this as the `create_connect_link` tool on its MCP server and as a REST operation. An onboarding sequence an agent can run on day one: ```text whoami confirm the key belongs to the agency organization create_workspace "Copperline Coffee" create_connect_link for the new workspace, returns the link to send (wait for the client to complete the flow) list_channels confirm which accounts were connected create_group "All cafes", "Instagram only", by region if useful ``` A prompt to the agent: ```text New client: Copperline Coffee, 14 cafes, Facebook Pages and Instagram. Create a workspace, create a connect link, and draft a short email to their marketing lead explaining what the link does in plain language. Mention that they will sign in on Facebook and Instagram directly and won't share any password with us. Do not send the email; give it to me. Tomorrow, check which channels are connected and propose groups by city. ``` Note one constraint. A self-registered agent sandbox cannot create connect links until a human claims it. That is intentional: requesting access to someone else's accounts is a step that should trace back to an accountable person. Our article on [agent self-signup and claim](/en/blog/agent-self-signup-and-claim) explains the claim step. ## What should the message to the client say? Clients are rightly wary of links asking for access to their social accounts. The note that accompanies the link does a lot of work. Keep it short and specific: ```text Hi Dana, Here is the link to connect Copperline's Facebook and Instagram accounts to our publishing workspace: You'll sign in on Facebook and Instagram directly, choose which cafe accounts to connect, and approve publishing access. We never see your password. You can remove our access at any time from your account settings. It takes about five minutes. If a cafe account is missing from the list, it usually means your login doesn't have full control of it; tell us and we'll help. ``` The last paragraph prevents the most common support ticket. A client can only connect accounts their own login has sufficient rights on, so multi-location brands where different managers own different Pages may need more than one person to open the link. ## How does this fit with network-native partner access? Networks have their own tools for agency access, such as sharing assets between business portfolios in Meta's business tools. Those are useful for advertising and team management, and many agencies use both. A connect link is narrower: it grants the publishing platform the access it needs to publish, schedule and read results for those accounts. For a client who just wants posts to go out under their brand, it is usually the simpler path. ## What happens when access needs to change? Three situations come up regularly. When a client adds a location, send the same kind of link again and they connect the new account. The agent can then add it to the right groups. When a client leaves, they remove access from their side, and the agency removes the channels from the workspace. There are no passwords to rotate. When a token stops working, which can happen after a password change or a permissions change on the network side, the channel needs reconnecting. Google's OAuth documentation notes that applications must expect that [a granted refresh token might no longer work](https://developers.google.com/identity/protocols/oauth2). A weekly agent check with `list_channels` against the client's expected account list, plus a look at any failed posts with `get_post`, catches this early. ## What does this have to do with agents? Agent-run distribution depends on clean access. If the agency's connection to forty client Pages relies on a shared password, the agent inherits all the fragility of that arrangement. With client-granted connections, each channel is a clear permission that can be listed, grouped, audited and revoked. That is the foundation the rest of the [agency operating model](/en/blog/agency-operating-model-with-agents) builds on. ## FAQ ### Does the client need a Shager account to use a connect link? No. The client opens the link, signs in with the network and approves access. They do not create a Shager account or share a password. ### Which networks do connect links support? Facebook Pages, Instagram professional accounts and YouTube channels, which are the networks live in Shager today. TikTok and LinkedIn are in development. ### Can an AI agent send connect links to clients by itself? An agent with a claimed key can create the link. We recommend that a person sends it with a personal note, because a request for account access should come from someone the client knows. To try it, create a workspace for your next client and generate a link from the dashboard, or have your agent do it through the MCP server described on the [agent entry point](/en/agents). --- Source: https://shager.ai/en/blog/client-connect-links # Keeping One Brand Voice Across Dozens of Social Accounts _2026-09-22 · How agencies managing dozens of pages and profiles keep one consistent brand voice without duplicating posts: style guides, templates, groups and QA._ With one account, brand voice lives in the head of whoever writes the posts. With thirty franchise locations, twenty dealer pages or fifty profiles across a holding company's brands, it can't live there anymore. Every writer brings their own habits, every client asks for "one small tweak," and a few months later the pages sound like five different businesses. The common shortcut, pasting the same post into every account, causes a different problem. Identical content across dozens of pages looks lazy to the audience and can hurt distribution. The goal isn't identical text. It's an identical **voice**. This article is about the difference between the two, and how to build a process that holds it in place. ## Voice is not a text template Brand voice is a set of decisions: how you address people, how formal you are, which words you use and avoid, how much humor is allowed, what a call to action sounds like. Two posts can share no sentences and still sound like the same brand. Two nearly identical posts can feel off if one was written in a rush. It helps to separate three layers: 1. **Voice**: fixed at the brand level. It doesn't change between accounts. 2. **Message**: fixed at the campaign level. Same offer, same core benefit, same proof point. 3. **Wording**: varies by account, network and audience. This is where the city name, the location manager, a local detail or a different angle goes. Once your team sees these layers clearly, you can produce variations without losing the identity. ## A style guide people actually use Most brand books are written once, exported to PDF and forgotten. A useful guide for an agency publishing at volume is short, practical and available at the moment of writing. ### What it must cover 1. **Form of address**: "you" and direct, or more distant? First-person plural for the brand, or third person? Decide once. 2. **Formality**: one example of a sentence that is "us" and one that isn't beats a page of adjectives. 3. **Preferred and banned words**: "customers," not "consumers"; "price," not "attractive pricing." 4. **Length and structure**: lines before the CTA, lists or no lists, emoji policy. 5. **Approved calls to action**: a closed list of three to five phrasings. This is where brands drift fastest. 6. **What you can't promise**: prices, outcomes, or claims the client's industry or regulator won't allow. ### Where it should live Not in a shared drive. Put it where the post gets written: as a pinned note in your scheduling tool, inside the template, or as standing instructions for your writing assistant. If people have to go looking for the guide, they won't read it. ## Templates with variables, not copy-paste When one campaign goes out to dozens of accounts, a template with variables balances consistency against variety. Instead of one block of text, you write a fixed structure with slots: > Open on the audience's problem → core campaign benefit → local detail (city, location, manager's name) → CTA from the approved list Every post comes out different enough not to read as a duplicate, while the structure and tone stay the same. Prepare two or three alternative openings per campaign and rotate them across accounts. ### What to avoid 1. Swapping only the city name and leaving the rest identical. That's still duplication. 2. Letting every writer "improve" the template freely. Small improvements add up to drift. 3. One template for every network. A Facebook Page post, an Instagram Reel caption and a YouTube description each need different wording. ## Group accounts by audience, not just by client Agencies naturally organize accounts by client. That's right for billing and reporting, but not always for writing. A client with twenty locations may span very different markets, and some will need a slightly different tone. Build account groups around what changes the wording: region, audience type, language or network. Then you write one variation per group instead of one per account, and stay consistent within each group. ## AI writing as a gatekeeper, not a replacement AI writing tools help a lot at volume, especially for generating variations and adapting copy per network. Without clear instructions, though, they drift toward a generic style that sounds the same for every brand. Rules that work: 1. **Feed the style guide in as standing instructions**, with good and bad examples. 2. **Ask for variations of an approved post**, not a fresh post from scratch. The message stays put; the wording changes. 3. **Check language quality**, especially in non-English markets. Translated-sounding copy gives automated text away fastest. 4. **Keep a human in the loop**, at least for the first post of every campaign. ## Quality control that doesn't block the calendar At volume you can't review every post with the same depth. You can review in layers: | Stage | What gets checked | Who | |---|---|---| | Campaign template | Message, tone, CTA, claims | Brand lead or client | | Variations | Fit to group, language, no full duplicates | Senior writer | | Pre-send sample | 3 to 5 random posts per group | Whoever schedules | | After publishing | Odd comments, typos, broken links | Community manager or client | The key move: the client approves the template and the direction, not each of fifty variations. That saves days and puts consistency where it matters most. ## Pre-launch checklist for a multi-account campaign 1. A short style guide is available inside the tool where posts are written 2. Message and CTA are approved at campaign level 3. At least two openings and three body variations exist 4. Accounts are grouped by audience or region 5. Local details (city, address, phone) are checked against a reliable source 6. Captions are adapted per network 7. A sample from each group has been reviewed before scheduling 8. Someone owns comment monitoring on launch day ## Wrapping up A consistent voice across dozens of accounts doesn't come from publishing the same text over and over. It comes from clear decisions documented where people write, templates that leave room for variety, and review focused on what actually matters. An agency that sets this up once saves hours of corrections on every campaign after. Shager is built for this kind of work: account groups so you write one variation per audience, an AI writing assistant that follows your instructions, and client approval links that show the campaign to the client before it goes out to every account. --- Source: https://shager.ai/en/blog/brand-consistency-across-many-accounts # Six Prompts That Make a Content Agent Safe to Run on Client Accounts _2026-09-22 · Copyable prompts for an AI content agent working through Shager: standing rules, weekly drafts, caption variation, scheduling, review and failure triage._ The prompts that matter for a content agent are not clever one-liners. They are a standing instruction block that sets hard rules once, plus a handful of task prompts that each do one job: draft the week, vary captions, schedule, review before anything goes out, and triage failures. Below are six of them, complete and ready to paste, written for an agent connected to Shager over MCP. They are written for Claude Code and Claude Desktop and should work in Codex or Cursor with small changes, since the tool names come from the MCP server, not from the client. ## How these prompts are built Two techniques carry most of the weight. Anthropic's [prompting best practices](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices) recommend separating instructions, context and inputs with XML tags so the model does not confuse a client brief with an instruction, and using concrete examples to pin down format and tone. Both show up below. The other principle is mine: every prompt names the exact Shager tools it may call. An agent told "publish this" will find a way. An agent told "call `create_post` without `schedule_at`, then stop" will do exactly that. Replace anything in angle brackets before use. ## Prompt 1: standing instructions This goes into the agent's persistent context: a [`CLAUDE.md` file](https://code.claude.com/docs/en/memory) for Claude Code, project instructions in Claude Desktop, an [`AGENTS.md` file](https://developers.openai.com/codex/guides/agents-md) for Codex. Anthropic's memory docs note that shorter, specific instructions are followed more consistently, so keep only rules you actually need. Each rule here addresses a mistake agents make when nobody tells them otherwise. It is read once per session and saves you from repeating rules in every task. ```text You are the content distribution agent for . You work through the Shager MCP server. Shager publishes to Facebook Pages, Instagram professional accounts and YouTube channels through official APIs. 1. Never publish or schedule unless the task explicitly says "schedule". Default to drafts: call create_post WITHOUT schedule_at. 2. Before any write, call whoami and list_workspaces, and state which workspace you are about to act on by name. If the task does not name a client, ask. 3. Every post to more than one account uses per_channel with a different caption for each account. Never send identical captions to multiple accounts. 4. Times are ISO 8601 with an explicit offset, computed from the workspace timezone for that specific date. Never guess an offset. 5. Never shorten stagger_seconds below the default [30, 90]. 6. Do not invent facts about the client: prices, opening hours, offers, dates. If the brief does not contain it, leave it out or ask. 7. If any tool returns an error, stop and report the error code and message. Do not retry more than once. 1. Short sentences. No hashtags unless the brief asks for them. 2. Facebook first comments may carry the link. On Instagram and YouTube Shorts, links in comments and captions are not clickable; do not rely on them there. 3. Write in the language of the account, not the language of the brief. End every task with a table: account name, network, what you did, post_id, status. Then one line: what a human needs to do next, if anything. ``` ## Prompt 2: draft the week from a brief This is the workhorse. The brief goes inside its own tag so the model treats it as material, not as orders. ```text Draft next week's posts for the client workspace "". 1. Call list_channels and list_groups for this workspace. Summarise the accounts by network and group before drafting. 2. For each media URL in the brief, call upload_media_from_url. For video, pass width, height and duration_ms; if you do not know them, ask me. 3. Plan posts for the week. Show me the plan as a table (day, topic, format, target group) and wait for "go". 4. After "go", call create_post once per planned post, as a draft, with: caption, group_ids, media_ids, per_channel (one caption per account), cta_url and campaign "", label " week post ". 5. Do not call schedule_post or request_approval. Report using the reporting table from your standing instructions. ``` The "wait for go" line in step 3 costs one message and catches most bad plans before they become forty drafts. ## Prompt 3: caption variation per account Use this when a single approved master caption must become many. It includes examples, because examples steer tone better than adjectives do. ```text Rewrite the master caption below for each account in the post in workspace "". Call get_post to read the accounts. 1. Keep every fact, offer and date exactly as in the master. Change wording, order and the opening line. 2. Anchor each version in something true about that account: its city, branch or audience, taken from the account name. Do not invent local details. 3. Same length as the master, within 20 percent. 4. No two versions may share the same first sentence. Master: "Our winter menu starts Sunday." Account "Cafe Lune Haifa": "Haifa, the soup is back. Winter menu from Sunday." Account "Cafe Lune Eilat": "Yes, even in Eilat. The winter menu lands Sunday." Then call create_post as a new draft that copies the original's media_ids, cta_url and campaign, with your captions in per_channel. Do not edit or cancel the original. Report the new post_id. ``` The method behind this prompt is covered in more depth in [caption variation per account with AI](/en/blog/caption-variation-per-account-with-ai). ## Prompt 4: schedule approved drafts This is the only prompt that touches the clock. It only works if the key has the `publish` scope, which a human grants. That is intended. ```text Schedule the approved drafts in workspace "". 1. Call list_posts with status APPROVED. Show me the list. 2. Read the workspace timezone. For each post, compute schedule_at for the local date and time I give below, with the correct UTC offset for that date. 3. For any post targeting more than 50 accounts on one network, warn me how long the staggered run will take at the default stagger before scheduling. 4. Call schedule_post for each. If one fails, stop and show the error. : ``` The reasoning behind the time rules is in [scheduling strategy for agents](/en/blog/scheduling-strategy-for-agents). ## Prompt 5: pre-flight review Run this as a separate pass, ideally in a fresh session, so the reviewer has not just written the drafts it is checking. ```text You are reviewing drafts, not writing them. Do not create, edit, schedule or cancel anything. Only call list_posts and get_post. In workspace "", review every post with status DRAFT or APPROVED. For each, check: 1. Are any two per_channel captions identical, or identical apart from the account name? 2. Does any caption contain a fact not present in this brief? 3. Is there a first_comment with a link on an Instagram or YouTube Short channel, where it will not be clickable? 4. Is a REEL or SHORT format set on media that is not vertical video? Output one table: post label, account, issue, suggested fix. If there are no issues, say so in one line. ``` A reviewer that cannot write is the cheapest safety layer you will build. It pairs well with the human gate described in [human approval for agent posts](/en/blog/human-approval-for-agent-posts). ## Prompt 6: failure triage Some accounts will fail on a large run. The question is how fast you hear about it and whether the agent makes it worse. ```text Check the result of post in workspace "". 1. Call get_post. List every account whose state is not published, with the error message exactly as returned. 2. Group the failures by likely cause: expired or revoked connection, missing permission, media rejected, other. 3. For connection problems, do not retry. Tell me which account owner needs a new connect link. If I confirm, call create_connect_link with a label naming that account. 4. Do not create a replacement post unless I ask. ``` ## A note on keys and context None of these prompts contain an API key, and none should. The key lives in the MCP client configuration or an environment variable. Pasting it into a prompt puts it into transcripts, logs and sometimes shared chat history. ## FAQ ### Do these prompts work with models other than Claude? The structure does. XML tags and explicit tool names help any capable model. You may need to adjust how the standing instructions are loaded, since each client has its own file or setting for persistent context. ### Why not let the agent schedule directly from the weekly draft prompt? Because the most expensive mistakes happen at the moment of publishing, and a separate prompt with a separately granted scope makes that moment deliberate. Drafting is cheap to undo. A post to sixty pages is not. ### How long should standing instructions be? As long as your hard rules require and no longer. If a rule is never violated in practice, it can probably go. If a mistake happens twice, it becomes a rule. ## Where to go next If your agent is not yet connected, the [agent entry point](/en/agents) shows the MCP address and the self-signup call. Start with prompts 1 and 2 on a single client, and add the others as the volume grows. --- Source: https://shager.ai/en/blog/prompts-for-a-content-agent # Shager REST API Quickstart: From a Fresh Key to a Tracked Post on 40 Accounts in Seven Calls _2026-09-19 · A working tour of Shager's REST API in curl and TypeScript: auth, workspaces, channels, media, per-account drafts, scheduling, status checks and clicks._ Shager's REST API lives at `https://app.shager.ai/api/v1`, authenticates with `Authorization: Bearer shgr_live_...`, returns every result as `{ "data": ... }` and every error as `{ "error": { "code", "message" } }`. A complete distribution run is seven calls: check the key, pick a workspace, list its channels, upload media, create a draft with per-account captions, schedule it, then read status and clicks. The machine-readable spec is the [OpenAPI 3.1 document](https://app.shager.ai/api/v1/openapi.json). Everything below runs as written once you set two environment variables. The same operations exist as MCP tools with the same names, so what you learn here carries over to Claude Code, Codex or Cursor. ## What do you need before the first call? A key. Either a human creates one at https://app.shager.ai/dashboard/agents with the scopes you need, or your agent creates a sandbox through [self-signup](/en/blog/agent-self-signup-and-claim). Scopes work like this: | Scope | Allows | |---|---| | `read` | `whoami`, listing workspaces, channels, groups and posts, reading a post, analytics | | `write` | Creating workspaces, groups, media, draft posts, connect links, approval requests, cancelling | | `publish` | Scheduling, including `create_post` with `schedule_at` | ```bash export SHAGER_API_KEY="shgr_live_your_key_here" export API="https://app.shager.ai/api/v1" ``` ## Call 1: who am I? ```bash curl -s "$API/me" -H "Authorization: Bearer $SHAGER_API_KEY" ``` ```json { "data": { "organization_id": "...", "organization": "Northwind Agency", "sandbox": false, "scopes": ["read", "write"] } } ``` If `sandbox` is true, scheduling and connect links are blocked until a human claims the key. If `publish` is missing from `scopes`, you can build drafts but not schedule them. Knowing this up front saves a confusing 403 later. ## Call 2: pick or create a workspace A workspace is usually one client or brand. ```bash curl -s "$API/workspaces" -H "Authorization: Bearer $SHAGER_API_KEY" curl -s -X POST "$API/workspaces" \ -H "Authorization: Bearer $SHAGER_API_KEY" -H "Content-Type: application/json" \ -d '{"name": "Summit Physio", "timezone": "Europe/London", "approval_required": true}' ``` Always set `timezone` (an IANA name) on creation. Schedule times are stored with their offset, and the workspace zone is how Shager shows them to humans. `approval_required: true` means posts must be approved by the client before they can be scheduled, which is a good default for new clients. Export the id from the response so the following commands work: ```bash export WS="the_workspace_id" ``` ## Call 3: list channels and groups ```bash curl -s "$API/workspaces/$WS/channels" -H "Authorization: Bearer $SHAGER_API_KEY" curl -s "$API/workspaces/$WS/groups" -H "Authorization: Bearer $SHAGER_API_KEY" ``` Each channel comes back with `id`, `network`, `name`, `handle`, `status`, the `formats` it supports, and `connected_by_client`. Groups return `id`, `name` and `channel_ids`. Groups are how you address forty accounts without listing forty ids; pass `group_ids` to `create_post` and every active channel in the group is included. If the workspace has no channels yet, create a connect link with `POST /workspaces/{workspace_id}/connect-links` and send it to the account owner. They connect Facebook, Instagram or YouTube themselves, with no Shager login. ## Call 4: upload media from a URL ```bash curl -s -X POST "$API/workspaces/$WS/media" \ -H "Authorization: Bearer $SHAGER_API_KEY" -H "Content-Type: application/json" \ -d '{ "url": "https://cdn.summitphysio.example/video/knee-mobility.mp4", "file_name": "knee-mobility.mp4", "width": 1080, "height": 1920, "duration_ms": 42000 }' ``` Shager downloads the file server side and returns `id`, `kind`, `mime_type` and `size_bytes`. For Reels, Shorts and Stories, pass `width`, `height` and `duration_ms` when you know them. That lets Shager check each network's format rules before a post is scheduled rather than failing at dispatch. ## Call 5: create a draft with per-account captions This is the call that matters. Here it is in TypeScript with plain `fetch`, including a small helper you'll reuse: ```typescript const API = "https://app.shager.ai/api/v1"; async function shager(method: string, path: string, body?: unknown): Promise { const res = await fetch(`${API}${path}`, { method, headers: { Authorization: `Bearer ${process.env.SHAGER_API_KEY}`, "Content-Type": "application/json", }, body: body ? JSON.stringify(body) : undefined, }); const json = await res.json(); if (!res.ok) { const err = new Error(`${res.status} ${json.error.code}: ${json.error.message}`); (err as any).status = res.status; throw err; } return json.data as T; } const WS = process.env.SHAGER_WORKSPACE_ID!; const mediaId = process.env.SHAGER_MEDIA_ID!; // the id returned by call 4 const channels = await shager>( "GET", `/workspaces/${WS}/channels`, ); const post = await shager<{ id: string; status: string }>("POST", `/workspaces/${WS}/posts`, { label: "Knee mobility, week 42", caption: "Three minutes a day for stiffer knees. Full routine in the video.", channel_ids: channels.map((c) => c.id), media_ids: [mediaId], format: "REEL", youtube_title: "3-minute knee mobility routine", youtube_privacy: "public", per_channel: channels.map((c) => ({ channel_id: c.id, caption: `${c.name}: three minutes a day for stiffer knees. Our physios show the routine.`, })), cta_url: "https://summitphysio.example/book", cta_text: "Book an assessment", campaign: "knee-mobility-oct", first_comment: "Book an assessment: https://summitphysio.example/book", stagger_seconds: [45, 120], }); console.log(post.id, post.status); // DRAFT ``` What each field earns you: 1. `per_channel` gives every account its own caption. In practice an agent writes these; the template above is a placeholder for that step, and the reasoning is in [avoiding spam blocks at scale](/en/blog/avoid-spam-blocks-when-posting-at-scale). 2. `format` is applied where the network supports it, and `SHORT` versus `REEL` is resolved per network otherwise. `youtube_title` and `youtube_privacy` only affect YouTube channels. 3. `cta_url` produces a separate short link and UTM set per account, with `utm_content` identifying the account. That's what [per-account lead attribution](/en/blog/utm-per-account-lead-attribution) is built on. 4. `stagger_seconds` sets a random pause between accounts on the same network. The default is `[30, 90]`. Without `schedule_at`, the result is a draft. Keep its id for the next calls with `export POST_ID="the_post_id"`. ## Call 6: approval or schedule If the workspace requires approval, send it to the client. The response includes an `approval_url` the reviewer opens without logging in: ```bash curl -s -X POST "$API/workspaces/$WS/posts/$POST_ID/approval" \ -H "Authorization: Bearer $SHAGER_API_KEY" -H "Content-Type: application/json" \ -d '{"reviewer_name": "Dana Ellis", "reviewer_email": "dana@summitphysio.example", "send_email": true}' ``` Once approved (or if approval isn't required), schedule it. This needs the `publish` scope, and `schedule_at` must be ISO 8601 with an offset: ```bash curl -s -X POST "$API/workspaces/$WS/posts/$POST_ID/schedule" \ -H "Authorization: Bearer $SHAGER_API_KEY" -H "Content-Type: application/json" \ -d '{"schedule_at": "2026-10-20T08:30:00+01:00"}' ``` Shager validates every destination against its network's rules at this point. If any account would reject the post, you get a 422 `rejected` with the reason, and nothing is queued. ## Call 7: check status and clicks ```bash curl -s "$API/workspaces/$WS/posts/$POST_ID" -H "Authorization: Bearer $SHAGER_API_KEY" curl -s "$API/workspaces/$WS/posts?status=SCHEDULED&limit=50" -H "Authorization: Bearer $SHAGER_API_KEY" curl -s "$API/workspaces/$WS/analytics?from=2026-10-01T00:00:00Z&to=2026-10-31T23:59:59Z" \ -H "Authorization: Bearer $SHAGER_API_KEY" ``` `get_post` returns one row per destination with `state`, `dispatch_at`, `published_at`, the live `url` and any `error`. Analytics returns `total_clicks`, `by_account` and `by_post`, counting clicks on Shager's tracked links with bot traffic excluded. To cancel a scheduled post that hasn't started publishing, `POST /workspaces/{workspace_id}/posts/{post_id}/cancel`. ## Which errors should your code handle? | Status and code | Meaning | What to do | |---|---|---| | 401 `unauthorized` | Header missing or malformed | Send `Authorization: Bearer shgr_...` | | 403 `forbidden` | Key lacks the needed scope | Draft instead, or ask a human for `publish` | | 403 `sandbox_unclaimed` | Unclaimed self-signup key | Surface the claim link to a human | | 404 `not_found` | Wrong workspace, post or channel id | Re-list; ids are per workspace | | 409 `not_scheduled` | Cancelling a post that isn't scheduled | Read the post status first | | 422 `rejected` | A network rule failed | Show the message; it names the problem | | 429 `rate_limited` | Over 120 requests per minute per key | Back off and retry | The rate limit rarely bites a well-designed client. One `create_post` covers hundreds of accounts, so you shouldn't need a call per account. ## FAQ ### Is there an SDK? Not a dedicated one. The OpenAPI 3.1 document works with standard generators if you want typed clients, and the API is small enough that a helper like the one above is usually all you need. A Shager CLI is coming. ### Are REST and MCP really the same? Yes. Each MCP tool maps to one REST operation with the same name, inputs, scopes, rate limit and audit logging. Use REST from scripts and services, and MCP from agent clients. The full tool list is on the [agents page](/en/agents). ### How do I post different text to Facebook and YouTube in the same post? Use `per_channel` with each channel's id and caption, and `youtube_title` for the YouTube title. One post object, many destinations, each with its own caption, format and first comment if you need it. ## Next step When this sequence runs cleanly by hand, wrap it into something an agent can repeat. [Building a Claude skill for Shager](/en/blog/build-a-claude-skill-for-shager) shows how to package these calls and the rules around them into a reusable skill. --- Source: https://shager.ai/en/blog/shager-rest-api-quickstart # Scheduling Strategy for Agents: Time Zones, Staggering and Not Flooding Forty Pages at 9:00 _2026-09-18 · How an AI agent should schedule posts across many accounts: ISO 8601 offsets, time zones and DST, stagger math, splitting groups across days, and safe cancels._ A good scheduling strategy for an agent comes down to three rules: always send times as ISO 8601 with an explicit offset computed from the client's time zone, let the platform stagger dispatch per account instead of firing everything at once, and split large account lists across separate posts and times rather than one giant run. Draft first, schedule as a separate step, and keep cancellation cheap. Everything below is about making those rules concrete, with the exact fields Shager expects. ## Why do agents get time wrong? Language models are bad at clocks. They do not know what time it is unless you tell them, they happily write `2026-11-02T09:00:00` with no offset, and they convert between zones in their head. Each of those is a source of posts going out at 7:00 instead of 9:00. Shager closes one door by refusing ambiguity: `schedule_at` must be ISO 8601 with an offset, for example `2026-10-20T09:00:00+03:00`. A timestamp without `Z` or an offset fails validation. That format is the profile defined in [RFC 3339](https://www.rfc-editor.org/rfc/rfc3339), and it is worth telling your agent so by name in its instructions. The other door is the offset itself. `+03:00` is correct for Israel in October and wrong in December. Offsets change with daylight saving time, and the change dates differ between Israel, the EU and the US. The agent should never hardcode an offset. It should resolve the client's zone name through the [IANA time zone database](https://www.iana.org/time-zones), which every mainstream language ships, and compute the offset for the specific date. ```python from datetime import datetime from zoneinfo import ZoneInfo local = datetime(2026, 11, 2, 9, 0, tzinfo=ZoneInfo("Europe/Berlin")) print(local.isoformat()) # 2026-11-02T09:00:00+01:00 ``` Each Shager workspace also has a `timezone`, an IANA zone name set when the workspace is created (the default is `Asia/Jerusalem`). Make the agent read it and use it. When you run [one agent across many clients](/en/blog/one-agent-many-clients), the clients will not all share a zone, and the workspace is the one place that records which zone each client lives in. ## Draft, then schedule `create_post` can schedule immediately if you pass `schedule_at`. I rarely let agents do that on client work. The safer pattern is two calls: 1. `create_post` without `schedule_at`, which saves a draft. 2. `schedule_post` with the post ID and the time, once a human or a rule has cleared it. ```json { "tool": "schedule_post", "arguments": { "workspace_id": "ws_example", "post_id": "pst_example", "schedule_at": "2026-10-20T09:00:00+03:00" } } ``` There is a permission reason too. In Shager, scheduling needs the `publish` scope on the API key, while drafting needs only `write`. A human grants `publish` explicitly when claiming an agent's sandbox, and can create keys without it. That split lets you give a drafting agent wide freedom and keep the final step behind a person. The details are in [API keys, scopes and audit](/en/blog/api-keys-scopes-and-audit). `schedule_post` also does a useful thing on failure: if any account would reject the post, or client approval is required and missing, it fails with a clear reason instead of scheduling a run that will half fail. ## How long does a staggered run actually take? Shager publishes account by account with a random pause between accounts of the same network. The `stagger_seconds` field sets that range, default `[30, 90]`. Networks run in parallel, so the length of a run is driven by the network with the most accounts. The arithmetic is simple enough for an agent to do before it picks a time: | Accounts on the largest network | Stagger | Average gap | Approximate run length | |---|---|---|---| | 10 | [30, 90] | 60 s | about 9 minutes | | 40 | [30, 90] | 60 s | about 39 minutes | | 40 | [60, 180] | 120 s | about 78 minutes | | 120 | [30, 90] | 60 s | about 2 hours | That last row is the one that surprises people. If a client says "everything must be live by 10:00" and you have 120 Facebook Pages, a 9:00 schedule does not satisfy it. Either start earlier or split the run. Do not respond to a deadline by shrinking the stagger to `[0, 5]`. The pause exists so that a mass run does not look like a burst from one source. Our article on [avoiding spam blocks when posting at scale](/en/blog/avoid-spam-blocks-when-posting-at-scale) explains why pacing matters more than any single caption. ## Split by group, not by hour For large clients, the stronger pattern is one post per account group, each with its own time. A retail chain with 90 branch pages might be grouped by region. The agent creates three posts, one per region group, with schedules on different mornings or spread across a day. ```json { "tool": "create_post", "arguments": { "workspace_id": "ws_example", "group_ids": ["grp_north"], "caption": "Winter hours start Sunday at every northern branch.", "per_channel": [ { "channel_id": "ch_fb_haifa", "caption": "Haifa branch: winter hours start Sunday. We open at 8:30." } ], "campaign": "winter-hours", "stagger_seconds": [60, 150] } } ``` Groups are created with `create_group`, which takes a name and a list of `channel_ids`. Every active channel in a group is added when you target the group. ## Network limits the agent should respect The networks themselves cap how much an account can publish through their APIs. Meta documents a per-account limit on API-published Instagram posts within a rolling 24 hour window and exposes a [content_publishing_limit endpoint](https://developers.facebook.com/docs/instagram-platform/content-publishing) to check current usage. YouTube allocates API quota per project, with a [default of 10,000 units per day](https://developers.google.com/youtube/v3/getting-started), and uploads are among the most expensive operations. Shager handles the dispatch side, but the planning side belongs to the agent. An account that gets six posts in a day is a strategy problem before it is an API problem. I give agents a simple house rule: no more than one feed post per account per day unless a human says otherwise. ## Calendars, holidays and quiet days Shager's calendar includes Israeli holidays, which matters for Israeli clients where a post scheduled for the eve of a major holiday lands on an audience that is offline. For clients elsewhere, give the agent the client's own calendar of closures and events in its instructions. Models know roughly when public holidays fall; they do not know that this client's warehouse closes for inventory on the last Friday of the quarter. ## Cancelling and moving `cancel_post` unschedules a post that has not started publishing. It does not delete it: the post goes back to being an approved draft, so the agent can call `schedule_post` again with a new time. Cancellation is for posts still waiting; once publishing has started, `cancel_post` no longer applies. Before moving anything, the agent should call `list_posts` with `status` set to `SCHEDULED` to see what is already in the queue for that workspace. Two scheduled runs landing on the same accounts in the same hour is the most common self-inflicted mistake I see. ## FAQ ### What time zone does Shager use if the agent sends UTC? A timestamp with `Z` is unambiguous, so Shager schedules it at that exact instant. The workspace time zone matters for how people see the schedule in the calendar and for the agent's own reasoning. Sending local time with the correct offset keeps the agent's logs readable for the humans checking them. ### Can the agent schedule different accounts at different times in one post? One post has one `schedule_at`, and accounts then go out in the staggered sequence. For truly different times, create separate posts, usually one per group. That also keeps reporting cleaner, since each post can carry its own `label`. ### What is a sensible default stagger? The default `[30, 90]` is reasonable for most runs. For video and for runs over about 50 accounts on one network, I widen it to something like `[60, 150]` and start earlier. The cost is time, not reach. ## Where to go next Put these rules into your agent's standing instructions rather than repeating them per task. The [content agent prompts](/en/blog/prompts-for-a-content-agent) article has a scheduling block you can paste as is. --- Source: https://shager.ai/en/blog/scheduling-strategy-for-agents # Caption Variation per Account: Letting AI Rewrite Without Losing the Brand _2026-09-16 · How an AI agent can write a different caption for every account in a campaign while claims, offer and voice stay fixed, using per_channel in one create_post._ Caption variation per account means each account in a campaign gets its own wording while the claim, the offer and the brand voice stay identical. The workable method is to split every caption into fixed parts and variable parts, give the agent explicit rules for each, and send all the variants in one call using `per_channel`. Done this way, forty Pages sound like forty local branches of the same business rather than forty copies of one post. The difficulty is not getting an AI to write variants. Any model will happily produce forty versions of a paragraph. The difficulty is getting variants that are different where difference helps and identical where it matters. ## Why vary captions at all? There are two reasons, and they point in the same direction. The first is the audience. A follower of a Page for a gym in Leeds responds to a post that mentions Leeds, the opening hours of that studio and the trainer they know. A generic caption reads as head-office broadcast. The second is the networks. Meta's [spam policy](https://transparency.meta.com/policies/community-standards/spam/) names repetitive content as one of the signals it acts on, and YouTube's [spam policies](https://support.google.com/youtube/answer/2801973) cover repetitive and untargeted posting. A large set of accounts publishing the same text at the same time is easy to read as exactly that. Variation is not a trick to avoid detection; it is what genuinely local publishing looks like. ## What should stay fixed and what should vary? Before giving the agent any instructions, write this table for the client. It is the contract between the brand and the agent. | Element | Fixed or variable | Notes | |---|---|---| | Core claim or message | Fixed | One sentence, quoted verbatim from the brief if legal sensitivity is high | | Offer, price, dates | Fixed | The agent must never paraphrase numbers | | Legal disclaimers | Fixed | Copied exactly | | Brand voice rules | Fixed | Tone, person, words to avoid | | Opening line or hook | Variable | Different angle per account | | Local detail | Variable | Neighborhood, branch name, local landmark, staff name if provided | | Call to action phrasing | Variable | Same action, different wording | | Length | Variable within a range | For example 40 to 90 words | | Hashtags | Variable from an approved set | The agent picks, never invents | | First comment | Variable | Same link, different lead-in sentence | Our earlier piece on [brand consistency across many accounts](/en/blog/brand-consistency-across-many-accounts) covers the brand side of this in more depth. The table is the bridge between that guidance and what the agent actually does. ## Where does the agent get local detail from? This is where most variation goes wrong. If the agent has no real information about each account, it invents some, and invented local detail is worse than none. A caption that mentions the wrong street will be noticed by exactly the people you want to reach. Give the agent a source of truth. Account names from `list_channels` are a start, since many agencies name Pages by location. For richer detail, keep a small table per client: account, location name, area, opening hours, one or two local facts the client has confirmed. Paste it into the skill or attach it to the run. Then add a rule: "Use only local details from the account table. If an account has no details, use its location name and nothing else." ## How does the call look? Shager's `create_post` accepts a shared `caption` and a `per_channel` array where each entry can override the caption, the first comment and the format for one account. A trimmed example for three accounts: ```json { "caption": "Free intro session this Saturday. Book through the link in the comments.", "group_ids": [""], "media_ids": [""], "format": "REEL", "cta_url": "https://example-gym.com/intro", "campaign": "intro-saturday-oct", "label": "w42-agent", "stagger_seconds": [60, 150], "per_channel": [ { "channel_id": "", "caption": "Headingley, your first session is on us this Saturday. Sam and the morning crew run intro classes from 9 to 12. Free, no commitment.", "first_comment": "Grab a Headingley slot here:" }, { "channel_id": "", "caption": "New to training? Chapel Allerton is opening its doors this Saturday for free intro sessions. Come see the space, meet the coaches, try a class.", "first_comment": "Book your Chapel Allerton intro:" }, { "channel_id": "", "caption": "Saturday at Kirkstall: free intro sessions for anyone thinking about starting. No contract, no pressure, just a proper first workout.", "first_comment": "Kirkstall intro booking:" } ] } ``` Notice what stayed fixed: free, this Saturday, intro session, booking link. What changed: the hook, the local name, who runs it where the client provided it, and the closing. Shager attaches each account's own short link and UTM tag, so the three variants are also measured separately. ## What prompt produces good variants? Here is the instruction block we suggest placing in the agent's skill for any multi-account post: ```text CAPTION VARIATION 1. Read the fixed elements from the brief: core message, offer, dates, disclaimer. Copy them exactly. Never paraphrase numbers or dates. 2. For each account, write a caption between 40 and 90 words. 3. Each caption must open differently. Do not start two captions with the same three words. 4. Use local details only from the account table. If none, use only the location name. 5. Rotate the call to action phrasing. Same action, different words. 6. Hashtags: choose up to 3 from the approved list. Never invent hashtags. 7. Write a distinct first_comment lead-in per account, ending with the link. 8. Put all variants in per_channel in a single create_post call. 9. Before creating the post, list every variant's opening line so a human can check variety at a glance. ``` Rule 9 is a cheap quality check. A reviewer can scan forty opening lines in a minute and spot repetition far faster than by reading forty full captions. ## How do you review variants efficiently? Read the fixed parts once, then check that they appear unchanged everywhere. A simple search across the variants for the price or date catches paraphrasing. Then read a sample of five full variants for voice. Finally, look at the opening lines together. If they cluster around two or three patterns, ask the agent to rework the cluster rather than the whole set. For multilingual clients the same structure holds, with one extra fixed element: the language per account. Our guide to [multilingual content agents](/en/blog/multilingual-content-agents) covers how to handle that without translations that read as translations. ## FAQ ### Is a single caption with the location name swapped enough variation? Usually not. A template where only the place name changes still reads as the same post. Vary the opening and the call to action at minimum, and use real local details when you have them. ### Can the agent vary the format per account too? Yes. Each `per_channel` entry can set its own `format`, so one account can get a Reel while another gets a feed post from the same media, where the network and media allow it. ### Will varied captions hurt brand consistency? Not if the fixed elements are truly fixed. Consistency lives in the claim, the offer and the voice. Wording that changes around a stable core is how good local marketing has always worked. To get started, write the fixed and variable table for one client and add the instruction block to your agent. Our collection of [prompts for a content agent](/en/blog/prompts-for-a-content-agent) has more instructions you can combine with it. --- Source: https://shager.ai/en/blog/caption-variation-per-account-with-ai # One Vertical Video, Forty Accounts: How an Agent Ships Reels and Shorts Through Shager _2026-09-15 · A hands-on playbook for agents distributing short video: format checks, Reels and Shorts metadata, per-account captions, staggered dispatch and real MCP calls._ An agent can distribute one short vertical video to dozens of Instagram, Facebook and YouTube accounts by uploading it once with its dimensions and duration, creating a single post that sets the format per network, and writing a different caption for each account. Shager validates the file against each network's rules before anything is sent, then dispatches account by account with a random pause in between. The agent's real work is the metadata, not the upload. That last sentence is the whole lesson. Short video runs rarely fail on the video itself. They fail because the agent does not know the clip runs 3 minutes and 4 seconds, or because forty accounts receive the same caption word for word. ## What does the agent need to know about the file before it uploads? Three numbers: width, height and duration. The networks classify and accept short video based on them, and an agent that guesses will produce posts that land in the wrong format or get rejected. YouTube's rule is the cleanest to state. According to Google's own help page on [three-minute YouTube Shorts](https://support.google.com/youtube/answer/15424877?hl=en), videos uploaded since October 15, 2024 with a square or vertical aspect ratio and a length of up to three minutes are categorized as Shorts. A clip of 3:04 in 9:16 is therefore a regular video, not a Short, whatever the agent intended. Instagram is looser on aspect ratio but has opinions. Meta's [content publishing documentation](https://developers.facebook.com/docs/instagram-platform/content-publishing) for the Instagram Platform lists the accepted containers and codecs for Reels and recommends 9:16 to avoid cropping or blank space. The video has to sit at a publicly reachable URL when it is published, because Meta fetches it. This is why `upload_media_from_url` in Shager takes optional `width`, `height` and `duration_ms` fields. Pass them and the validation for Reels, Shorts and Stories happens at upload time and again before scheduling, instead of surfacing as a failed post on account number 23. If the agent does not have the numbers, it should get them before uploading. In Claude Code or Codex that is one `ffprobe` call: ```bash ffprobe -v error -select_streams v:0 \ -show_entries stream=width,height:format=duration \ -of json launch-teaser.mp4 ``` ## The MCP call sequence Here is the sequence an agent runs for a client with 38 connected accounts, using Shager's MCP server at `https://app.shager.ai/api/mcp`. The tool names are the real ones; the IDs are placeholders. 1. `whoami` to confirm which organization the key belongs to and whether it may publish. 2. `list_workspaces` to find the client's workspace. 3. `list_channels` for that workspace, to see networks, status and supported formats. 4. `list_groups` to find the group that holds the accounts for this campaign. 5. `upload_media_from_url` with the dimensions and duration. 6. `create_post` as a draft, with per-account captions and per-network format. 7. `request_approval` if the client signs off on videos, or `schedule_post` if not. 8. `get_post` after the scheduled time, to check every account's state. The upload call: ```json { "tool": "upload_media_from_url", "arguments": { "workspace_id": "ws_example", "url": "https://cdn.example-agency.com/clients/aurora/launch-teaser.mp4", "file_name": "launch-teaser.mp4", "width": 1080, "height": 1920, "duration_ms": 42000 } } ``` The draft post. Notice that `format` is set per channel, because the same file is a `REEL` on Instagram and Facebook and a `SHORT` on YouTube: ```json { "tool": "create_post", "arguments": { "workspace_id": "ws_example", "caption": "Aurora opens its new showroom on Thursday. 42 seconds inside.", "media_ids": ["med_teaser"], "youtube_title": "Inside the new Aurora showroom", "youtube_privacy": "public", "cta_url": "https://aurora-example.com/showroom", "campaign": "showroom-launch", "label": "Showroom teaser, week 38", "per_channel": [ { "channel_id": "ch_ig_downtown", "format": "REEL", "caption": "Downtown team here. Thursday we open the doors, and this is what you'll see first." }, { "channel_id": "ch_fb_northside", "format": "REEL", "caption": "Northside customers asked for a showroom. Here's a 42 second look before Thursday." }, { "channel_id": "ch_yt_main", "format": "SHORT", "caption": "A first look at the new Aurora showroom, opening Thursday." } ], "stagger_seconds": [45, 120] } } ``` In a real run `per_channel` has an entry for every account, not three. The agent writes them; a human should not. ## Why does every account need its own caption? Because forty pages publishing the identical text within an hour is the pattern spam systems are built to notice, and because it reads badly to anyone who follows two of the pages. Shager's own [auth.md](/auth.md) tells agents directly to vary captions per account through `per_channel`. Good variation is not synonym swapping. The agent should anchor each caption in something true about that account: the location, the team, the audience. We cover the method in detail in [caption variation per account with AI](/en/blog/caption-variation-per-account-with-ai), including how to keep the brand voice stable while the wording moves. For short video specifically, keep captions short. The video carries the message. A caption that repeats the voiceover wastes the space. ## Where does the link go on short video? This is the part agents most often get wrong, because they apply one rule to every network. On YouTube, Google states in its help center that [URLs in Shorts comments and Shorts descriptions are non-clickable](https://support.google.com/youtube/answer/13748639) to reduce spam. A lead link in a Short's first comment is text, not a link. On Instagram, URLs in captions and comments are not rendered as links either. Facebook Page posts are where a first-comment link behaves as people expect. So for a short video run, the agent should set `first_comment` per channel only where it is useful, and leave it empty on Shorts. Shager still generates a tracked short link per account from `cta_url`, so the click data stays per account wherever the link does appear. The full playbook for this is in [first-comment lead links with agents](/en/blog/first-comment-lead-links-with-agents). ## Pacing: what stagger_seconds actually does `stagger_seconds` is a random pause, in seconds, between accounts of the same network. The default is `[30, 90]`. With 38 accounts split across three networks, each network's queue runs on its own, so Instagram accounts are spaced from each other, and YouTube channels from each other. For video I usually widen it. A 38 account run at `[45, 120]` takes longer to finish, but the posts spread over a period that looks like people publishing, not a script. If the client cares about everything being live before a specific hour, the agent should schedule earlier rather than tightening the stagger. We go deeper on timing in [scheduling strategy for agents](/en/blog/scheduling-strategy-for-agents). ## Checking the result After the scheduled time, the agent calls `get_post`. It returns the post's overall state and the state of each account: publish time, live URL, or the error. Post statuses include `PUBLISHED`, `PARTIALLY_PUBLISHED` and `FAILED`, among others listed in the [OpenAPI document](https://app.shager.ai/api/v1/openapi.json). A `PARTIALLY_PUBLISHED` result is normal at scale. One account's token expired; one Page lost a permission. The agent's job is to report those accounts by name to the human, not to retry blindly. Often the fix is a fresh client connect link for that one account. ## A REST version for scripts If the pipeline runs from a script rather than a chat agent, the same two steps over REST look like this: ```bash curl -s https://app.shager.ai/api/v1/workspaces/ws_example/media \ -H "Authorization: Bearer $SHAGER_API_KEY" \ -H "Content-Type: application/json" \ -d '{"url":"https://cdn.example-agency.com/clients/aurora/launch-teaser.mp4", "file_name":"launch-teaser.mp4","width":1080,"height":1920,"duration_ms":42000}' curl -s https://app.shager.ai/api/v1/workspaces/ws_example/posts \ -H "Authorization: Bearer $SHAGER_API_KEY" \ -H "Content-Type: application/json" \ -d @teaser-post.json ``` Responses come back as `{ "data": ... }`, errors as `{ "error": { "code", "message" } }`. The limit is 120 requests per minute per key, which a single video run never approaches. ## FAQ ### Can the agent post a horizontal video as a Short? No. YouTube classifies Shorts by aspect ratio and length, so a horizontal video goes up as a regular video regardless of the `format` you request. Ask the editor for a vertical cut, or post the horizontal version with `format` set to `VIDEO` on YouTube and keep Reels for the vertical one. ### Should the same video go to every account on the same day? It can, with varied captions and a wide stagger. For large groups, many agencies split the run across two or three days so each account's audience does not see the same clip shared by a neighbouring page at the same hour. The agent can do that by creating separate posts per group with different `schedule_at` values. ### What happens if one account rejects the video? Shager checks each account against its network's rules before sending, so most problems surface at scheduling with a clear reason. If something still fails at publish time, `get_post` shows which account failed and why, and the rest of the run is not affected. ## Where to go next If your agent is not connected yet, start at the [agent entry point](/en/agents), which covers the MCP server, the REST API and self-signup. Then run one short video to a small group before you point it at the whole client list. --- Source: https://shager.ai/en/blog/agent-short-video-distribution # Agent Self-Signup: How an AI Agent Opens a Shager Sandbox in One Call, and Why a Human Still Holds the Publish Button _2026-09-12 · An agent can open its own Shager sandbox with one POST. Here is the call, what the sandbox allows, the human claim step, and how publish rights get granted._ An AI agent can sign up for Shager by itself with one request: `POST https://app.shager.ai/api/v1/agent/signup` with a JSON body containing at least `agent_name`. It gets back an API key, an MCP URL and a claim link, and can immediately create workspaces, import media and draft posts. Nothing is scheduled or published until a human opens the claim link, signs in, and decides whether that key may publish. That split is the whole design. The agent gets unblocked without waiting on a person; the person keeps the decision that touches real audiences. ## Why let an agent sign itself up at all? Because the alternative breaks the agent's flow. An agent asked to "set up our client's social distribution" hits a wall at the first step if the only way in is a human filling a sign-up form, verifying an email and creating a key in a dashboard. By the time someone does that, the agent's context is gone. With self-signup the agent does the groundwork on its own: creates a workspace per client, pulls in the media, writes draft posts, and hands the human a single link with everything ready to review. The registration recipe is published for agents at [/auth.md](/auth.md), and the [agents page](/en/agents) lists the discovery files an agent can read before it starts. ## What does the signup call look like? Only `agent_name` is required (2 to 80 characters). The other fields help the human recognize what they're claiming. ```bash curl -s https://app.shager.ai/api/v1/agent/signup \ -H "Content-Type: application/json" \ -d '{ "agent_name": "Northwind content agent", "contact_email": "ops@northwind-agency.example", "organization_name": "Northwind Agency", "purpose": "Draft weekly posts for 12 restaurant clients" }' ``` The response wraps everything in `data`: ```json { "data": { "api_key": "shgr_live_...", "organization_id": "...", "sandbox": true, "claim_url": "https://app.shager.ai/...", "expires_at": "2026-09-19T10:04:11.000Z", "mcp_url": "https://app.shager.ai/api/mcp", "api_base": "https://app.shager.ai/api/v1", "openapi_url": "https://app.shager.ai/api/v1/openapi.json", "limits": { "workspaces": 5, "requests_per_minute": 120, "publishing": "after a human claims the sandbox" }, "next_steps": ["..."] } } ``` Two fields need immediate handling. 1. `api_key` is shown once. Store it before doing anything else, in a secret store or an environment variable, never in a log line. 2. `claim_url` goes to a human. If you passed `contact_email`, Shager emails the claim link there too, but the agent should still surface it in its own reply. Signups are limited to five per hour per address, which keeps a looping agent from spawning dozens of orphan sandboxes. ## What can an unclaimed sandbox do? | Allowed before the claim | Blocked until a human claims | |---|---| | Create up to 5 workspaces | Schedule or publish anything | | Upload media from URLs | Create client connect links | | Create draft posts | Send client approval requests | | List and read everything it created | | Blocked calls fail with a clear error rather than a silent no-op. An attempt to schedule returns HTTP 403 with `"code": "sandbox_unclaimed"`, and so do `create_connect_link` and `request_approval`. A sixth workspace returns 403 `sandbox_limit`. Good agents read the `code` and tell the human what's needed instead of retrying. The reason connect links and approval requests are blocked is that both reach real people outside the agency: a client clicking a link to connect their Facebook Page, or a reviewer getting an approval email. That shouldn't happen on behalf of an organization nobody has verified. ## A sensible first session in the sandbox Here is what a well-behaved agent does in its first minutes, in Python with `requests`: ```python import os, requests API = "https://app.shager.ai/api/v1" H = {"Authorization": f"Bearer {os.environ['SHAGER_API_KEY']}"} def call(method, path, **body): r = requests.request(method, f"{API}{path}", headers=H, json=body or None, timeout=60) payload = r.json() if not r.ok: err = payload["error"] raise RuntimeError(f"{r.status_code} {err['code']}: {err['message']}") return payload["data"] me = call("GET", "/me") print(me) # organization, scopes, sandbox status ws = call("POST", "/workspaces", name="Harbor Tacos", timezone="America/Chicago") media = call("POST", f"/workspaces/{ws['id']}/media", url="https://harbortacos.example/press/fall-menu.jpg", file_name="fall-menu.jpg") print("Workspace", ws["id"], "media", media["id"], media["kind"]) ``` Pass `timezone` explicitly when you create a workspace. It's an IANA zone name, and scheduling later is interpreted in that zone, so a restaurant in Chicago should not inherit someone else's default. At this point there are no connected social accounts yet, because connecting accounts requires a connect link, which requires the claim. The agent prepares the content and the structure, and the human opens the door to the rest. ## What happens when the human claims it? The human opens `claim_url`, signs in to Shager (or creates an account), and takes ownership of the sandbox along with the workspaces, media and drafts the agent prepared. During the claim they choose whether the agent's key may also schedule and publish, which adds the `publish` scope. That choice deserves a moment of thought. Leaving `publish` off is a perfectly good long-term setup: the agent drafts, the human or the client approves and schedules. Many agencies start there and add a separate publishing key later at https://app.shager.ai/dashboard/agents, where every key can be revoked and every agent call appears in the audit log. The tradeoffs between those setups are covered in [the weekly distribution routine](/en/blog/skill-weekly-distribution-routine). After the claim, the next steps the API itself suggests are straightforward: call `create_connect_link` so the account owner connects their Facebook, Instagram or YouTube without a Shager login, then `create_post` and, if the key has `publish`, `schedule_post`. ## What if nobody claims it? Unclaimed sandboxes expire after seven days, at the time given in `expires_at`. The drafts and workspaces go with them. An agent working on a longer project should remind the human before that date, and should not respond to expiry by signing up again and again. A fresh sandbox doesn't carry the old drafts. ## How should an agent phrase the handoff? Plainly, with the link and the consequences. Something like: ```text I set up a Shager sandbox for Northwind with 3 client workspaces and 9 draft posts. To connect the clients' accounts and publish, open this link and sign in: When you claim it you can choose whether I'm allowed to schedule posts myself. If you don't claim it by Sep 19, the sandbox and drafts are deleted. ``` That message is honest about what was done, what's waiting, and what the human controls. It's also the message most likely to get clicked. ## FAQ ### Does self-signup cost anything? No. The sandbox is free, and after the claim the organization lands on Shager's normal plans, where API and MCP access are included on every tier including Free. Plan limits are on the [pricing page](/en/pricing). ### Can the agent use MCP instead of REST after signing up? Yes. The response includes `mcp_url`, and the same key works as `Authorization: Bearer shgr_live_...` on the MCP server. The tools map one to one to the REST operations described in the [OpenAPI document](https://app.shager.ai/api/v1/openapi.json). ### Can a claimed key ever publish without a human seeing the post? Only if the human granted `publish` during the claim and the workspace doesn't require client approval. Both are the human's choices, and both can be changed later: keys can be revoked in the dashboard, and approval can be required per workspace. ## Next step Once the sandbox is claimed and accounts are connected, move from exploration to a full run. The [end-to-end agent content pipeline](/en/blog/agent-content-pipeline-end-to-end) picks up exactly where this leaves off, from brief to published posts and per-account clicks. --- Source: https://shager.ai/en/blog/agent-self-signup-and-claim # Safety Rules for AI Agents Posting to Hundreds of Accounts _2026-09-09 · A rulebook for AI agents publishing to many social accounts: official APIs, scoped keys, varied captions, staggered dispatch, network limits and a stop plan._ An AI agent posting to hundreds of accounts stays safe by following a short set of rules: publish only through official network APIs, hold the narrowest key it needs, never send identical captions across accounts, space dispatch between accounts, respect each network's limits and policies, and have a way to stop a run quickly. Most of these should be enforced by the platform and the key scopes, with the agent's instructions as a second layer rather than the only one. Below is the rulebook we recommend, written so you can paste most of it straight into an agent's skill. Each rule comes with the reason behind it, because an agent that understands the reason handles edge cases better than one following a bare instruction. ## Why do agents need their own safety rules? A human scheduling posts makes mistakes one at a time. An agent makes them in batches. If the instructions contain an error, that error lands on every account in the run. Scale multiplies good work and bad work equally. The networks are also explicit that volume and repetition are signals they watch. Meta's [spam policy](https://transparency.meta.com/policies/community-standards/spam/) covers posting at very high frequencies, whether manual or automated, and repetitive content. YouTube's [spam, deceptive practices and scams policies](https://support.google.com/youtube/answer/2801973) cover repetitive and untargeted content. These are policies about behavior, not about whether a person or software pressed the button. ## The rulebook ### Rule 1: Official APIs only The agent publishes through a platform that uses each network's official API. No browser automation, no shared logins, no unofficial endpoints. Shager publishes through official network APIs only, so this rule is satisfied by the choice of platform rather than by the agent's discipline. Why: unofficial methods break terms of service and put the account itself at risk, and they fail unpredictably. ### Rule 2: Least privilege keys Start every agent with `read` and `write`. Add `publish` only when a human has decided that agent may schedule. Use separate keys per client or per agent so revoking one does not stop everything. Why: a key that cannot publish turns a bad instruction into a bad draft, which is harmless. Our article on [API keys, scopes and audit](/en/blog/api-keys-scopes-and-audit) explains the setup. ### Rule 3: Draft first, schedule second Every run creates drafts. Scheduling is a separate step after review or client approval. Why: it creates a natural checkpoint without slowing the agent's production work. The full reasoning is in [human approval for agent posts](/en/blog/human-approval-for-agent-posts). ### Rule 4: Vary the caption per account When one post goes to many accounts, use `per_channel` to give each account its own caption, and where relevant its own first comment. Keep claims and offers fixed, vary the opening, local details, phrasing and call to action. Why: identical text across many accounts at the same moment is what repetitive content looks like from the outside. Our guide to [caption variation per account](/en/blog/caption-variation-per-account-with-ai) shows how to do this without drifting off brand. ### Rule 5: Stagger the dispatch Do not send to all accounts in the same second. Shager's `stagger_seconds` sets a random delay range between accounts, with a default of `[30, 90]` seconds. For large groups or sensitive clients, widen it. Why: spreading sends over time is how a real team would publish across many Pages, and it reduces bursts that look automated. ### Rule 6: Know each network's hard limits Some limits are published. Instagram, for example, documents that accounts are [limited to 100 API-published posts within a 24-hour moving period](https://developers.facebook.com/docs/instagram-platform/content-publishing). Your agent should never approach limits like this in normal operation; if it does, the plan is wrong. Media also has format constraints. When uploading video for Reels, Shorts or Stories, pass `width`, `height` and `duration_ms` to `upload_media_from_url` so it can be validated before any post is built. Why: a post rejected at send time wastes a slot, and repeated failures are noise you do not want on a client account. ### Rule 7: Let the platform check before sending Shager checks each post against the target network's rules before dispatch. The agent should treat a validation error as information: read the error code and message, fix the post, and try again once. If it fails twice, stop and report. Why: an agent that retries blindly can turn one problem into dozens of failed calls. ### Rule 8: Respect the API's own rate limit The Shager API allows 120 requests per minute per key. A well-designed run uses group targeting and `per_channel` in a single `create_post` rather than one call per account, so it rarely comes close. Why: batching is faster, and it keeps the run inside limits without sleep loops in the agent's logic. ### Rule 9: Have a stop plan Before a large run, know how to halt it. `list_posts` shows what is scheduled, and the run's `label` tells you which posts belong to it; `cancel_post` withdraws each one before its send time. A human can also revoke the key at the agents dashboard, which stops any further calls from that agent. Why: the time to design the stop button is before you need it. ### Rule 10: Keep an audit trail and read it Every agent call is recorded in the audit log on the agents dashboard. Someone should look at it weekly, not only after an incident. Why: drift in agent behavior shows up in the log before it shows up in public. ## The rulebook as skill text Here is a condensed version to place in a skill or system prompt: ```text SAFETY RULES (always apply) 1. Create drafts only unless the instructions explicitly say to schedule an approved post. 2. When targeting more than one account, always use per_channel with a distinct caption for each account. Never send identical captions. 3. Use stagger_seconds of at least [30, 90]; use [60, 180] for groups larger than 20 accounts. 4. For video, always pass width, height and duration_ms on upload. 5. Never state a price, discount, date or claim that is not in the brief. 6. On a validation error, fix and retry once. On a second error, stop and report the error code and message. 7. Label every post in a run with the same label so the run can be listed and cancelled as a group. 8. Never call schedule_post on a post that has not been approved. ``` The thresholds in rule 3 are our suggestion, not a network rule. Pick values that fit your clients and keep them consistent. ## What does a safe large run look like? 1. `whoami` to confirm the key's scopes match the task. 2. `list_groups` and `list_channels` to resolve exactly which accounts are in scope, and report the count before doing anything else. 3. `upload_media_from_url` with full dimensions and duration. 4. `create_post` with `group_ids`, `per_channel`, `first_comment`, `stagger_seconds` and a run `label`, as a draft. 5. `request_approval`, or hand off to a human reviewer. 6. After approval, `schedule_post` for each approved post. 7. After send time, `get_post` on a sample to confirm delivery, and report any failures. Step 2 is the one teams skip and regret. An agent that announces "this run targets 212 accounts in 3 groups" gives a human a chance to say "that is the wrong group" before a single draft exists. ## FAQ ### Is posting through an agent riskier than posting by hand? The risk is different, not necessarily higher. An agent repeats errors at scale, while a human makes scattered errors. With scoped keys, draft-first runs and varied captions, an agent run can be more consistent than manual work across many accounts. ### What is the safest default for stagger_seconds? Shager's default is 30 to 90 seconds between accounts. No network publishes an ideal spacing value, so widen it for large groups and judge by results rather than by a rule of thumb. ### Can I stop a scheduled run after it starts? Yes. Posts not yet sent can be withdrawn with `cancel_post`, and the shared run label makes them easy to identify in `list_posts`. Revoking the key stops any further calls. For the background on how platforms treat high-volume posting, read [avoiding spam blocks when posting at scale](/en/blog/avoid-spam-blocks-when-posting-at-scale), then copy the rulebook above into your agent's skill before its next run. --- Source: https://shager.ai/en/blog/safety-rules-for-agents-posting-at-scale # Can ChatGPT Post Through Shager? What Works Today, What Waits for OAuth, and the Three Routes That Ship Now _2026-09-05 · ChatGPT's MCP connectors need OAuth or no auth, so Shager's API-key server can't plug in yet. Here are the routes that work today and what OAuth will change._ Not as a ChatGPT connector, not yet. ChatGPT's custom MCP connectors authenticate with OAuth or no authentication at all, and Shager's MCP server currently uses an API key in the `Authorization` header, so the two don't meet inside the ChatGPT app today. Shager's OAuth for MCP is coming and will close that gap. Until then, you can still put OpenAI models to work on Shager through Codex, through the OpenAI API, or by using ChatGPT for writing and a short script for delivery. This piece explains why the gap exists, and gives working code for each route so you aren't stuck waiting. ## Why can't you add Shager as a ChatGPT connector right now? OpenAI's guide to [authentication for apps in ChatGPT](https://developers.openai.com/apps-sdk/build/auth) describes the supported model: servers that need authentication implement an OAuth 2.1 flow that follows the MCP authorization spec, with Client ID Metadata Documents preferred and dynamic client registration also supported. Servers can also run without authentication. The same guide states that ChatGPT cannot present custom API keys. Shager's server at https://app.shager.ai/api/mcp expects `Authorization: Bearer shgr_live_...`. That header is exactly the thing ChatGPT's connector flow doesn't send. So the honest answer is that the ChatGPT app can't call Shager directly until Shager offers OAuth sign-in, which is on the way. ### Why not put a no-auth proxy in front? People suggest this, and it's a bad idea. A proxy that accepts unauthenticated requests and injects your Shager key turns your agency's publishing access into a public endpoint. Anyone who finds the URL can draft posts into client workspaces, and with a `publish` key, schedule them. Don't do it. ## Route 1: Codex, OpenAI's coding agent If what you want is "an OpenAI model operating Shager," Codex already does that cleanly. It supports bearer tokens from an environment variable for streamable HTTP MCP servers, so the setup is a few lines in `~/.codex/config.toml`: ```toml [mcp_servers.shager] url = "https://app.shager.ai/api/mcp" bearer_token_env_var = "SHAGER_API_KEY" ``` OpenAI's MCP docs note that the ChatGPT desktop app, Codex CLI and IDE extension share this configuration file. The full walkthrough, including a tool allowlist, is in [connecting Shager to Codex](/en/blog/connect-shager-to-codex). ## Route 2: the OpenAI Responses API with a remote MCP tool If you're building your own agent on OpenAI's API, the Responses API can call remote MCP servers itself. The [connectors and MCP guide](https://developers.openai.com/api/docs/guides/tools-connectors-mcp) documents an `mcp` tool with `server_url`, an `authorization` field for the access token, `allowed_tools` and `require_approval`. The docs also note the API does not store the `authorization` value, so you send it on every request. ```python import os from openai import OpenAI client = OpenAI() response = client.responses.create( model=os.environ["OPENAI_MODEL"], input=( "In the Shager workspace 'Cedar Clinics', list the channels, then create a " "DRAFT post to all active channels announcing Saturday walk-in hours. " "Use a different caption per channel that names the clinic's town. " "cta_url https://cedarclinics.example/walk-in, campaign 'walk-in-sat'. " "Do not pass schedule_at." ), tools=[{ "type": "mcp", "server_label": "shager", "server_url": "https://app.shager.ai/api/mcp", "authorization": os.environ["SHAGER_API_KEY"], "allowed_tools": [ "whoami", "list_workspaces", "list_channels", "list_groups", "create_post", "get_post", ], "require_approval": { "never": {"tool_names": ["whoami", "list_workspaces", "list_channels", "list_groups", "get_post"]} }, }], ) print(response.output_text) ``` Three notes from running this kind of setup. First, test the auth with `whoami` before anything else. The OpenAI docs present `authorization` as an OAuth access token field; Shager's key is a bearer token, so the first call tells you immediately whether the header arrives the way Shager expects. If you get a 401 back in the tool output, fall back to Route 3. Second, `create_post` is deliberately left out of the `never` list, so the API returns an approval request before it runs. Your code inspects the arguments and answers with an approval response. That's a cheap human or rule-based checkpoint before a draft is written. Third, keep `publish` off this key. Then even an approved call can only create drafts. ## Route 3: ChatGPT writes, your script delivers This is the most common pattern among agencies that live in ChatGPT. The model does what it's good at, which is writing forty variations of a caption. A twenty-line script does the delivery through Shager's REST API at https://app.shager.ai/api/v1, which the [OpenAPI document](https://app.shager.ai/api/v1/openapi.json) describes in full. Ask ChatGPT for structured output you can paste into a file: ```text For each account below, write a caption for our Saturday walk-in hours post. Vary the opening line and mention the town. Keep facts identical. Return only JSON: [{"channel_id": "...", "caption": "..."}] Accounts: ``` Then push it as a draft: ```python import json, os, requests API = "https://app.shager.ai/api/v1" H = {"Authorization": f"Bearer {os.environ['SHAGER_API_KEY']}"} WS = os.environ["SHAGER_WORKSPACE_ID"] captions = json.load(open("captions.json")) r = requests.post(f"{API}/workspaces/{WS}/posts", headers=H, json={ "caption": captions[0]["caption"], "channel_ids": [c["channel_id"] for c in captions], "per_channel": captions, "cta_url": "https://cedarclinics.example/walk-in", "campaign": "walk-in-sat", "first_comment": "Hours and directions: https://cedarclinics.example/walk-in", }, timeout=60) body = r.json() if not r.ok: raise SystemExit(f"{body['error']['code']}: {body['error']['message']}") print("draft", body["data"]["id"], body["data"]["status"]) ``` The `per_channel` array accepts objects with `channel_id` and `caption` (plus optional `first_comment` and `format`), so ChatGPT's JSON drops straight in. The `cta_url` gets a separate short link and UTM per account, with `utm_content` naming the account, which is what makes the results attributable later. ## Which route fits which team? | Situation | Route | |---|---| | You want an agent with tools in a terminal or IDE today | Codex with `bearer_token_env_var` | | You're building your own product or agent on OpenAI models | Responses API with the `mcp` tool, or plain REST | | Your team writes in ChatGPT and won't leave it | ChatGPT for captions, script for delivery | | You want Shager inside the ChatGPT app itself | Wait for Shager's OAuth for MCP | ## What changes when Shager's OAuth ships? You'll be able to add https://app.shager.ai/api/mcp as a custom MCP server in ChatGPT and sign in with your Shager account, the way OpenAI's [guide to connecting from ChatGPT](https://developers.openai.com/apps-sdk/deploy/connect-chatgpt) describes for authenticated servers. Each person connects with their own account rather than sharing a key. Scopes and the audit log stay the same, and so do the tools, which match the REST operations one to one. ## FAQ ### Is there any way to use an API key in ChatGPT's connector settings? Not according to OpenAI's authentication guide for apps in ChatGPT, which lists OAuth and no-auth modes and says ChatGPT cannot present custom API keys. Treat any workaround that exposes your key behind an open endpoint as a security problem, not a fix. ### Will Shager work in ChatGPT on mobile once OAuth is live? That depends on where ChatGPT allows custom MCP servers at the time, which is OpenAI's decision and has changed during rollout. Check OpenAI's current documentation when Shager's OAuth ships rather than relying on today's behavior. ### Do I need a paid Shager plan to try any of these routes? No. API and MCP access are included on every plan, including Free with three accounts, and there's a 14-day trial with no card. The [pricing page](/en/pricing) has the account limits per plan. ## Next step If you're going the code route, the fastest way to get oriented is the [REST API quickstart](/en/blog/shager-rest-api-quickstart), which goes from a fresh key to a tracked multi-account draft in six calls. --- Source: https://shager.ai/en/blog/shager-and-chatgpt # Measuring Leads From Agent-Published Content, Account by Account _2026-09-02 · How to tell whether agent-published posts produce leads: per-account short links and UTMs, campaign labels, get_analytics, CRM hidden fields and a weekly read._ To measure leads from agent-published content, every post needs a tracked link per account before it goes out, every post needs a campaign label the agent sets consistently, and the source must be carried into the lead record in the CRM. Clicks per account and per post come from the distribution platform; leads per account come from the CRM. An agent can assemble both into a weekly read, but only if the tagging was done at publishing time. Agents change the measurement problem in one specific way. They make it easy to publish a lot, which means it is also easy to publish a lot of things nobody can evaluate. If the measurement design is not in place before the first agent run, you end up with more posts and less clarity than before. ## Why do agent workflows need stricter tagging than manual ones? In a manual workflow, a person often remembers why a post exists. "That was the clinic open day thing." An agent run that produces sixty variants across forty accounts leaves no such memory. Unless the post itself carries its purpose in structured fields, nobody will be able to group the results later. There are three things to tag, and each has a home: | What you need to know later | Where it lives | Set by | |---|---|---| | Which account sent the click | Per-account short link with `utm_content` | Platform, automatically | | Which campaign or theme the post served | `campaign` field on the post | Agent, from the brief | | Which batch or experiment it was part of | `label` field on the post | Agent, from the run instructions | Shager generates a short link and UTM tag per account, with `utm_content` identifying the account, so the first row needs no work from the agent. The other two do, and they need to be written into the skill as rules, not left to the model's judgment. ## How should campaign and label values be named? Treat these values like database keys. Lowercase, hyphenated, stable, and drawn from a list the agent is given. Google's [guide to collecting campaign data with custom URLs](https://support.google.com/analytics/answer/10917952) notes that UTM values are case sensitive, which is exactly the kind of detail an agent will get wrong if it improvises. A naming rule in the agent's skill: ```text campaign: use the campaign key from the brief verbatim, e.g. "autumn-open-day-2026". Never invent a campaign key. If the brief has none, stop and ask. label: "w-", e.g. "w38-a", "w38-b" when testing two hooks. cta_url: the landing page from the brief, without UTM parameters. The platform adds per-account tracking. ``` The last line matters. If the agent adds its own UTM parameters on top of the platform's, you get duplicated or conflicting tags and broken reports. ## Where do the leads come from, not just the clicks? Clicks are the platform's half. A click is counted on the short link server before the redirect, so it does not depend on the visitor accepting cookies. But a click is not a lead. To turn clicks into leads per account, the landing page has to capture the UTM values into the form and pass them to the CRM. Our article on [per-account lead attribution](/en/blog/utm-per-account-lead-attribution) covers hidden fields, persistence across pages and CRM mapping in detail. In short: 1. Add hidden fields for `utm_source`, `utm_campaign` and `utm_content` to every lead form. 2. Populate them from the URL on landing, and keep them if the visitor browses before converting. 3. Map them to dedicated CRM properties. 4. Send a test lead from one account in each group and confirm the account identifier arrives. Once that is done, the CRM can count leads by `utm_content`, which is the account, and by `utm_campaign`. ## Does the first comment change measurement? It adds a second click path. Shager can post a first comment carrying the lead link, and that link uses the same per-account tracking. The practical consequence is that you can compare posts where the link sat in the comment against posts where it sat in the caption, on the same account, as long as the agent labels them. Treat placement as something to test rather than a rule. Our piece on [first-comment lead links with agents](/en/blog/first-comment-lead-links-with-agents) goes through the setup. ## What does the weekly read look like? This is where an agent earns its keep twice. It published the posts, and now it can read the results without anyone exporting spreadsheets. A Friday instruction: ```text Workspace "Summit Physio". Date range: last 7 days. 1. Get clicks per account and per post. 2. Group by campaign. For each campaign, list the top 5 and bottom 5 accounts by clicks. 3. Flag any account with zero clicks across all posts this week. 4. Compare label w38-a against w38-b where both ran on the same account. 5. I will paste the CRM export of leads by utm_content. Join it to the click data and show leads per 100 clicks per account. Write the summary in plain English, under 300 words, then the tables. ``` The tool calls: ```text list_workspaces select "Summit Physio" get_analytics date range last 7 days: clicks per account, per post list_posts to map post ids to campaign and label ``` Step 5 deliberately has a human pasting CRM data. Many agencies do not want an agent with direct write access to a client's CRM, and the join is easy once both tables exist. If you want the whole report automated and formatted for the client, see [the weekly client report built by an agent](/en/blog/weekly-client-report-by-agent). ## How should you read the numbers? A few habits keep the read honest. Compare accounts against themselves over time before comparing them against each other. A small-town Page and a city-center Page have different audiences, and ranking them side by side mostly measures population. Watch the ratio, not only the volume. An account with modest clicks and a high share of leads is telling you something about audience fit that a high-click, low-lead account is not. Keep experiments small and labeled. If the agent tests two hooks, it should be on the same accounts in the same week, with the label telling them apart. Otherwise you are comparing weeks, not hooks. Do not over-read a single week. Look for patterns over a month before moving budget or effort. ## FAQ ### Can the agent see leads, or only clicks? Through Shager, the agent sees clicks per account and per post via `get_analytics`. Leads live in the client's CRM. You can give the agent a CRM export to join, or connect a separate CRM tool, depending on what the client permits. ### Why are click counts and analytics sessions different? Short-link clicks are counted on the server before the redirect. Analytics sessions depend on the page loading its tracking script and, often, on cookie consent. Some visitors click and never register as a session. Expect the click count to be the higher of the two. ### Should the agent pick which accounts get more posts based on results? It can propose, and a human should decide. Shifting effort between accounts is a strategy call that also involves the client relationship. Let the agent prepare the case with numbers. If your current posts carry no campaign or label values, fix that before anything else. Add the naming rules to your agent's skill, run one week, and the Friday read will already be more useful than last month's report. The [OpenAPI description](https://app.shager.ai/api/v1/openapi.json) lists the analytics fields if you want to build the report from code. --- Source: https://shager.ai/en/blog/measuring-leads-from-agent-content # Add Shager to Cursor With .cursor/mcp.json: Turn Release Notes Into Drafts for Every Client Account _2026-08-28 · Configure Shager's remote MCP server in Cursor with a url and an env-backed Authorization header, then turn a changelog into per-account social drafts._ To connect Shager to Cursor, create `.cursor/mcp.json` in your project (or `~/.cursor/mcp.json` for every project) with a `shager` entry whose `url` is `https://app.shager.ai/api/mcp` and whose `headers` set `Authorization` to `Bearer ${env:SHAGER_API_KEY}`. Cursor resolves the variable from your environment, connects over HTTP, and the agent gets Shager's tools. No local server, no bridge. Cursor is an interesting place to run distribution from because the source material already sits in the repo: changelogs, docs, release notes, blog drafts. This guide sets up the connection properly and then uses it for that job. ## What does Cursor's MCP config look like for a remote server? Cursor's [MCP documentation](https://cursor.com/docs/context/mcp) shows a remote server as a `url` plus an optional `headers` object, and documents `${env:NAME}` interpolation in the `url` and `headers` fields. It also lists two locations: `.cursor/mcp.json` in a project for project-specific tools, and `~/.cursor/mcp.json` in your home directory for tools available everywhere. For Shager: ```json { "mcpServers": { "shager": { "url": "https://app.shager.ai/api/mcp", "headers": { "Authorization": "Bearer ${env:SHAGER_API_KEY}" } } } } ``` And in your shell profile: ```bash export SHAGER_API_KEY="shgr_live_your_key_here" ``` Cursor reads environment variables from the process that launched it. On macOS, an app opened from the Dock may not see variables you set in `~/.zshrc`. If the server fails with a 401 even though the key is right, quit Cursor and launch it from a terminal with `cursor .` to confirm that's the cause. ## Project file or global file? | Location | Good for | Watch out for | |---|---|---| | `.cursor/mcp.json` in the repo | A marketing site or docs repo where content work happens | Commit it only with the `${env:...}` form, never a literal key | | `~/.cursor/mcp.json` | You want Shager available in every workspace | Every project's agent can now reach your Shager workspaces | For an agency developer who maintains several client sites, the project file is usually the better fit. The repo for client A shouldn't have an agent that can casually draft into client B's workspace. Pair the project file with a key whose organization only holds the workspaces that make sense for that repo, or at least name workspaces explicitly in your prompts. ## Where does the key come from? A human creates it at https://app.shager.ai/dashboard/agents and picks scopes. For work inside an editor, `read` plus `write` is the right default: the agent can upload media and create drafts, but Shager refuses to schedule or publish without the `publish` scope. If you're prototyping and don't have an account yet, an agent can create a sandbox through [self-signup](/en/blog/agent-self-signup-and-claim); the recipe is published at shager.ai/auth.md. ## How do you check that Cursor sees the tools? Open Cursor's MCP settings and look for `shager` with a connected status and its tool list: `whoami`, `list_workspaces`, `create_workspace`, `list_channels`, `create_connect_link`, `list_groups`, `create_group`, `upload_media_from_url`, `create_post`, `schedule_post`, `request_approval`, `get_post`, `list_posts`, `cancel_post` and `get_analytics`. If the server shows an error, the three usual causes are a missing environment variable, `Bearer` missing from the header value, or a JSON syntax error in the file. Then, in the agent chat: ```text Call shager whoami and tell me which scopes this key has. ``` ## The workflow: a changelog becomes per-account drafts Here is a concrete job that fits Cursor well. Say you maintain the site for a software reseller with twelve regional partner pages on Facebook and Instagram. Every release, someone rewrites the changelog into social posts by hand. With Shager connected, the agent can do the first pass. ```text Read CHANGELOG.md and take the entry for v4.2 only. In Shager workspace "Brightline Partners": 1. list_groups and use the group "Regional partners". 2. list_channels so you know each channel's name and network. 3. Write one short post about v4.2 for a non-technical audience. 4. Create a DRAFT with create_post (no schedule_at): group_ids: the "Regional partners" group per_channel: a caption per channel that names the region from the channel name and varies the opening line; keep facts identical cta_url: https://brightline.example/releases/4-2 campaign: "release-4-2" first_comment: "Full notes: " followed by the link 5. Print the post id and a table of channel, caption first line, format. ``` A few choices in that prompt are deliberate. Facts stay identical while wording varies. `per_channel` overrides the caption for each account, which is the recommended pattern. Twelve copies of the same text across related pages is the kind of repetition our piece on [avoiding spam blocks when posting at scale](/en/blog/avoid-spam-blocks-when-posting-at-scale) warns about, and it reads badly to anyone who follows two of those pages. The link is tracked per account. Passing `cta_url` makes Shager create a separate short link and UTM set for every account, with `utm_content` identifying it. Later, `get_analytics` returns clicks by account and by post, so the partner in one region can see what their page drove. The output is a draft. Somebody still reads it in Shager before it ships, either an internal reviewer or the client through an approval link. ## What if you'd rather call the API from code? Sometimes you want this as a script in the repo rather than a chat. A release workflow in CI, for example, should not depend on someone opening Cursor. The same operations are exposed over REST, described in the [OpenAPI document](https://app.shager.ai/api/v1/openapi.json). The equivalent of step 4 above in TypeScript: ```typescript const API = "https://app.shager.ai/api/v1"; const headers = { Authorization: `Bearer ${process.env.SHAGER_API_KEY}`, "Content-Type": "application/json", }; const res = await fetch(`${API}/workspaces/${workspaceId}/posts`, { method: "POST", headers, body: JSON.stringify({ caption: defaultCaption, group_ids: [groupId], per_channel: captions.map((c) => ({ channel_id: c.channelId, caption: c.text })), cta_url: "https://brightline.example/releases/4-2", campaign: "release-4-2", first_comment: "Full notes: https://brightline.example/releases/4-2", }), }); const body = await res.json(); if (!res.ok) throw new Error(`${body.error.code}: ${body.error.message}`); console.log(body.data.id, body.data.status); // a DRAFT post ``` Responses are wrapped in `{ "data": ... }` and errors in `{ "error": { "code", "message" } }`, so the error handling is the same everywhere. The [REST quickstart](/en/blog/shager-rest-api-quickstart) covers the full sequence. ## Rules worth adding to the project Cursor supports project rules, and a short one saves you from repeating constraints in every prompt. Something like: ```text When using the shager MCP server: Never pass schedule_at unless I explicitly give a date and time. Always use per_channel captions when posting to more than one account. Always pass cta_url for any link instead of pasting raw URLs into captions. Use ISO 8601 with an offset for any time, in the workspace timezone. ``` Rules are guidance to the model, not enforcement. The enforcement is the key's scope. Keep `publish` off the editor key and the first rule can't be broken even if the model ignores it. ## FAQ ### Does Cursor support Shager without OAuth? Yes. Cursor sends whatever headers you configure, so the bearer API key works directly. Shager's OAuth for MCP is coming, but Cursor users don't need to wait for it. ### Can I use the same key in Cursor and Claude Code? You can, but separate keys are better. Each call lands in Shager's audit log under the key that made it, and separate keys let you revoke one tool without breaking the other. The Claude Code setup has its own guide in this series. ### Will the agent post immediately if I say "publish this"? Only if the key has the `publish` scope, the account has been claimed by a human, and the workspace doesn't require client approval first. With a read and write key, the request fails with a clear 403 and nothing goes out. ## Next step Once the connection works, the bigger win is a repeatable procedure rather than clever prompts. Read [how to build a Claude skill for Shager](/en/blog/build-a-claude-skill-for-shager) for the structure, since the same instructions translate well into Cursor rules, and keep the [agents page](/en/agents) open as the reference for every tool and field. --- Source: https://shager.ai/en/blog/connect-shager-to-cursor # Human Approval for Agent-Written Posts: Where to Put the Gate _2026-08-26 · Where human approval belongs when an AI agent writes and schedules social posts: scoped keys, draft-first runs, client approval links and what reviewers check._ Human approval for agent-written posts belongs at one point: between a finished draft and the schedule. The agent should be free to research, write and build drafts, but a person, or the client, decides what goes live. You enforce that with key scopes, not with good intentions, so the agent technically cannot publish until the approval step has happened. This piece explains why that placement works, how to set it up in Shager, and what a reviewer should actually check when twenty drafts land at once. ## Why not approve every step the agent takes? Some teams react to agents by asking for confirmation on everything: every upload, every caption, every lookup. That feels safe and fails within a week. Reviewers get confirmation fatigue and start clicking yes without reading, which is worse than no gate at all. The MCP specification takes a measured position. It says that for trust and safety [there should always be a human in the loop with the ability to deny tool invocations](https://modelcontextprotocol.io/specification/2025-06-18/server/tools), and that clients should prompt for confirmation on sensitive operations. The key word is sensitive. Reading an account list is not sensitive. Making a public statement on behalf of a client is. ## Where exactly should the gate sit? Look at the agent's work as a chain and mark which links are reversible: | Step | Reversible? | Needs a human? | |---|---|---| | Look up workspaces, groups, channels | Nothing changes | No | | Upload media from a URL | Private to the workspace | No | | Create a draft post | Private, editable, deletable | No | | Schedule a post | Reversible until the send time | Yes | | Publish | Public, seen immediately | Yes, already decided | The irreversible moment is publishing, and the last practical point to stop it is scheduling. So the gate goes there. Everything before it can run without interruption, which is what makes agents efficient in the first place. ## How do scopes enforce the gate? Shager API keys carry scopes: `read`, `write` and `publish`. A key with `read` and `write` can do every step above the gate line and none below it. If the agent tries `schedule_post`, the call fails. That gives you three practical configurations: 1. **Drafting agent, human schedules.** The agent's key has `read` and `write`. A person reviews drafts in the dashboard and schedules them. This is where every team should start. 2. **Drafting agent, client approves, agent schedules.** The agent's key also has `publish`, but your skill instructs it to schedule only posts whose approval came back positive. This is efficient, but it depends on the instructions being followed, so keep the audit log under review. 3. **Two keys.** One drafting key without `publish` used by the content agent, and a separate scheduling step, by a person or a narrowly instructed agent, holding the publish key. This is the cleanest separation for larger agencies. Self-registered agents start even more constrained. An agent that signs up on its own through [/auth.md](/auth.md) gets a sandbox that can create drafts but cannot schedule, publish, create connect links or send approval requests until a human claims it. During the claim, the human decides whether the key gets `publish`. We cover the full flow in [agent self-signup and claim](/en/blog/agent-self-signup-and-claim). ## How does client approval fit in? For agency work, the person who approves is often the client. Shager's `request_approval` creates an approval link that the client opens without logging in or creating an account. They review the post and approve or reject it. A typical sequence: ```text create_post caption, group_ids, media_ids, per_channel[...], no schedule_at request_approval post id, returns an approval link for the client get_post later: read the approval status schedule_post only if approved; schedule_at "2026-09-03T09:00:00+02:00" ``` And a matching instruction for the agent, written into its skill: ```text Never call schedule_post on a post unless get_post shows it was approved. If a post is rejected, do not schedule it. Report the rejection to the account lead, wait for revision notes, then create a revised draft with create_post and request approval again. ``` The broader process, including how to stop approvals stalling for days, is in our [client approval workflow for agencies](/en/blog/client-approval-workflow-for-agencies). ## What should a reviewer actually check? Reviewing twenty agent drafts is a different task from reviewing one human post. You are looking for systematic errors, because an agent repeats its mistakes consistently. Read in this order: 1. **Claims.** Prices, dates, offers, health or financial statements. Compare against the brief. This is where real harm happens. 2. **Links.** Open the first comment link on two or three variants. Confirm it goes to the right landing page. 3. **Per-account details.** Spot check that the Denver variant says Denver and the Boise variant says Boise. Mismatched local details are the most common agent error in localized captions. 4. **Variation.** Skim the variants side by side. If they read like the same sentence with one word swapped, ask for more distinct versions. 5. **Format.** Reels and Shorts have length and aspect requirements. Shager validates media against network rules before sending, but the reviewer should still check that the format chosen fits the creative. When you find a problem, fix the rule that caused it, not just the post. If the agent invented a discount, add "never state a price or discount that is not in the brief" to its instructions. ## When can you loosen the gate? Loosen it gradually and only with evidence. After several weeks in which reviewers found no claim or link errors, a team might move evergreen content, such as tips and opening hours, to a lighter review, while campaigns with offers stay fully reviewed. The audit log on the agents dashboard shows every call the agent made, so loosening the gate does not mean losing visibility. ## FAQ ### Can a client approve posts without a Shager account? Yes. The approval link opens without login. The client sees the post and approves or rejects it, and the agent or the account lead reads the result. ### What happens if an agent tries to publish without the publish scope? The call is rejected with a structured error, and nothing is scheduled. That is the point of putting the gate in scopes: it holds even when the instructions are wrong. ### Should internal posts for the agency's own accounts skip approval? They can have a lighter gate, but keep some human step. Agency accounts are your public reputation, and an agent error there is as visible as one on a client Page. Start with the first configuration, drafting agent and human scheduling, for every new client. The [agent entry point](/en/agents) has the connection details, and you can tighten or loosen from there with real review data behind the decision. --- Source: https://shager.ai/en/blog/human-approval-for-agent-posts # Shager in OpenAI Codex: config.toml, bearer_token_env_var and a Tool Allowlist That Keeps Drafts as Drafts _2026-08-20 · Set up Shager's remote MCP server in Codex CLI via config.toml or codex mcp add, read the key from an env var, restrict tools, and create a first draft._ To connect Shager to OpenAI's Codex CLI, add an `[mcp_servers.shager]` table to `~/.codex/config.toml` with `url = "https://app.shager.ai/api/mcp"` and `bearer_token_env_var = "SHAGER_API_KEY"`, then export your `shgr_live_` key in that variable. Codex speaks streamable HTTP natively and sends the key as a bearer token, so no bridge or local process is needed. You can also do it in one line with `codex mcp add shager --url ... --bearer-token-env-var SHAGER_API_KEY`. The rest of this guide is about doing it in a way you won't regret: keeping the key out of the file, limiting which Shager tools Codex can call, and picking a first task that proves the wiring. ## What does Codex support for remote MCP servers? OpenAI's [Codex MCP documentation](https://developers.openai.com/codex/mcp) describes streamable HTTP servers configured with a `url`, plus three ways to authenticate with headers. The [configuration reference](https://developers.openai.com/codex/config-reference) defines them: | Key | What it does | |---|---| | `bearer_token_env_var` | Name of an environment variable whose value is sent as the bearer token | | `http_headers` | Static headers included with each request | | `env_http_headers` | Headers whose values are read from environment variables | Shager expects `Authorization: Bearer shgr_live_...`, which is exactly what `bearer_token_env_var` produces. That is the option to use. ## Option A: edit config.toml Open `~/.codex/config.toml` and add: ```toml [mcp_servers.shager] url = "https://app.shager.ai/api/mcp" bearer_token_env_var = "SHAGER_API_KEY" ``` Then put the key in your shell profile, not in the TOML: ```bash export SHAGER_API_KEY="shgr_live_your_key_here" ``` Note that the config holds the variable's name, not the key itself. That means you can commit or share the snippet freely, and each teammate supplies their own key. Separate keys per person pay off later, because Shager's audit log at https://app.shager.ai/dashboard/agents records every call against the key that made it. ## Option B: codex mcp add The CLI writes the same table for you. The Codex source for `codex mcp add` defines `--url` for streamable HTTP servers and a `--bearer-token-env-var` flag that requires it ([mcp_cmd.rs on GitHub](https://github.com/openai/codex/blob/main/codex-rs/cli/src/mcp_cmd.rs)): ```bash codex mcp add shager \ --url https://app.shager.ai/api/mcp \ --bearer-token-env-var SHAGER_API_KEY ``` If your installed version differs, `codex mcp add --help` is the source of truth. Check the result: ```bash codex mcp list ``` Inside the Codex TUI, `/mcp` shows active servers and their tools. ## Should you use http_headers instead? You can, but you shouldn't. `http_headers = { "Authorization" = "Bearer shgr_live_..." }` works, and it puts a live credential in a plain text file that tends to get copied into dotfile repos. If you need a header other than the bearer token, `env_http_headers` maps a header name to an environment variable name: ```toml [mcp_servers.shager] url = "https://app.shager.ai/api/mcp" env_http_headers = { "Authorization" = "SHAGER_AUTH_HEADER" } ``` With that form, the variable must contain the full value, including the scheme: `export SHAGER_AUTH_HEADER="Bearer shgr_live_..."`. For Shager, `bearer_token_env_var` is simpler and does the same thing. ## How do you limit what Codex can do in Shager? This is the part most setup guides skip. Codex lets you filter a server's tools with `enabled_tools` (an allow list) and `disabled_tools` (a deny list applied after it), both documented in the configuration reference. Combine that with Shager's key scopes and you get two layers that fail closed. A drafting profile that can read everything and create drafts, but cannot schedule, cancel or create connect links: ```toml [mcp_servers.shager] url = "https://app.shager.ai/api/mcp" bearer_token_env_var = "SHAGER_API_KEY" enabled_tools = [ "whoami", "list_workspaces", "list_channels", "list_groups", "upload_media_from_url", "create_post", "get_post", "list_posts", "get_analytics", ] tool_timeout_sec = 120 ``` `create_post` stays in the list because without `schedule_at` it only saves a draft. If the key also lacks the `publish` scope, Shager rejects any `create_post` that includes `schedule_at` with a 403, so even a creative model can't sneak a scheduled post through. The `tool_timeout_sec` bump is there because `upload_media_from_url` downloads the file server side, and a large vertical video can take longer than the default 60 seconds the reference lists. ## A first task worth running Start with a prompt that touches several tools and leaves only a draft behind: ```text Use the shager MCP server. 1. whoami, then list_workspaces. 2. In workspace "Lakeside Realty", list_channels and list_groups. 3. upload_media_from_url https://example.com/media/open-house.jpg 4. create_post as a draft to group "All agents" with a different caption per channel (per_channel), mentioning each agent's neighborhood from the channel name. cta_url https://lakesiderealty.example/open-house, campaign "open-house-oct", first_comment "Details and RSVP: " followed by the link. 5. get_post and print a table of channel, network, format and state. ``` What you should see: a post in `DRAFT` status with one destination per account, each with its format resolved for that network. In Shager, every account gets its own short link and UTM tags for the `cta_url`, with `utm_content` naming the account, which is what makes per-account attribution work later. The details are in [per-account lead attribution](/en/blog/utm-per-account-lead-attribution). ## Can Codex run this without a human at the keyboard? Codex has a non-interactive `codex exec` mode for scripts and CI. How MCP tool approvals behave in a headless run has changed between releases, so test a dry run on your installed version before you put it on a timer. For a job that must run unattended every week, many teams skip the chat layer and call Shager's REST API from a short script, which has no approval prompts to get stuck on. Whichever you choose, give the job its own key, keep the tool allowlist tight, and decide deliberately whether that key carries `publish`. A routine built around those choices is laid out in [the weekly distribution routine](/en/blog/skill-weekly-distribution-routine). ## Troubleshooting | What you see | Cause | Fix | |---|---|---| | 401 `unauthorized` | Variable not exported in the shell that launched Codex | `echo $SHAGER_API_KEY` in the same terminal, then restart Codex | | Tools missing from `/mcp` | Name not in `enabled_tools`, or listed in `disabled_tools` | Check the spelling against the tool list on [/en/agents](/en/agents) | | 403 `sandbox_unclaimed` | Key came from agent self-signup and no human has claimed it | Send the `claim_url` to a human | | 403 `forbidden` on scheduling | Key lacks `publish` | Expected for a drafting key | | 429 `rate_limited` | Over 120 requests per minute per key | Use groups and one `create_post` instead of one call per account | ## FAQ ### Does Codex need OAuth to talk to Shager? No. Codex supports bearer tokens from an environment variable, which is how Shager authenticates today. Shager's OAuth for MCP is coming, and Codex also supports OAuth servers, but you don't need to wait for it. ### Is the Shager setup different in the Codex IDE extension? OpenAI's MCP docs say the ChatGPT desktop app, Codex CLI and IDE extension share this configuration, so the same `~/.codex/config.toml` table serves all of them. Make sure the environment variable is visible to the editor process, which on macOS can mean launching the editor from a terminal. ### Can I point Codex at the REST API instead of MCP? Yes, if you're writing code rather than chatting. The [OpenAPI document](https://app.shager.ai/api/v1/openapi.json) describes the same operations as the MCP tools, with the same scopes and limits. ## Next step With Codex connected, get comfortable with the operations themselves before automating anything. The [REST API quickstart](/en/blog/shager-rest-api-quickstart) walks the full sequence from workspace to tracked post with curl and Python, which also helps you read what Codex is doing when it calls the MCP tools. --- Source: https://shager.ai/en/blog/connect-shager-to-codex # The Agency Operating Model When AI Agents Handle Distribution _2026-08-19 · How a social agency restructures roles, weekly rhythm, client workspaces and API keys when AI agents do distribution and people own strategy and approval._ An agency that uses AI agents for distribution should reorganize around three human roles, strategist, editor and client lead, plus one technical owner who runs the agents. Agents take the production line between an approved idea and a scheduled post across many accounts. People own direction, quality and the client relationship, and the weekly rhythm is built so that every agent output passes a human before it goes live. Most agencies bolt an agent onto the old structure and wonder why nothing improves. The old structure assumed that the scarce resource was hands. Once the hands are cheap, the scarce resources are judgment and review time, and the model has to be designed around those. ## What changes when production stops being the bottleneck? In a traditional social agency, account managers spend most of their week on production: writing variants, uploading, scheduling, chasing links, building reports. Their capacity sets how many accounts the agency can carry. With an agent connected to a distribution platform, production for one campaign across fifty accounts becomes a single instructed run. The constraint moves upstream to "is the idea good and approved?" and downstream to "did anyone read the results?" If you do not staff those two points, the agency simply produces more mediocre posts faster. ## Which roles does the agency need? | Role | Owns | Spends time on | Does not do | |---|---|---|---| | Strategist | Monthly themes, offers, audiences per client | Planning, reading results, client strategy calls | Writing per-account captions | | Editor | Quality of agent output | Reviewing drafts, refining the agent's rules | Scheduling by hand | | Client lead | The relationship and approvals | Sending approval links, handling feedback | Production | | Agent operator | Keys, skills, prompts, audit | Maintaining the agent setup across clients | Content decisions | In a small agency one person may hold two of these. The point is that each responsibility has a name attached. The agent operator role is new for most teams and is often missing, which is why prompts drift and nobody knows which key can publish where. ## How should client accounts be structured? Structure decides what an agent can and cannot touch by accident. 1. **One workspace per client.** Each client's accounts live in their own workspace. An agent working on Client A never sees Client B's channels in the same list. 2. **Groups that mirror the client's org chart.** Regions, brands, languages, franchise tiers. The agent targets `group_ids`, and the strategist can reason about "all northern stores" without a spreadsheet. 3. **Client-owned connections.** Clients connect their own Facebook, Instagram or YouTube accounts through a connect link, so no passwords pass through the agency. See [client connect links](/en/blog/client-connect-links) for the full flow. 4. **Keys scoped to the job.** A drafting agent gets `read` and `write`. Only the step that schedules gets `publish`. Every call shows in the audit log on the agents dashboard, which our article on [API keys, scopes and audit](/en/blog/api-keys-scopes-and-audit) walks through. If you operate one agent across many clients, the separation matters even more. Our guide to [running one agent for many clients](/en/blog/one-agent-many-clients) covers the prompt and key patterns that keep work from crossing over. ## What does the weekly rhythm look like? Here is a rhythm that works for agencies running between ten and a few hundred accounts. The days are illustrative; the order is what matters. 1. **Monday, planning.** The strategist writes a one-page brief per client: theme, offer, assets, which groups, which days, and any claims that need legal care. 2. **Monday afternoon, agent run.** The agent operator triggers the run. The agent uploads media, writes per-account captions and creates drafts. 3. **Tuesday, editorial review.** The editor reads every draft batch. Problems are fixed in the agent's rules, then the run is repeated, so the same issue does not come back next week. 4. **Tuesday afternoon, client approval.** The client lead sends approval requests. Clients approve without logging in. 5. **Wednesday, scheduling.** Approved posts are scheduled with staggered dispatch across accounts. 6. **Friday, reading results.** The agent pulls clicks per account and per post, writes a short summary, and the strategist decides what changes next week. The brief in step 1 is the most important artifact in the whole system. A vague brief produces vague posts at scale. ## What does the agent run on Monday look like? The agent operator usually keeps the run instructions in a skill so they are the same every week. A weekly instruction to the agent can be short because the rules live elsewhere: ```text Run the weekly distribution routine for workspace "Northwind Bakeries" using brief 2026-W38 (attached). Groups: "City stores", "Mall kiosks". Formats: REEL for the video, FEED for the two photos. Draft only. When done, request approval for all drafts and return the links. ``` The tool calls behind that instruction: ```text whoami check scopes: expect read, write list_workspaces select "Northwind Bakeries" list_groups resolve "City stores", "Mall kiosks" list_channels fetch account names for localization upload_media_from_url once per asset, with width, height, duration_ms for the Reel create_post per asset: caption, group_ids, media_ids, format, per_channel[...], first_comment, cta_url, campaign "w38-autumn-menu", label "agent-draft" request_approval per post, returns a link for the client ``` The `campaign` and `label` fields look like housekeeping, but they are what make Friday's reporting possible without anyone tagging posts by hand. If you want the routine itself packaged as a reusable skill, see [the weekly distribution routine](/en/blog/skill-weekly-distribution-routine). ## How should the agency price this? Pricing per post makes little sense once posting is cheap. Most agencies that move to this model price per account under management, with the strategy and reporting as the core of the retainer. On the platform side, Shager prices by connected accounts and includes API access, MCP and unlimited users on every plan, so adding an agent or a reviewer does not add seats. The current tiers are on the [pricing page](/en/pricing). ## What are the common failure modes? The first is skipping editorial review because "the agent is good now." Drift is gradual. A weekly read catches it early. The second is letting every team member run their own prompts. Two people instructing the same agent differently for the same client is how brand voice falls apart. Keep one skill per client and change it deliberately. The third is never reading Friday's numbers. If nobody acts on per-account results, the agency is producing volume, not outcomes. ## FAQ ### How many accounts can one editor review per week? That depends on post length, the number of variants and how mature the agent's rules are. Early on, review takes longer because you are still fixing the rules. Track review hours per client for the first month and set capacity from your own data. ### Should clients know an agent writes their captions? We recommend telling them. Explain that an agent drafts and a named editor reviews before anything reaches them for approval. Most clients care about quality and accountability, and this model gives them both. ### Do we need a developer to run this? No. The agent operator needs to be comfortable with API keys and editing a skill file, not writing software. The MCP connection is configuration, not code. A good first move is to pick one mid-sized client, set up the workspace and groups, and run the Monday to Friday rhythm for two weeks before changing anything else. --- Source: https://shager.ai/en/blog/agency-operating-model-with-agents # Connecting Shager to Claude Desktop: Custom Connector With Request Headers, or the mcp-remote Route _2026-08-12 · Two working ways to connect Claude Desktop to Shager's API-key MCP server: a custom connector with request headers, or mcp-remote in the desktop config file._ Claude Desktop can use Shager today, but which route works depends on your account. If the Add custom connector dialog shows a Request headers section, add https://app.shager.ai/api/mcp as a custom connector with No sign-in and an `authorization` header of `Bearer shgr_live_...`. If it doesn't, bridge the remote server through `claude_desktop_config.json` with the open source `mcp-remote` package, which forwards the same header. Both routes end in the same place: Claude in the desktop app can list your client workspaces, draft multi-account posts and pull per-account clicks. The difference is who holds the key and how much setup each teammate repeats. ## Why isn't this a one-click connector? Shager authenticates MCP clients with an API key in the `Authorization` header. OAuth sign-in for MCP is coming, but it isn't live yet. Most consumer chat apps were built around OAuth connectors, so header auth is where the friction shows up. Anthropic's documentation for [adding a connector that isn't in the directory](https://claude.com/docs/connectors/custom/add-unlisted) is explicit about this case: "If the server uses an API key, choose No sign-in and add the key under Request headers." The same page also says request header authentication "is in beta and available to a limited set of organizations." So the first route is the right one, but you may not have it yet. That's why the second route exists. ## Route 1: a custom connector with a request header Use this if you can see Request headers in the dialog. Custom connectors by URL work on Free, Pro, Max, Team and Enterprise plans according to the same page, with Free limited to one custom connector. On Free, Pro or Max: 1. Open Customize, then Connectors, and click Add custom connector. 2. Name it `Shager` and enter the MCP server URL `https://app.shager.ai/api/mcp`. 3. For Authentication, choose No sign-in. 4. Open Request headers, pick `authorization` from the list, and enter the value `Bearer shgr_live_your_key_here`. 5. Mark the header Required, then click Add. Step 4 is where most people slip. The docs state that Claude "sends the value exactly as you enter it. It doesn't add an authentication scheme or any other prefix." If you paste only the key, Shager receives `Authorization: shgr_live_...` and returns 401. Include the word `Bearer` and the space. On Team and Enterprise, an Owner adds the connector under Organization settings, then Connectors, and members connect from their own Customize page. Be careful with that pattern for Shager. A request header is one shared credential for everyone in the org, which the Anthropic page says suits "a service account" rather than per-person sign-in. With one shared Shager key, the audit log at https://app.shager.ai/dashboard/agents attributes every call to that single key. If you need per-person attribution, use Route 2 with individual keys until Shager's OAuth ships. Also note you can't edit headers later. To rotate the key, remove the connector and add it again. ## Route 2: mcp-remote in claude_desktop_config.json The desktop config file is for local servers that Claude Desktop launches as processes. Anthropic's help article on [custom connectors](https://support.claude.com/en/articles/11175166-get-started-with-custom-connectors-using-remote-mcp) describes those local servers as "a separate mechanism" from remote connectors, and a plain `url` entry there isn't how Desktop reaches a remote server. The workaround is [mcp-remote](https://github.com/geelen/mcp-remote), an open source package that runs locally over stdio and forwards requests to a remote MCP server, with custom headers. It needs Node.js installed. Open the config through Settings, then Developer, then Edit Config. The [MCP quickstart for local servers](https://modelcontextprotocol.io/docs/develop/connect-local-servers) gives the paths: `~/Library/Application Support/Claude/claude_desktop_config.json` on macOS and `%APPDATA%\Claude\claude_desktop_config.json` on Windows. ```json { "mcpServers": { "shager": { "command": "npx", "args": [ "-y", "mcp-remote", "https://app.shager.ai/api/mcp", "--header", "Authorization:${SHAGER_AUTH_HEADER}" ], "env": { "SHAGER_AUTH_HEADER": "Bearer shgr_live_your_key_here" } } } } ``` The odd-looking `Authorization:${SHAGER_AUTH_HEADER}` with no space after the colon is deliberate. The mcp-remote README warns that Claude Desktop on Windows (and some other clients) doesn't escape spaces inside `args`, so the space lives in the environment variable instead. This form works on macOS too, so use it everywhere and stop thinking about it. If you'd rather not keep the key in the config JSON, mcp-remote also accepts `--header-file` pointing at a file with one `Name: value` per line: ```text Authorization: Bearer shgr_live_your_key_here ``` Quit Claude Desktop completely and reopen it. The quickstart says the app must restart to load new config. Then open the connectors menu from the chat input and check that `shager` is listed with its tools. ### If it doesn't connect Logs live in `~/Library/Logs/Claude` on macOS (`%APPDATA%\Claude\logs` on Windows). `mcp.log` covers connection failures, and `mcp-server-shager.log` holds mcp-remote's own output. A 401 in there means the header value is wrong. A `command not found` for npx means Node isn't on the PATH that Claude Desktop sees, which is common when Node was installed through a version manager. Point `command` at the absolute path of `npx` in that case. ## Which route should you pick? | | Custom connector with request header | mcp-remote in config | |---|---|---| | Availability | Beta, limited organizations | Any Claude Desktop install with Node | | Who holds the key | Stored by Claude, not shown again | Your local config or a header file | | Works on claude.ai in the browser | Yes, it's an account connector | No, desktop only | | Per-person keys on Team plans | No, one shared header | Yes, each person configures their own | | Rotating the key | Remove and re-add the connector | Edit the file, restart | For a solo consultant, Route 1 is cleaner if you have it. For an agency with five people touching client accounts, Route 2 with individual keys keeps the audit trail honest. ## A first prompt that proves it works ```text Using Shager: who am I, which workspaces do I have, and for the workspace "Harbor Fitness" list the connected channels by network and status. ``` Then try a draft: ```text Create a draft post in "Harbor Fitness" to every active Instagram and Facebook channel. Caption: announce the new 6am class. Write a different caption per channel using the location in the channel name. cta_url https://harborfitness.example/6am, campaign "6am-launch". Don't schedule it. ``` That second prompt uses `create_post` with `per_channel` captions and a tracked `cta_url`, which gives each account its own short link with `utm_content` set to the account. You'll see the draft in Shager, where a human or the client approval link can take it from there. Our piece on [client approval workflows](/en/blog/client-approval-workflow-for-agencies) explains how agencies tend to wire that step. ## Keep the key scoped Desktop chat is where people experiment, so give this key `read` and `write` only. Without `publish`, Shager refuses `schedule_post` and any `create_post` that includes `schedule_at`, no matter what is typed in chat. Create a separate key with `publish` for the scripted routine that actually ships posts, at https://app.shager.ai/dashboard/agents. ## FAQ ### Can I just paste a url entry into claude_desktop_config.json? That file launches local servers as processes, and Anthropic documents remote servers as a separate mechanism through connectors. Use mcp-remote as the local process that forwards to the remote URL, or use a custom connector if your account has request headers. ### Will this get simpler? Yes. OAuth sign-in for Shager's MCP server is coming. Once it ships, adding https://app.shager.ai/api/mcp as a custom connector with a normal sign-in will be the simplest path on every plan, each person will connect with their own account, and the header workarounds become optional. ### Does the same setup work for Claude Code? Claude Code supports header auth natively with `claude mcp add --transport http` and `--header`, so it needs neither workaround. The steps are in [connecting Shager to Claude Code](/en/blog/connect-shager-to-claude-code). ## Next step Once Desktop can call Shager, the useful habit is to stop typing long prompts and package them as a skill. If you're on the API rather than a chat app, start with the [REST API quickstart](/en/blog/shager-rest-api-quickstart) and the [OpenAPI document](https://app.shager.ai/api/v1/openapi.json), which describe the exact same operations the connector exposes. --- Source: https://shager.ai/en/blog/connect-shager-to-claude-desktop # No Content, No Existence: Why Silent Brands Vanish When Agents Choose _2026-08-11 · When agents and answer engines decide what people see, they draw on what is published and findable. A brand that doesn't publish consistently isn't found._ When AI agents and answer engines decide what people see, they can only work with what has been published and can be found. A brand that does not publish consistently gives them nothing to retrieve, cite or recommend, so in practical terms it does not exist for that buyer. Consistent publishing is no longer a marketing nice-to-have; it is the cost of being present at all. That is a strong claim, so this piece makes the argument carefully, separates what is documented from what is inference, and ends with a working plan for agencies whose clients have gone quiet. ## What has changed about how people find businesses? For twenty years, discovery meant a list of links and a human choosing among them. A brand with a decent website and a few reviews could get by publishing rarely, because the person searching would scroll and click. Two shifts compress that. Search engines now answer questions directly. Google's documentation on [AI features and your website](https://developers.google.com/search/docs/appearance/ai-features) explains that AI Overviews and AI Mode show supporting links, and that to be one of them a page must be indexed and eligible to appear in Search with a snippet. Second, people increasingly hand the search itself to an assistant: "find me three physiotherapists near the office who handle running injuries." The assistant reads, filters and returns a short answer. In both cases a machine assembles the shortlist before a human sees anything. The shortlist is built from material that exists. That is the whole mechanism, and it is unforgiving. ## Why does silence now cost more than it used to? A shortlist of three is harsher than a page of ten. When a person scrolled, a weak presence still got an occasional click. When an engine or agent summarizes, it tends to lean on sources that are clear, current and specific to the question. A brand whose last post is from February and whose site says little about what it actually does is easy to leave out. There is no published formula that says "post this often and you will be cited." Anyone quoting one is guessing. What Google does say plainly is that [the best practices for SEO remain relevant for AI features](https://developers.google.com/search/docs/appearance/ai-features) and that there are no special optimizations required. Read that the other way round: there is no trick that substitutes for having useful, indexable material. The only lever is publishing it. ## Is this an argument for publishing more of anything? No, and this is where many teams misread the moment. Google's spam policies define [scaled content abuse](https://developers.google.com/search/docs/essentials/spam-policies) as generating many pages primarily to manipulate rankings rather than help users, "no matter how it's created." Meta's [spam policy](https://transparency.meta.com/policies/community-standards/spam/) targets very high frequency posting, manual or automated, and repetitive content. YouTube's [spam, deceptive practices and scams policies](https://support.google.com/youtube/answer/2801973) cover repetitive and untargeted posting. So the thesis has a second half. Silence makes a brand invisible, and noise makes it untrustworthy. What gets found is steady, specific, varied content tied to real offerings, published where the audience and the engines can see it. ## What "consistent" means in practice For a local or multi-location business, consistency has three dimensions: | Dimension | What it looks like | What breaks it | |---|---|---| | Rhythm | A predictable weekly floor of posts per account | Bursts before campaigns, silence after | | Coverage | Every location's account is active, not just the flagship | Thirty Pages, five of them alive | | Specificity | Posts name the service, place, price range or problem solved | Generic stock captions | Coverage is the one agencies underrate. A dental group with twenty clinics may run a strong main Page and leave nineteen local Pages untouched since launch. Someone searching for a dentist in one of those neighborhoods meets a dead Page. Each of those accounts is a separate surface where the brand either shows signs of life or does not. ## Why agents make consistency affordable The reason clients go silent is rarely strategy. It is labor. Keeping twenty accounts alive every week with captions written for each location is many hours of tedious work, and it is the first thing cut when the team is busy. That labor is exactly what an agent with access to a distribution platform does well. Our piece on [why agents should run distribution](/en/blog/why-agents-should-run-distribution) makes the full case. The short version: a human sets the monthly themes and approves, and the agent turns them into account-specific posts on a steady schedule. ## A plan to bring a quiet client back to life 1. **Audit the surfaces.** List every account and the date of its last post. The agent can do this with `list_channels` and `list_posts` for the client workspace. 2. **Set a floor, not a ceiling.** Agree with the client on a minimum weekly rhythm per account that the team can sustain for a year. 3. **Build a content bank by theme.** Services, local proof, seasonal questions, team, process. Each theme produces material for many weeks. 4. **Let the agent localize.** For each post, the agent writes per-account captions with `per_channel`, naming the neighborhood or service line that account serves. 5. **Gate with approval.** Drafts go to the client through `request_approval`, which they can answer without logging in. Our [approval workflow guide](/en/blog/client-approval-workflow-for-agencies) covers how to set expectations. 6. **Measure per account.** Every post carries a per-account short link and UTM tag, and `get_analytics` returns clicks per account and per post. Dead accounts that stay dead after two months tell you something about the audience, not the effort. A prompt for step 4 might read: ```text Workspace "Lakeside Dental". Theme this week: sensitive teeth in cold weather. Create one FEED post for the group "All clinics" with the attached image. For each clinic, write a 50 to 80 word caption that names the clinic's neighborhood and its booking hours. Same core advice everywhere, different opening and closing lines. Booking link in first_comment. Draft only. Then call request_approval and give me the approval link. ``` ## What this means for agencies The agency pitch used to be reach. Increasingly it is presence: making sure that when a person or an agent goes looking, the client is there, current and clearly described. That is a retainer worth paying for, and it is one that agents make profitable to deliver across many accounts. The [agent entry point](/en/agents) shows how to connect one. ## FAQ ### Does posting on social media help a brand appear in AI answers? There is no official statement that social posts feed any specific answer engine, so be careful with anyone who promises it. What is documented is that search AI features draw on indexed, eligible pages, and that the usual SEO practices apply. Consistent publishing across your site and public profiles increases the amount of current, specific material available to be found. ### How often should a business post to stay visible? No network or search engine publishes a number. Pick a rhythm per account the team can sustain all year, keep it steady, and judge it by the clicks and leads each account produces rather than by volume. ### Is AI-written content penalized? Google's guidance on [using generative AI content](https://developers.google.com/search/docs/fundamentals/using-gen-ai-content) says the problem is generating many pages without adding value, and that AI output should be fact-checked before publishing. The test is usefulness, not the tool. If one of your clients has gone quiet, start with the audit in step 1. It takes an agent a few minutes and usually makes the case to the client better than any deck. --- Source: https://shager.ai/en/blog/no-content-no-existence # Connect Shager to Claude Code: One Command, Then Draft Posts for 50 Accounts From Your Terminal _2026-08-04 · Add Shager's remote MCP server to Claude Code with claude mcp add and a bearer header, pick the right scope, verify it, and draft a first multi-account post._ To connect Shager to Claude Code, run `claude mcp add --transport http shager https://app.shager.ai/api/mcp --header "Authorization: Bearer shgr_live_..."` and then check `/mcp` inside a session. That registers Shager's remote MCP server over streamable HTTP, and Claude Code can immediately list your workspaces, connected accounts and posts. The whole thing takes about two minutes once you have an API key. This guide covers getting the key, choosing the right config scope, keeping the secret out of git, and the first real task worth running. ## What do you need before you start? You need two things: Claude Code installed, and a Shager API key that starts with `shgr_live_`. There are two ways to get the key. If you already have a Shager account, a human on your team creates one at https://app.shager.ai/dashboard/agents and picks the scopes (`read`, `write`, and optionally `publish`). If you don't have an account yet, the agent can sign itself up with one HTTP call and get a sandbox key back. That flow is covered in [agent self-signup and claim](/en/blog/agent-self-signup-and-claim), and the short version lives at [/auth.md](/auth.md). A word on scopes before you paste anything. For the first week, give Claude Code `read` and `write` only. It can then create workspaces, upload media and build drafts, but it can't schedule or publish anything. You add `publish` later, once you trust the drafts it produces. ## How do you add the server with claude mcp add? Claude Code's [MCP documentation](https://code.claude.com/docs/en/mcp) shows the exact form for a remote HTTP server with a bearer token: `--transport http`, a name, the URL, and `--header`. For Shager it looks like this: ```bash claude mcp add --transport http shager https://app.shager.ai/api/mcp \ --header "Authorization: Bearer shgr_live_your_key_here" ``` The docs note that `claude mcp add` saves the config without validating the credential. A typo in the key won't fail here. It fails later, when the client connects. ### Which scope should you use? The `--scope` flag decides where the config lives. Per the same docs page: | Scope | Where it is stored | Use it when | |---|---|---| | `local` (default) | Your user config, for this project only | You're trying Shager in one repo | | `project` | `.mcp.json` in the repo, shared with the team | The whole team runs content tasks from this repo | | `user` | Your user config, all projects | You want Shager available everywhere you open Claude Code | For an agency, `user` is usually the right call. Distribution isn't tied to one codebase. ```bash claude mcp add --transport http shager --scope user https://app.shager.ai/api/mcp \ --header "Authorization: Bearer shgr_live_your_key_here" ``` ## How do you share the config without committing the key? If you want a `project` scope so teammates get the server automatically, don't hardcode the key in `.mcp.json`. Claude Code supports environment variable expansion in `url` and `headers` for HTTP servers, using `${VAR}` or `${VAR:-default}`. Commit this: ```json { "mcpServers": { "shager": { "type": "http", "url": "https://app.shager.ai/api/mcp", "headers": { "Authorization": "Bearer ${SHAGER_API_KEY}" } } } } ``` Each person then exports their own key in their shell profile: ```bash export SHAGER_API_KEY="shgr_live_your_key_here" ``` Two details from the docs matter here. If the variable is unset, Claude Code still loads the config and sends the literal `${SHAGER_API_KEY}` text, with a warning in `claude mcp list`. And some reserved credential names such as `ANTHROPIC_API_KEY` deliberately expand to empty in remote headers, so always use your own variable name. `SHAGER_API_KEY` is fine. Separate keys per person also make the audit log at https://app.shager.ai/dashboard/agents useful. Every agent call is recorded against the key that made it, so you can tell whose session created which draft. ## How do you confirm it works? From the shell: ```bash claude mcp list claude mcp get shager ``` Inside a session, type `/mcp`. A healthy server shows as connected. The docs say a server with bad credentials shows as failed, and the detail includes the HTTP status. For Shager, a 401 means the header is missing or malformed. The server expects exactly `Authorization: Bearer shgr_...`, with the word Bearer and a single space. Then ask Claude something cheap and read only: ```text Call whoami on shager, then list my workspaces with their channel counts. ``` `whoami` returns the organization and the scopes on the key. If you see `read` and `write` but not `publish`, that's the setup working as intended. ## What should the first real task be? Don't start with "publish something." Start with a draft that exercises the parts of Shager that matter at scale. A good first prompt: ```text In the workspace "Northside Dental", list the channels and the account groups. Upload this video as media: https://example.com/clips/whitening-30s.mp4 (width 1080, height 1920, duration_ms 30000). Then create a DRAFT post (no schedule_at) to the group "All locations" as a REEL, with a caption per channel that mentions the city in that account's name, first_comment "Book a slot: " plus the cta_url, cta_url https://northsidedental.example/book, campaign "whitening-oct". Show me the per-channel captions before you call create_post. ``` Behind the scenes Claude chains `list_channels`, `list_groups`, `upload_media_from_url` and `create_post`. Three fields in that call do the heavy lifting. 1. `per_channel` lets every account get its own caption instead of fifty identical posts. Networks and audiences both notice duplicates, which is why we recommend it in [avoiding spam blocks at scale](/en/blog/avoid-spam-blocks-when-posting-at-scale). 2. `cta_url` gets a separate short link and UTM tag per account, with `utm_content` identifying the account. Clicks come back per account through `get_analytics`. 3. Passing width, height and `duration_ms` on upload lets Shager validate the Reel against each network's rules before anything is queued. Since no `schedule_at` was passed, the result is a draft. You review it in the Shager app or ask Claude for `get_post`. ## How do you control what Claude Code is allowed to do? Claude Code asks permission before calling MCP tools unless you allow them. MCP tools are named `mcp____`, so for Shager you'll see `mcp__shager__create_post`, `mcp__shager__list_posts` and so on. A sensible starting allowlist approves the read tools and leaves anything that writes on prompt. Pair that with a key that lacks `publish`, and you get two independent brakes: the client asks you, and the server refuses to schedule regardless. When you are ready to schedule, create a new key with `publish`, swap the environment variable, and keep the old read/write key for exploratory sessions. Shager's REST API and MCP server enforce the same scopes, so the rule holds whichever route a script takes. ## Troubleshooting checklist | Symptom | Likely cause | Fix | |---|---|---| | `/mcp` shows failed, 401 | Header missing `Bearer ` or key mistyped | Re-add the server, or check the env var is exported in the shell that launched Claude | | Tools appear but `create_post` with `schedule_at` returns 403 | Key lacks `publish`, or the sandbox is unclaimed | Expected. Draft instead, or have a human add the scope | | 429 `rate_limited` | More than 120 requests per minute on one key | Batch work; one `create_post` covers many accounts | | 422 `rejected` | A network rule failed, such as a Reel too long | Read the message; it names the account and the rule | ## FAQ ### Do I need to install anything besides Claude Code? No. Shager runs as a remote MCP server, so there's no local process, Docker container or npm package to install. Claude Code talks to https://app.shager.ai/api/mcp directly over streamable HTTP. ### Can Claude Code publish without me approving each post? Only if the key it uses has the `publish` scope and the account is claimed by a human. Without that scope, scheduling and publishing calls return 403 regardless of what the agent tries. Many teams also turn on client approval per workspace, which adds a human review step before scheduling. ### Does Shager support OAuth sign-in for Claude Code? Not yet. OAuth for MCP is coming; today authentication is the bearer API key header shown above. Claude Code handles header auth natively, so this is the smoothest client to connect right now. ## Next step Once Claude Code can see your workspaces, the natural next move is to make the routine repeatable instead of retyping prompts. The guide on [building a Claude skill for Shager](/en/blog/build-a-claude-skill-for-shager) turns the draft workflow above into a `/shager` command your whole team can run, and the [agents page](/en/agents) lists every tool and endpoint if you want the full map first. --- Source: https://shager.ai/en/blog/connect-shager-to-claude-code # Why AI Agents Should Run Social Distribution, and What Humans Should Keep _2026-08-04 · Distribution is repetitive, rule-bound work across many accounts, which makes it a natural job for AI agents. Here is what to hand over and what humans keep._ AI agents should run social distribution because most of it is structured, repetitive work with clear rules: picking accounts, adapting captions, timing posts, attaching links and reporting clicks. Humans should keep the decisions that carry judgment and liability, which means strategy, the creative itself and the final approval. Split the work along that line and an agency can serve far more accounts without the quality dropping. That split sounds obvious, yet most teams still do the opposite. A strategist spends Tuesday afternoon copying one caption into thirty-two Page composers, while nobody has time to ask whether the campaign is pointed at the right audience. The rest of this piece explains why the work belongs to agents now, how to divide it, and what a working setup looks like. ## What is distribution work, once you take the creative out? Take a single campaign for a client with forty locations. The video is done and the message is approved. What remains looks like this: | Task | Nature of the work | Who should own it | |---|---|---| | Choose which accounts get the post | Rule-based, from account groups | Agent | | Adapt the caption per account | Pattern work inside fixed constraints | Agent, with human-set rules | | Check format limits per network | Mechanical | Agent and platform | | Set the schedule and spacing | Rule-based | Agent | | Attach a tracked link per account | Mechanical | Platform | | Decide whether the post goes out | Judgment and accountability | Human | | Read the results and change course | Judgment | Human, with an agent's summary | Five of seven rows are work a person does slowly and a model does well. None of them require taste. They require patience, consistency and a memory for rules, which is where people get tired and agents do not. ## Why now and not three years ago? Two things changed. Models became reliable at following detailed written instructions across long tasks, and a common way for them to act on outside systems arrived. The [Model Context Protocol](https://modelcontextprotocol.io/docs/getting-started/intro) describes itself as an open standard for connecting AI applications to external systems, and it is supported by clients such as Claude, ChatGPT, Cursor and Visual Studio Code. Before that, every integration was a one-off script that broke when someone changed a field name. With a standard in place, a distribution platform can expose its operations as tools, and any capable agent can use them. If MCP is new to you, our [plain-language explainer for marketers](/en/blog/mcp-explained-for-marketers) covers it without the jargon. ## Why agents are better at this specific job than people The case is not that agents are smarter. It is that distribution punishes inconsistency, and consistency is cheap for software. A human scheduling posts across sixty accounts will, at some point, paste the wrong link into the wrong Page, forget the first comment on account forty-one, or schedule two client Pages at the identical minute. None of these are skill problems. They are attention problems that grow with volume. An agent working through a defined tool set does the same steps in the same order every time. It reads the account list from the platform instead of from memory. It writes a different caption for each account because the instructions say so, not because it remembered. And when the platform rejects something, it gets a structured error back and can fix it without a human noticing the problem first. ## What humans should keep, without exception Handing distribution to an agent is not handing over the brand. Three things stay with people. First, strategy. Which audience, which offer, which month. An agent can draft options; it should not pick the quarter's direction. Second, the creative claim. Anything that makes a promise about price, health, finance or results needs a human who will answer for it. Third, the publish decision. The MCP specification itself says that for trust and safety [there should always be a human in the loop with the ability to deny tool invocations](https://modelcontextprotocol.io/specification/2025-06-18/server/tools). In practice that means drafts by default and a deliberate step before anything goes live. We go deeper on where to place that gate in [human approval for agent posts](/en/blog/human-approval-for-agent-posts). ## A working setup in six steps This is the sequence we recommend for a team starting out with Shager as the distribution layer. 1. **Connect the agent.** Point an MCP client at `https://app.shager.ai/api/mcp` with an API key in the `Authorization` header. The [agent entry point](/en/agents) lists the setup for each client. 2. **Start in drafts.** Give the first key `read` and `write` scopes only. The agent can build posts but cannot schedule or publish them. 3. **Group the accounts.** Create account groups that match how the client thinks: regions, brands, languages. The agent targets groups, not forty separate IDs. 4. **Write the rules once.** Put the caption constraints, banned phrases, link rules and timing windows in a skill or system prompt, not in each request. 5. **Review a week of drafts.** Read what the agent produced. Fix the rules, not the posts. 6. **Add the publish scope.** Only after the drafts are consistently right does a human issue a key with `publish`. ## What the agent's run looks like Here is a prompt a strategist might give the agent on a Monday morning: ```text Client: Harbor Fitness, workspace "Harbor Fitness". Video: https://cdn.example.com/harbor/sept-open-house.mp4 (1080x1920, 28s). Post it as a Reel to the "Studios North" group on Thursday 18:00 local time. Write a different caption for each studio using its neighborhood name. Lead link in the first comment: https://harborfitness.example/open-house Create drafts only and send me the list for review. ``` And the tool sequence the agent runs against Shager's MCP server: ```text whoami confirm key, scopes and organization list_workspaces find "Harbor Fitness" list_groups find "Studios North" list_channels read channel names to personalize captions upload_media_from_url url, file_name, width 1080, height 1920, duration_ms 28000 create_post caption, group_ids, media_ids, format "REEL", first_comment, cta_url, per_channel[...], stagger_seconds [60, 180], no schedule_at (draft) list_posts return the drafts for human review ``` Nothing here goes live. The human reads the drafts, then either approves the schedule or sends them to the client with `request_approval`. Once the key has the publish scope, `schedule_post` puts them in the calendar, and Shager checks each post against the target network's rules before sending and dispatches with spacing between accounts. ## Where this goes wrong Teams that struggle with agent-run distribution usually make one of three mistakes. They give the first key full publish rights, so the first bad prompt becomes a public post. They let the agent post identical captions everywhere, which looks like spam to people and to platforms. Or they skip measurement, so nobody can tell whether the extra volume produced anything. Each has a fix covered elsewhere in this series, starting with [safety rules for agents posting at scale](/en/blog/safety-rules-for-agents-posting-at-scale). ## FAQ ### Does an agent replace the social media manager? No. It replaces the copy, paste and schedule part of the role. The manager's time moves to strategy, client conversations and reviewing what the agent produced, which is the part clients actually pay for. ### Which AI clients can run distribution through Shager? Any client that can connect to a remote MCP server over Streamable HTTP with a bearer token header, which includes Claude Code, Claude Desktop, Codex and Cursor. Clients that only support OAuth connectors need to wait for OAuth sign-in, which is coming, or call the REST API from code. ### Can an agent publish without a human ever being involved? Technically a key with the publish scope can schedule posts directly. We recommend against it for client accounts. Keep drafts as the default, and let a human or the client approve before anything is scheduled. The practical next step is small: connect one agent to one client workspace in draft mode and let it prepare next week's posts. The [agent entry point](/en/agents) has the connection details, and an agent can register itself through [/auth.md](/auth.md) before a human claims the sandbox. --- Source: https://shager.ai/en/blog/why-agents-should-run-distribution # Privacy Policy Shager is a B2B tool that lets agencies and marketing teams schedule content and distribute it to the social media accounts they manage, and measure the clicks and leads it brings. Shager is operated by יניב פרסלר (Yaniv Presler). For any privacy question, write to yaniv.presler@gmail.com. This policy covers the website shager.ai, the Shager app, and the short links that Shager creates. It is written for the people who use Shager (agency staff and their clients) and for anyone whose details an agency enters into Shager. ## Who is responsible for your data | Data | Who decides what happens to it | Our role | |---|---|---| | Your own Shager account (name, email, sign-in, team settings, billing contact) | יניב פרסלר (Yaniv Presler) | Controller | | Website visitors and contact form messages | יניב פרסלר (Yaniv Presler) | Controller | | Data an agency puts into its workspace about its clients and their audiences: client details, approval contacts, posts, media, connected accounts, short-link clicks and leads | The agency (our customer) | Processor, under our [Data Processing Addendum](/en/dpa) | If you are a client of an agency that uses Shager, the agency is responsible for your data. You can contact the agency directly, or write to us and we will pass your request on. **Self-hosted installations.** Shager can also be installed on a customer's own servers. In that case the customer who runs the installation is the controller of all data in it, and this policy applies only to the extent that customer adopts it. ## What data we store ### Your account - Name and email address. - A hashed password, or the fact that you sign in with Google (we receive your name, email and profile picture from Google). - Your role in the workspace and your team members. ### Your work - Clients, posts, captions, media files, schedules and campaign settings. - Approval contacts that the agency enters (name, email, phone), their approval decisions and comments. - Leads captured through Shager, as configured by the agency. ### Connected social accounts - The account or page ID, name, handle and profile picture. - The permissions you granted and the access tokens the network issued. **Access tokens are encrypted in our database.** - Publishing results: post IDs, links, status and metrics that the network returns. ### Short-link clicks When someone clicks a Shager short link, we record the time, the country, a coarse device type, the referring site, and a one-way visitor code that changes every day, so we can count unique visitors. **IP addresses are not stored.** The daily code cannot be turned back into an IP address and cannot link the same visitor across days. ### Contact form Name, email, company, your message and the time you sent it. We use it only to answer you, and delete it after 12 months. ### Technical records When you sign in to the app, your session records the IP address and browser type used, to protect your account; it is deleted when the session ends or expires. Our servers also keep short-term technical logs, such as error records, only as long as needed for security and troubleshooting. (This is separate from short-link clicks, where no IP address is stored.) ## Your language and country When you visit shager.ai we look up which country your IP address belongs to, so we can show the site in your language (Hebrew in Israel, English elsewhere). The lookup happens on our own server with a local copy of a country database; the address is not stored and not sent to anyone. IP geolocation by [DB-IP](https://db-ip.com), licensed under CC BY 4.0. ## How we use it Only to provide the service: to publish the content you scheduled to the accounts you connected, to show results and leads, to run client approvals, to keep the service secure, and to answer you. We do **not** sell data. We do **not** use it for advertising. We do **not** use it to train AI models, ours or anyone else's. | Purpose | Legal basis (GDPR) | |---|---| | Providing the service you signed up for | Performance of a contract (Art. 6(1)(b)) | | Processing workspace data for the agency | On the agency's instructions, under the [DPA](/en/dpa) | | Security, abuse prevention, service logs | Legitimate interests (Art. 6(1)(f)) | | Answering contact form messages | Legitimate interests, or steps before a contract | | Keeping records the law requires | Legal obligation (Art. 6(1)(c)) | ## YouTube and Google Shager uses **YouTube API Services** to upload videos and post comments on channels you connect. By connecting a YouTube channel you agree to the [YouTube Terms of Service](https://www.youtube.com/t/terms). See also the [Google Privacy Policy](https://policies.google.com/privacy). You can revoke Shager's access at any time in your [Google security settings](https://myaccount.google.com/permissions), or by removing the channel in Shager, which revokes access immediately. Shager's use and transfer of information received from Google APIs adheres to the [Google API Services User Data Policy](https://developers.google.com/terms/api-services-user-data-policy), including the Limited Use requirements. In particular: - We use Google user data only to provide the features you see in Shager. - We do not transfer it to others except as needed to provide those features, for security, or where the law requires it. - We do not use it for advertising, and we do not sell it. - No person at Shager reads it unless you ask us to (for example in a support request), it is needed for security, or the law requires it. - We do not use it to train AI models. ## Facebook and Instagram Shager publishes to Facebook Pages and Instagram professional accounts you connect, through Meta's official APIs. Facebook Pages connect with Facebook Login; Instagram accounts connect directly with Instagram Login, which gives us the account's id, username, name, profile picture and account type, and an access token to publish on its behalf. **To delete your data**, remove the app in Facebook (**Settings & privacy → Settings → Business integrations**) or in Instagram (**Settings → Website permissions → Apps and websites**). We delete the access tokens immediately and show you a link where you can check the status of the deletion request. You can also email yaniv.presler@gmail.com. ## TikTok and LinkedIn (coming soon) TikTok and LinkedIn are not available in Shager yet. When they are, the same principles will apply: we will access only the accounts you connect, request only the permissions needed to publish and report, store tokens encrypted, follow each network's developer terms and data storage rules, and let you disconnect at any time. We will update this policy before they go live. ## AI writing assistant Shager has an optional writing assistant powered by Anthropic. When you choose to use it, the text you send to it (for example a draft caption or instructions) is sent to Anthropic to generate a suggestion. Nothing else is sent: not your contacts, your tokens, or your leads. Anthropic does not use this text to train its models under its commercial terms. ## Who we share it with - **The social networks:** the content you choose to publish, sent to the accounts you choose. The networks are destinations you pick, not our subprocessors, and their own policies apply. - **Service providers (subprocessors):** server hosting (Hetzner Online GmbH — Helsinki, Finland (EU)) and the other providers listed on our [subprocessors page](/en/subprocessors). - **Anthropic:** only text you send to the writing assistant, when you choose to use it. - **Authorities:** only where the law requires it. - **A buyer of the business:** if the business is sold or merged, under the same commitments, and we will tell you first. ## Where the data is kept Our servers are in the European Union: Hetzner Online GmbH — Helsinki, Finland (EU). Text you send to the AI writing assistant is processed by Anthropic in the United States, under the safeguards described in our [DPA](/en/dpa). Israel and the EU recognise each other as providing adequate protection for personal data. ## How long we keep it - **While your account is active.** On a deletion request (yaniv.presler@gmail.com), data is deleted within **7 days** and from backups within **30 days**. - **When you remove a channel**, its access tokens are deleted immediately (for YouTube, also revoked at Google). - **Data retrieved from network APIs** is refreshed or deleted within **30 days**. - **Short-link click records** are kept as part of the workspace's reports and deleted with the workspace. - **Contact form messages** are deleted after **12 months**. ## Security Traffic is encrypted (HTTPS), access tokens are encrypted at rest, and access to the servers is limited to the operator. More on our [security page](/en/security). ## Your rights Under the Israeli Privacy Protection Law, including Amendment 13 (in force since August 2025), you may ask to see the data we hold about you and to correct or delete it. If the GDPR applies to you, you may also ask us to restrict or object to processing, to give you your data in a portable format, and to withdraw consent where we rely on it. To make a request, write to yaniv.presler@gmail.com. We will answer within 30 days. If your data is in an agency's workspace, we will forward your request to that agency, which decides on it, and help it respond. You may also complain to the Israeli Privacy Protection Authority, or to the data protection authority in your EU country. **EU representative:** we have not yet appointed a representative in the EU under Article 27 GDPR. Until we do, contact us directly at yaniv.presler@gmail.com. ## Cookies We use only strictly necessary first-party cookies, for sign-in and for connecting accounts. No analytics, advertising or third-party cookies. Details on our [cookies page](/en/cookies). ## Children Shager is a business service. It is not meant for children, and we do not knowingly collect data about children under 16. ## Changes If we change this policy, we will update the date at the top. If a change matters, we will tell account holders by email or in the app before it takes effect. ## Contact יניב פרסלר (Yaniv Presler) הכרמים 20/2, ישראל (HaKramim St. 20/2, Israel) yaniv.presler@gmail.com --- Source: https://shager.ai/en/privacy # Terms of Service Shager is operated by יניב פרסלר (Yaniv Presler). By using Shager you agree to these terms, to the [Privacy Policy](/en/privacy) and to the [Acceptable Use Policy](/en/acceptable-use). If you use Shager on behalf of a company, you confirm that you may bind it, and "you" means that company. Shager is a business service. It is meant for agencies, marketers and companies, not for consumers. ## The service Shager lets you schedule, get client approval for, and distribute content to social media accounts you manage, and measure clicks and leads. It publishes only through each network's official API. Live networks today: Facebook Pages, Instagram professional accounts and YouTube. TikTok and LinkedIn are coming soon and are not yet available. ## Your account - Give accurate details and keep them up to date. - Keep your and your team's sign-in details safe. You are responsible for what happens under your account, including what your team members do. - Tell us at yaniv.presler@gmail.com if you think your account has been accessed without permission. ## Your responsibilities - Connect only accounts you are authorized to manage, and publish only content you have the right to publish. - Follow each network's terms, including the [YouTube Terms of Service](https://www.youtube.com/t/terms), Meta's terms and every network's community guidelines. By connecting a YouTube channel, you agree to be bound by the [YouTube Terms of Service](https://www.youtube.com/t/terms), and Google's handling of that data is described in the [Google Privacy Policy](https://policies.google.com/privacy). - Do not use Shager for spam, deception, impersonation, unlawful content, or to evade networks' limits or detection systems. The full list is in the [Acceptable Use Policy](/en/acceptable-use). - If you enter other people's personal data (for example your clients' approval contacts or leads), make sure you are allowed to, and that you have told them as the law requires. ## Your content Your content stays yours. You allow Shager to store, process (for example convert an image format) and publish it to the accounts you choose, only to provide the service. You are responsible for your content and for the results of publishing it. We do not review content before it is published. ## Clients and personal data When you put your clients' data or their audiences' data into Shager, you are the controller and we are your processor. Our [Data Processing Addendum](/en/dpa) is part of these terms and applies automatically. ## AI writing assistant The writing assistant suggests text. Its suggestions may be wrong or unsuitable. Check them before you publish. You are responsible for what you publish. ## Fees Paid plans, if you use one, are charged as shown in your order or on the pricing page at the time you sign up. We will give you at least 30 days' notice before a price change that affects you. Fees are not refundable unless the law requires otherwise or we agree in writing. ## Availability and changes The service is provided as is. Networks change their APIs and may reject or limit posts; their decisions are not ours. There may be maintenance downtime. We do not promise any reach, engagement or number of leads. We may change or improve features. If we remove a feature that is central to a paid plan, we will tell you in advance. ## Suspension and termination We may suspend accounts that break these terms or the Acceptable Use Policy, or that put the service, the networks or other people at risk. Where possible we will tell you first and give you a chance to fix the problem. You can stop using Shager and ask us to delete your account at any time by writing to yaniv.presler@gmail.com. Before deletion you can export your data. After deletion, data is removed as described in the [Privacy Policy](/en/privacy). ## Self-hosted installations If you run Shager on your own servers, you are the operator of that installation. You are responsible for its security, backups, updates, legal pages and compliance, and for the network developer apps you connect to it. ## Limitation of liability To the fullest extent the law allows, we are not liable for indirect or consequential damages (such as lost profits, lost data, lost reach or business interruption), and our total liability is limited to what you paid us in the last 12 months. Nothing in these terms limits liability that cannot be limited by law, such as liability for fraud or wilful misconduct. ## Indemnity If a third party makes a claim against us because of content you published through Shager or because you broke these terms, you will cover our reasonable costs of that claim. ## Changes to these terms If we change these terms, we will update the date at the top. If a change matters, we will tell account holders at least 14 days in advance. If you keep using Shager after the change takes effect, the new terms apply. ## Law and jurisdiction These terms are governed by Israeli law; the courts of Tel Aviv-Jaffa have exclusive jurisdiction. ## Contact Questions: yaniv.presler@gmail.com. --- Source: https://shager.ai/en/terms # Cookie Policy ## The short version Shager uses only cookies that are strictly necessary for the service to work: to keep you signed in, and to connect a social account safely. We use **no** analytics cookies, **no** advertising cookies and **no** third-party cookies. That is why there is no cookie banner: the law does not require consent for strictly necessary cookies. The cookies below are used by the app. Reading the public website (shager.ai) does not require any of them. ## The cookies we use | Cookie | Purpose | Set by | Lifetime | |---|---|---|---| | `better-auth.session_token` | Keeps you signed in to the app | Shager (first party) | Until you sign out or the session expires | | Other `better-auth.*` cookies | Support sign-in, for example during sign-in with Google | Shager (first party) | Minutes to the length of the session | | `shager_connect_` | Protects the connection of a social account (OAuth state), so that no one else can complete it in your name | Shager (first party) | Deleted when the connection finishes, and at most 24 hours | Over HTTPS, some of these names may start with the `__Secure-` prefix. All of them are marked `HttpOnly` where possible, so scripts on the page cannot read them. ## What we do not use - No analytics or tracking tools (no Google Analytics, no pixels). - No advertising or retargeting cookies. - No cookies from social networks on our pages. Short links created in Shager do not set cookies. How short-link clicks are counted is explained in the [Privacy Policy](/en/privacy). ## Managing cookies You can block or delete cookies in your browser settings. If you block the cookies above, you will not be able to sign in to the app or connect accounts. The public website will keep working. ## Changes If we ever add a cookie that is not strictly necessary, we will update this page and ask for your consent before setting it. Questions: yaniv.presler@gmail.com. --- Source: https://shager.ai/en/cookies # Accessibility Statement We want everyone, including people with disabilities, to be able to use the Shager website and app. This statement is published in line with the Israeli Equal Rights for Persons with Disabilities Law and its accessibility regulations for services. ## Target level Our target is conformance with **WCAG 2.2 at level AA** and with **Israeli Standard IS 5568**, which is based on the WCAG guidelines. ## How we build the site We design and build to these practices: - The site is built in Hebrew, right to left, with a full English version. Each page declares its language and direction. - Pages use real headings, landmarks and lists, so screen readers can move through them. - Everything can be used with a keyboard, and the keyboard focus is always visible. - Text and controls meet the contrast requirements, in both light and dark themes. - Text can be enlarged up to 200% without losing content, and the layout works on narrow screens. - Animations respect the "reduce motion" setting of your system. - Forms have visible labels and clear error messages. - We do not use an accessibility overlay widget. We fix the site itself. ## Known limitations We are honest about what is not finished yet: - **Blog images:** we are still adding full text alternatives to some images in older blog posts. - **Third-party content:** previews of posts from social networks and media uploaded by users may not be fully accessible. We do not control that content. - **The app:** parts of the app are newer than the public website and are still being checked against the same standard. If you find anything else, please tell us. ## Review The site was last reviewed for accessibility on 2026-10-13. We review it again when we make significant changes. ## Reporting a problem If you run into an accessibility problem, or need information in another format, contact our accessibility coordinator: יניב פרסלר (Yaniv Presler) yaniv.presler@gmail.com הכרמים 20/2, ישראל (HaKramim St. 20/2, Israel) Please describe the problem, the page where it happened, and, if you can, the browser and assistive technology you used. We will answer within **14 days**. --- Source: https://shager.ai/en/accessibility # Legal Notice ## Operator Shager (shager.ai) is operated by: יניב פרסלר (Yaniv Presler) הכרמים 20/2, ישראל (HaKramim St. 20/2, Israel) Business no.: 031204175 Email: yaniv.presler@gmail.com ## Responsible for content יניב פרסלר (Yaniv Presler) is responsible for the content of this website. Contact: yaniv.presler@gmail.com. ## Hosting Hetzner Online GmbH — Helsinki, Finland (EU) ## Disputes Shager is offered only to businesses, not to consumers. For this reason the EU Online Dispute Resolution platform for consumer disputes does not apply, and we do not take part in dispute resolution proceedings before a consumer arbitration board. If you have a complaint, write to us at yaniv.presler@gmail.com and we will try to solve it directly. ## Links to other sites This website links to other sites, such as the social networks' terms. We are not responsible for their content. ## More legal information - [Privacy Policy](/en/privacy) - [Terms of Service](/en/terms) - [Cookie Policy](/en/cookies) - [Accessibility Statement](/en/accessibility) - [Data Processing Addendum](/en/dpa) - [Subprocessors](/en/subprocessors) - [Acceptable Use Policy](/en/acceptable-use) - [Security](/en/security) --- Source: https://shager.ai/en/imprint # Data Processing Addendum This Data Processing Addendum ("**DPA**") is part of the [Terms of Service](/en/terms) between יניב פרסלר (Yaniv Presler) ("**Shager**", "**we**") and the customer that uses Shager ("**Customer**", "**you**"). It applies automatically whenever Shager processes personal data on your behalf. If you need a signed copy, write to yaniv.presler@gmail.com. ## 1. Definitions Terms such as "personal data", "processing", "controller", "processor", "data subject" and "personal data breach" have the meanings given in the EU General Data Protection Regulation 2016/679 ("**GDPR**"). Where the Israeli Privacy Protection Law, 5741-1981, and its regulations, including the Privacy Protection (Data Security) Regulations, 2017 and Amendment 13 ("**Israeli Privacy Law**") apply, the matching terms in that law apply as well ("database owner" corresponds to controller, "holder" to processor). "**Data Protection Law**" means all of these laws, as far as they apply. "**Customer Personal Data**" means personal data that Shager processes on your behalf when providing the service. ## 2. Roles - For Customer Personal Data, **you are the controller** and **Shager is the processor**. - For the data of your own account holders that Shager needs to run the account (sign-in, billing, support), Shager is an independent controller under the [Privacy Policy](/en/privacy). This DPA does not cover that data. - If you are yourself a processor for your clients, Shager is your subprocessor, and you confirm that your clients have authorised you to appoint us. ## 3. Details of the processing | Item | Description | |---|---| | Subject matter | Providing Shager: scheduling, approving, publishing and measuring social media content | | Duration | For the term of the Terms of Service, plus the deletion periods in section 11 | | Nature | Storage, hosting, organisation, transmission to the social networks you choose, retrieval of results, deletion | | Purpose | Only to provide the service to you, as described in the Terms and as you configure it | | Categories of data subjects | Your staff and team members; your clients and their contact persons; people who approve content; people who click your short links; leads you capture; people who appear in your content | | Categories of personal data | Names, email addresses, phone numbers, job roles; social account IDs, names, pictures and access tokens; content you upload (text, images, video), which may include people's likeness; approval decisions; short-link click data (time, country, coarse device type, referring site, a daily-rotating one-way visitor code, **no IP address**); lead details you choose to collect | | Special categories | Not intended. Do not upload special categories of personal data unless you have a lawful basis and have told us | ## 4. Your instructions We process Customer Personal Data only on your documented instructions. The Terms, this DPA, and the way you configure and use the service are your instructions. If we believe an instruction breaks Data Protection Law, we will tell you. If the law requires us to process data in another way, we will tell you first, unless the law forbids that. You are responsible for having a lawful basis for the processing, and for giving data subjects the information the law requires. ## 5. Confidentiality Everyone at Shager who can access Customer Personal Data is bound by confidentiality and accesses it only as needed to provide the service, to give support you asked for, or for security. ## 6. Security We apply the technical and organisational measures in **Annex 1**, which are appropriate to the risk. We may improve them over time, but we will not reduce the overall level of protection. ## 7. Subprocessors You give us general authorisation to use subprocessors. The current list is on our [subprocessors page](/en/subprocessors). - We bind each subprocessor by a written contract with data protection obligations no less protective than this DPA. - We will notify you at least **30 days** before a new subprocessor starts processing Customer Personal Data, by email or in the app, and update the subprocessors page. - You may object on reasonable data protection grounds within that period. We will then try in good faith to find a solution. If we cannot, you may terminate the affected service and receive a pro-rata refund of prepaid fees for it. - We remain responsible to you for our subprocessors' performance. The social networks you publish to (such as Meta and Google) are not our subprocessors. You choose to send content to them, and their terms apply. ## 8. International transfers - Customer Personal Data is hosted in the European Union (Hetzner Online GmbH, servers in Helsinki, Finland). - Text that a user chooses to send to the AI writing assistant is processed by Anthropic PBC in the United States. Where such text includes personal data from the EU, the transfer relies on the EU-U.S. Data Privacy Framework where the recipient is certified under it, and otherwise on the European Commission's Standard Contractual Clauses included in the provider's data processing terms. - Transfers from Israel rely on the Privacy Protection (Transfer of Data to Databases Abroad) Regulations, 2001, including the transfer to EU countries. - We will not transfer Customer Personal Data to another country without a lawful transfer mechanism. ## 9. Helping you Taking into account the nature of the processing, we will help you: - respond to data subject requests (access, correction, deletion, restriction, portability, objection). If we receive such a request directly, we will pass it to you without undue delay and will not answer it ourselves unless you ask us to; - meet your obligations on security, breach notification, data protection impact assessments and prior consultation with authorities. Much of this you can do yourself in the app, for example by editing or deleting contacts, posts and accounts. ## 10. Personal data breaches If we become aware of a personal data breach affecting Customer Personal Data, we will notify you **without undue delay, and in any case within 72 hours**. The notice will describe, as far as we know at the time, what happened, the data and data subjects affected, the likely consequences, and what we have done or propose to do. We will send further information as it becomes available, and take reasonable steps to contain the breach. ## 11. Deletion and return - While the service is active, you can export and delete your data in the app. - When the service ends, or when you ask, we delete Customer Personal Data within **7 days**, and from backups within **30 days**, unless the law requires us to keep it. - Before deletion you can ask us for a copy of your data in a common machine-readable format. - Access tokens are deleted immediately when you remove a connected account (and for YouTube, also revoked at Google). ## 12. Audits We will make available the information needed to show compliance with this DPA, including written answers to reasonable security questionnaires, once a year or after a personal data breach. If that is not enough, or an authority requires it, you may audit us, at your cost, with at least 30 days' notice, during business hours, without disrupting the service, and through an auditor bound by confidentiality. We do not currently hold third-party certifications such as SOC 2 or ISO 27001. ## 13. Liability Each party's liability under this DPA is subject to the limitations of liability in the [Terms of Service](/en/terms), as far as the law allows. ## 14. Order of precedence and law If this DPA conflicts with the Terms, this DPA prevails on data protection matters. If the Standard Contractual Clauses apply and conflict with this DPA, the Clauses prevail. This DPA is governed by the law and jurisdiction set out in the Terms, except where Data Protection Law requires otherwise. ## Annex 1: Security measures ### Encryption - All connections use TLS (HTTPS), including between the app and the networks' APIs. - Social network access tokens are encrypted at rest with AES-256-GCM. - Passwords are stored only as salted hashes. ### Access control - Access to production servers and databases is limited to the operator. Server login uses SSH keys only; password login is disabled. - In the app, each workspace is separated from the others, and team roles control who can do what. - Sessions use secure, HTTP-only cookies. - Client approval links carry a random token that is stored only as a hash, expire, can be revoked, and give access to a single post only. ### Data minimisation - We request only the OAuth permissions each feature needs (least privilege). - Short-link clicks are recorded without IP addresses, using a one-way visitor code that rotates daily. - Only text the user chooses to send reaches the AI writing assistant. ### Availability and recovery - Servers are hosted in the EU, in a professional data centre. Media files are stored on our own servers, not with a third-party storage provider. - Daily server backups. Deleted data disappears from backups within 30 days. ### Operations - Operating system security updates are installed automatically. - A firewall allows only web (HTTP/HTTPS) and SSH traffic. - Vulnerabilities can be reported to yaniv.presler@gmail.com (see the [security page](/en/security)). ## Annex 2: Subprocessors See the [subprocessors page](/en/subprocessors), which is part of this DPA. --- Source: https://shager.ai/en/dpa # Subprocessors These are the third-party providers that may process personal data when we provide Shager. They are bound by written agreements that protect the data at least as well as our [Data Processing Addendum](/en/dpa). ## Current subprocessors | Provider | What it does | Data involved | Location | |---|---|---|---| | Hetzner Online GmbH | Server hosting, storage and backups | All service data, stored on our servers | Germany (company); servers in Helsinki, Finland (EU) | | Anthropic PBC | AI writing assistant | Only text a user chooses to send to the assistant | United States | | Internet Security Research Group (Let's Encrypt) | TLS certificates for encrypted connections | No personal data, only our domain names | United States | | GoDaddy | DNS for our domain | No personal data, only DNS records | United States | ## Planned | Provider | What it will do | Status | |---|---|---| | Transactional email provider | Sending sign-in, approval and notification emails | Not in use yet. It will be listed here before we start using it. | | SMS / WhatsApp messaging provider | Sending approval links by SMS or WhatsApp, if the agency chooses to | Not in use yet. It will be listed here before we start using it. | ## Not subprocessors: the social networks Meta Platforms (Facebook, Instagram) and Google (YouTube), and later TikTok and LinkedIn, receive the content you choose to publish, sent to the accounts you choose. They are destinations picked by you, not providers working for us, and their own terms and privacy policies apply. ## Changes We will update this page and notify customers who have accepted the DPA at least **30 days** before a new subprocessor starts processing personal data. If you have a reasonable data protection objection, write to yaniv.presler@gmail.com within that period. The process is described in the [DPA](/en/dpa). Self-hosted installations are run by the customer, who chooses its own providers. This list does not apply to them. --- Source: https://shager.ai/en/subprocessors # Acceptable Use Policy Shager helps agencies publish to many accounts. That only works if every post is legitimate, and if the networks keep trusting the tools that publish to them. This policy is part of the [Terms of Service](/en/terms). ## Do not use Shager for ### Spam and mass duplication - Publishing the same or nearly the same content across many accounts in order to flood feeds, game the algorithm, or look bigger than you are. - Repetitive, unsolicited or misleading posts, comments or links. - Posting to accounts at a pace or volume meant to get around a network's limits. ### Fake engagement - Buying, selling or exchanging likes, follows, views, comments or shares. - Running networks of fake, automated or inauthentic accounts, or coordinating accounts to fake popularity. - Using comments (including first comments) to manipulate engagement rather than to inform. ### Impersonation and deception - Pretending to be another person, brand or organisation, or connecting accounts you are not authorised to manage. - Hiding that content is paid or promotional where the law or the network requires disclosure. - Misleading links: short links must lead where people expect them to. ### Unlawful or harmful content - Content that breaks the law, infringes copyright, trademarks or privacy, or that you have no right to publish. - Hate speech, harassment, threats, sexual content involving minors, violent extremism, or fraud. - Sending messages or collecting leads in breach of anti-spam or privacy law, including Israel's Communications Law (the "spam law") and the GDPR. ### Abusing the service or the networks - Trying to evade a network's limits, review or detection systems. - Scraping, reverse engineering or overloading Shager or the networks' APIs. - Accessing other customers' data, or testing our security without following our [responsible disclosure process](/en/security). ## What we expect instead - **Original content per account.** Each account should get content that fits its audience. Shager's tools (captions per network, first comments and tracking per account, staggered dispatch) exist to help you do this. Use them. - **Real authorisation.** Every connected account belongs to you or to a client who has authorised you to manage it. - **Honest disclosure.** Mark commercial, sponsored or AI-generated content where the law or the network requires it. ## Respect each network's rules When you publish through Shager, you also agree to follow the rules of each network you publish to, including: - Meta: [Meta Terms of Service](https://www.facebook.com/terms.php), [Instagram Terms of Use](https://help.instagram.com/581066165581870), [Meta Platform Terms](https://developers.facebook.com/terms/) and Community Standards. - YouTube: [YouTube Terms of Service](https://www.youtube.com/t/terms) and Community Guidelines. - TikTok (coming soon): [TikTok Terms of Service](https://www.tiktok.com/legal/terms-of-service), Community Guidelines, the Branded Content Policy and the Music Usage Confirmation. - LinkedIn (coming soon): [LinkedIn User Agreement](https://www.linkedin.com/legal/user-agreement) and Professional Community Policies. If a network's rules are stricter than this policy, the network's rules apply. ## What we may do If we believe this policy has been broken, we may remove content from the queue, pause publishing, disconnect accounts, or suspend or close the account, and, where the law requires it, report to the authorities. Where possible we will tell you first and give you a chance to fix the problem. In urgent cases (for example a risk to the networks, to other customers, or to people) we may act first and tell you afterwards. ## Reporting abuse If you see content published through Shager that breaks this policy, write to yaniv.presler@gmail.com with the link and a short explanation. --- Source: https://shager.ai/en/acceptable-use # Security Agencies connect their clients' social accounts to Shager. We treat that access as the most sensitive thing we hold. This page describes what we do today. It is not a certification. ## Encryption - **In transit:** every connection, to the website, the app and the networks' APIs, uses TLS (HTTPS). Certificates come from Let's Encrypt. - **At rest:** social network access tokens are encrypted in the database with **AES-256-GCM**. Passwords are stored only as salted hashes, never in plain text. ## Access to social accounts - **Least privilege:** we request only the OAuth permissions each feature needs, and we explain them when you connect. - **You stay in control:** you can disconnect an account in Shager at any time, which deletes its tokens immediately (for YouTube, they are also revoked at Google). You can also revoke access from the network's own settings. - **Official APIs only:** Shager never asks for your social network passwords and never uses browser automation. ## Hosting - Servers are hosted by Hetzner Online GmbH — Helsinki, Finland (EU), in the European Union. - Media files are stored on our own servers, not with a third-party storage provider. - Server backups are taken every day. Deleted data disappears from backups within 30 days. - Access to production servers is limited to the operator. Login uses SSH keys only; password login is disabled. - A firewall allows only web and SSH traffic, and operating system security updates are installed automatically. ## In the app - Each workspace's data is separated from other workspaces. - Team roles (owner, admin, member, and per-workspace manager, editor or viewer) control who can see each client and who can connect accounts and publish. - Sign-in sessions use secure, HTTP-only cookies. - Client approval links carry a random token that we store only as a hash. Each link expires, can be revoked, opens a single post only, and can never be used to sign in. ## Privacy by design - Short-link clicks are counted without storing IP addresses, using a one-way visitor code that rotates daily. - No analytics, advertising or third-party trackers on our site. - The AI writing assistant receives only the text you choose to send it. ## What we do not claim We do not currently hold SOC 2, ISO 27001 or any other security certification. If your procurement process needs a security questionnaire answered, write to yaniv.presler@gmail.com. ## Reporting a vulnerability If you think you have found a security problem in Shager, please email yaniv.presler@gmail.com with the details and how to reproduce it. We ask that you: - give us reasonable time to fix it before you disclose it publicly; - do not access, change or delete data that is not yours, and stop as soon as you reach any; - do not run denial-of-service tests, spam, or social engineering against us or our customers. We will confirm receipt, keep you updated, and will not take legal action against good-faith research that follows these rules. ## If something goes wrong If a personal data breach affects your data, we will notify affected customers without undue delay, and within 72 hours where the law or our [DPA](/en/dpa) requires it. --- Source: https://shager.ai/en/security # הסוכן שלך יוצר. שַׁגֵּר מפיצה לכל מקום. בעולם החדש, מי שאין לו תוכן, לא קיים. שַׁגֵּר לוקחת את מה שהסוכן שלך או הצוות שלך יוצרים ומשגרת אותו לעשרות ומאות עמודי פייסבוק, חשבונות אינסטגרם וערוצי יוטיוב, בקצב שהרשתות מאשרות, עם קישור מעקב לכל חשבון. - API ושרת MCP בכל מסלול - סוכן יכול לפתוח חשבון בעצמו - 14 יום ניסיון, בלי כרטיס אשראי ## לסוכנים: תן לסוכן שלך להפיץ ולעקוב אחרי כל מספר. שַׁגֵּר נבנתה כדי שסוכן AI יעבוד איתה ישירות. Claude, ChatGPT, Cursor או סוכן שבניתם בעצמכם מתחברים דרך שרת MCP או דרך API, ובשפה רגילה: מעלים סרטון, בונים פוסט לכל חשבון, שולחים ללקוח לאישור, מתזמנים, ושואלים מחר מה הביא לידים. - **חיבור בדקה:** כתובת MCP ומפתח אחד. אין SDK להתקין ואין אינטגרציה לתחזק. - **סוכן פותח חשבון לבד:** קריאה אחת יוצרת סביבת עבודה. אדם מאשר בקישור לפני שמשהו עולה לאוויר. - **נתונים שהסוכן קורא:** קליקים לפי חשבון, סטטוס פרסום ושגיאות, במבנה שסוכן מבין ופועל לפיו. ## פחות עבודה ידנית. יותר נוכחות. כל ליד עם כתובת. - **פעם אחת במקום מאה:** פוסט אחד מגיע לכל החשבונות, מותאם לכל רשת. בלי העתק והדבק, בלי לשכוח סניף. - **כל ליד משויך:** קישור קצר ותגית UTM לכל חשבון ולכל פוסט. רואים בדיוק איזה עמוד הביא את הפנייה. - **בלי חסימות:** API רשמי, פיזור שליחה בין חשבונות ובדיקת פורמט לפני השליחה, לא אחרי שהרשת דחתה. - **הלקוח מחבר בעצמו:** שולחים ללקוח קישור, הוא מחבר את העמודים שלו, בלי לפתוח חשבון ובלי למסור סיסמה. - **הלקוח מאשר בקישור:** תצוגה מקדימה, אישור או בקשת תיקון. נגמרו צילומי המסך בוואטסאפ. - **עברית קודם:** ממשק מימין לשמאל, עוזר כתיבה בעברית ולוח חגים של כל הדתות. ## הפצה: מתזמנים פעם אחת. יוצא לכולם. בוחרים קבוצת חשבונות (לקוח, סניפים, מותגים) וְשַׁגֵּר עושה את השאר: מתאימה את הפוסט לכל רשת, בודקת שהמדיה עומדת בדרישות, ומפזרת את השליחה לאורך דקות כדי שזה לא ייראה כמו ספאם. - **קבוצות חשבונות:** עשרות או מאות חשבונות בבחירה אחת, לפי לקוח או קמפיין. - **פיזור חכם:** השליחה מתפרסת בזמן ומכבדת את מגבלות הקצב של כל רשת. - **בדיקה לפני שליחה:** כותרת ליוטיוב, יחס מסך לסרטוני Shorts, אורך כיתוב: הכול נבדק מראש. ## לידים: כל חשבון מקבל קישור משלו. לכל פוסט בכל חשבון נוצרים קישור קצר ותגית UTM נפרדת. הקישור יכול לצאת בתגובה הראשונה, איפה שהקהל באמת לוחץ, והדוח מתפצל לבד לפי עמוד, סניף וסרטון. - **UTM לכל חשבון:** utm_content מזהה את החשבון, והדוחות שלכם בכלי Google Analytics מתפצלים לבד. - **קישורים קצרים משלנו:** ספירת קליקים לכל חשבון ולכל פוסט, בלי לשמור כתובות IP. - **תגובה ראשונה:** קישור הליד יוצא בתגובה מיד אחרי הפרסום, ברשתות שמאפשרות קישור לחיץ. ## לקוחות: הלקוח מחבר ומאשר. אתם מפרסמים. פותחים לקוח, שולחים לו קישור חיבור, והוא מחבר את עמודי הפייסבוק, האינסטגרם והיוטיוב שלו בעצמו. כשיש פוסט, הוא מקבל קישור לתצוגה מקדימה ומאשר. רק מה שאושר יוצא לדרך. - **קישור חיבור ללקוח:** הלקוח מתחבר ישירות מול הרשת. אתם רואים את החשבונות מיד ומקבלים הודעה. - **קישור אישור לכל פוסט:** תצוגה מקדימה כמו ברשת עצמה. אישור או בקשת תיקון בלחיצה. ## בנוי לעבוד עם הרשתות, לא נגדן. - **API רשמי בלבד:** אין בוטים, אין גירוד ואין התחברות בשמכם. כל חשבון מחובר בהרשאה שאפשר לבטל בכל רגע. - **אדם מאשר, סוכן מבצע:** סביבה שסוכן פתח לא מפרסמת כלום עד שאדם מאשר אותה. כל פעולה של סוכן נרשמת. - **מפתחות מוצפנים:** מפתחות הגישה לרשתות מוצפנים במסד הנתונים ולא יוצאים מהשרת. - **אירוח באירופה:** השרתים בפינלנד, באיחוד האירופי. בלי עוגיות מעקב באתר. אפשר גם להתקין אצלכם. ## מתחילים באפס שקלים. משלמים לפי חשבונות, לא לפי משתמשים. API, שרת MCP ומשתמשים ללא הגבלה בכל מסלול. חינם לתמיד עם 3 חשבונות, ו־10 חשבונות תמורת 29 ₪ לחודש. מפרסמים רק דרך הממשק הרשמי (API) של Facebook, Instagram, YouTube. בפיתוח: TikTok, LinkedIn. --- Source: https://shager.ai/ # מהחיבור הראשון ועד הליד. בלי עבודה ידנית באמצע. חמישה שלבים. אותו תהליך לעשרה חשבונות או לחמש מאות, ואותו תהליך כשמי שמפעיל אותו הוא אתם או הסוכן שלכם. ## תהליך 1. **מחברים חשבונות.** כל לקוח מקבל סביבת עבודה משלו. מחברים בעצמכם, או שולחים ללקוח קישור חיבור והוא מחבר את עמודי הפייסבוק, האינסטגרם והיוטיוב שלו לבד, במסך ההרשאות הרשמי של הרשת. שַׁגֵּר לא רואה ולא שומרת סיסמאות. 2. **מארגנים בקבוצות.** קבוצות לפי לקוח, אזור, מותג או קמפיין. חשבון יכול להיות בכמה קבוצות. בחירה של קבוצה אחת בעורך = כל החשבונות שבה. 3. **כותבים פעם אחת, או נותנים לסוכן.** עורך אחד לכל הרשתות: טקסט, תמונות, וידאו, כותרת ליוטיוב, פורמט (פוסט, רילס, סטורי, Shorts) ותגובה ראשונה. מעדיפים שסוכן AI יעשה את זה? הוא עושה בדיוק את אותו הדבר דרך MCP או API. 4. **מאשרים מול הלקוח.** אם צריך, הלקוח מקבל קישור לתצוגה מקדימה, מאשר או מבקש תיקון. בלי חשבון ובלי צילומי מסך. 5. **משגרים ומודדים.** שַׁגֵּר שולחת בפיזור שמכבד את מגבלות הרשתות, מנסה שוב כשהרשת עמוסה, ומדווחת על כל חשבון. כל פוסט יוצא עם קישור ותגית UTM משלו, וספירת הקליקים מגיעה לדוח. ## מה בפנים - **API ושרת MCP:** סוכן AI מתחבר ומפעיל את כל המערכת, בכל מסלול. - **קישור חיבור ללקוח:** הלקוח מחבר את החשבונות שלו בעצמו, בלי לפתוח חשבון. - **קבוצות חשבונות ובחירה מרוכזת:** בחירה של עשרות ומאות חשבונות בבת אחת. - **פיזור שליחה:** מרווחים בין חשבונות כדי לכבד את קצב הרשת ולמנוע חסימות. - **בדיקת מדיה מראש:** יחס מסך, אורך וידאו, כותרות ומגבלות טקסט נבדקים לפני השליחה. - **תגובה ראשונה:** קישור הליד בתגובה, ברשתות שמאפשרות קישור לחיץ. - **UTM וקישורים קצרים:** תגית לכל חשבון וספירת קליקים בלי כתובות IP. - **קישורי אישור ללקוח:** אופציונלי לכל סביבת עבודה. - **לוח חגים של כל הדתות:** חגי ישראל, אסלאם, נצרות, דרוזים, הינדואיזם, בודהיזם ועוד, עם המלצה לכל יום: לא לפרסם, רגיש או הזדמנות. גם הסוכן שלכם מקבל אותו. - **עוזר כתיבה בעברית:** ניסוח, קיצור והתאמת טון. אתם מחליטים מה יוצא. - **התקנה עצמית:** אותה מערכת בשרת שלכם, עם Docker. ## שאלות נפוצות ### זה לא ספאם? לא, כשעושים את זה נכון. שַׁגֵּר מפרסמת רק בחשבונות שאתם מנהלים ומורשים לפרסם בהם, דרך הממשק הרשמי (API), בקצב שהרשתות מאפשרות. אנחנו ממליצים להתאים את התוכן לכל חשבון (הכלים בעורך בנויים בדיוק לזה), ותנאי השימוש אוסרים ספאם. ### אילו רשתות נתמכות? פייסבוק (עמודים), אינסטגרם (חשבונות מקצועיים) ויוטיוב. טיקטוק ולינקדאין בפיתוח, ונעדכן כשיעלו. ### אתם שומרים את הסיסמאות שלנו? לא. החיבור נעשה במסך ההרשאות של הרשת עצמה, ואנחנו מקבלים מפתח גישה מוגבל שמוצפן אצלנו. אפשר לבטל אותו בכל רגע, אצלנו או בהגדרות הרשת. ### איפה הנתונים נשמרים? בשרתים באיחוד האירופי (פינלנד). אפשר גם להתקין את שַׁגֵּר בשרת שלכם. ### כמה זה עולה? מתחילים בחינם עם 3 חשבונות, לתמיד. מסלול יוצר: 10 חשבונות תמורת 29 ₪ לחודש לפני מע״מ, ועוד 4 ₪ לכל חשבון נוסף. API, MCP ומשתמשים ללא הגבלה בכל מסלול. כל המסלולים בעמוד המחירים. ### סוכן AI יכול לעבוד עם שַׁגֵּר לבד? כן. סוכן מתחבר דרך שרת MCP או דרך API, ויכול אפילו לפתוח סביבה בעצמו. שום דבר לא מתפרסם עד שאדם מאשר את הסביבה בקישור. --- Source: https://shager.ai/product # רשתות נתמכות. רק דרך הממשק הרשמי (API). כל חיבור נעשה במסך ההרשאות של הרשת עצמה, עם ההרשאות המינימליות שצריך כדי לפרסם, על ידיכם, או על ידי הלקוח עצמו דרך קישור חיבור. אפשר לבטל בכל רגע. ## Facebook (פעיל) - סוג חשבון: עמודים (Pages) - פורמטים: פוסט, תמונות, וידאו, רילס, סטורי - הערות: תגובה ראשונה עם קישור לחיץ. חיבור דרך Facebook Login for Business. - API: Meta Graph API ## Instagram (פעיל) - סוג חשבון: חשבונות מקצועיים (עסקי / יוצר), מתחברים ישירות עם אינסטגרם, בלי צורך בעמוד פייסבוק - פורמטים: פוסט, קרוסלה, רילס, סטורי - הערות: קישורים בכיתוב ובתגובות אינם לחיצים באינסטגרם, לכן מודדים דרך קישור בביו או תגית UTM. - API: Instagram API with Instagram Login ## YouTube (פעיל) - סוג חשבון: ערוצים - פורמטים: סרטונים רגילים וסרטוני Shorts - הערות: כותרת ופרטיות לכל סרטון, תגובה ראשונה בסרטונים ציבוריים. - API: YouTube Data API v3 ## TikTok (בפיתוח) - סוג חשבון: חשבונות עסקיים ויוצרים - פורמטים: וידאו ותמונות - הערות: בהמתנה לאישור הגישה מטיקטוק. הגדרות פרטיות וגילוי תוכן מסחרי ייבחרו לכל פוסט. - API: TikTok API for Business ## LinkedIn (בפיתוח) - סוג חשבון: פרופילים ועמודי חברה - פורמטים: טקסט, קישור, תמונות, וידאו, מסמכים - הערות: בהמתנה לאישור Community Management API מלינקדאין. - API: LinkedIn Posts API ## העקרונות שלנו בכל חיבור - הרשאות מינימליות: רק מה שצריך כדי לפרסם ולמדוד. - מפתחות גישה מוצפנים במסד הנתונים, ומבוטלים מול הרשת כשמסירים חשבון. - כיבוד מגבלות הקצב והמכסות של כל רשת, ופיזור שליחה בין חשבונות. - פרסום רק בחשבונות שהמשתמש מנהל ומורשה לפרסם בהם. - קישור חיבור ללקוח: הלקוח מתחבר בעצמו מול הרשת, בלי חשבון בְּשַׁגֵּר ובלי למסור סיסמה. - מחיקת נתונים לפי בקשה, כולל קריאות מחיקה של Meta. --- Source: https://shager.ai/networks # בונים את תשתית ההפצה של עידן הסוכנים. מישראל. ״לְשַׁגֵּר״: לשלוח למקום הנכון, בזמן הנכון. זה כל הרעיון: תוכן אחד שמגיע לכל החשבונות שהוא צריך להגיע אליהם, ונמדד בכל אחד מהם. סוכנויות ישראליות מנהלות היום עשרות ומאות עמודים וחשבונות: לקוחות עם סניפים, רשתות זכיינים, מותגים עם תתי מותגים. הכלים הקיימים נבנו לחשבון אחד או לחמישה, באנגלית, ובלי מושג על חגים, על עברית או על הדרך שבה לקוח ישראלי מאשר תוכן. התוצאה מוכרת: העתק והדבק לכל עמוד, וואטסאפים לאישור, ואין דרך לדעת איזה חשבון הביא את הליד. שַׁגֵּר נבנתה כדי לסגור את שלושת הפערים האלה (הפצה, אישור ומדידה) במקום אחד. ובקרוב מי שיעשה את העבודה הזו בכלל לא יהיה אדם. סוכני AI כבר כותבים, עורכים ומתכננים קמפיינים, וחסרה להם דרך אמינה להפיץ, לפי הכללים, ולמדוד מה עבד. לכן בנינו את שַׁגֵּר כך שסוכן יוכל לעבוד איתה ישירות, ואדם יישאר זה שמאשר. ## במה אנחנו לא מתפשרים - **רק דרך הדלת הראשית:** API רשמי של כל רשת, הרשאות מינימליות, ושום טריק שמסכן את החשבונות של הלקוחות שלכם. - **מספרים אמיתיים:** מה שאנחנו מודדים, אנחנו מראים. מה שאנחנו לא יודעים, אנחנו לא ממציאים, גם לא באתר הזה. - **עברית קודם:** ממשק מימין לשמאל, עוזר כתיבה בעברית ולוח חגים של כל הדתות. לא תרגום של מוצר זר. - **הנתונים שלכם:** אירוח באיחוד האירופי, מפתחות מוצפנים, מחיקה לפי בקשה, ואפשרות להתקין את כל המערכת אצלכם. --- Source: https://shager.ai/about # הסוכן שלך כבר יודע לכתוב. עכשיו הוא יודע גם להפיץ. שַׁגֵּר היא תשתית ההפצה שסוכנים עובדים איתה ישירות: שרת MCP, API מתועד, והרשמה שסוכן יכול לעשות בעצמו. הסוכן מייצר, מתזמן ומודד, ואדם מאשר לפני שמשהו עולה לאוויר. ## שלושה צעדים, בלי SDK. ### 1. הסוכן פותח סביבה קריאה אחת מחזירה מפתח API וקישור אישור. בסביבה הזו הסוכן יכול ליצור לקוחות, להעלות מדיה, לבנות טיוטות ותצוגות מקדימות, אבל לא לפרסם. ``` curl -X POST https://app.shager.ai/api/v1/agent/signup \ -H 'content-type: application/json' \ -d '{"agent_name":"Acme marketing agent", "contact_email":"owner@acme.com", "purpose":"Distribute weekly videos to 40 branch pages"}' ``` ```json { "data": { "api_key": "shgr_live_…", "claim_url": "https://app.shager.ai/claim/…", "sandbox": true, "mcp_url": "https://app.shager.ai/api/mcp", "expires_at": "…" } } ``` ### 2. מחברים את שרת MCP מדביקים את ההגדרה בלקוח MCP: Claude Desktop, Claude Code, Cursor או כל לקוח אחר. אפשר גם לעבוד ישירות מול ממשק REST API. ``` { "mcpServers": { "shager": { "url": "https://app.shager.ai/api/mcp", "headers": { "Authorization": "Bearer shgr_live_…" } } } } ``` ### 3. אדם מאשר, והסוכן מפיץ הבעלים פותח את קישור האישור, נכנס, מחבר את החשבונות (או שולח ללקוח קישור חיבור), ומרגע זה הסוכן מתזמן ומפרסם בפועל. ## מה הסוכן יכול לעשות - `whoami`: undefined - `list_workspaces`: רשימת הלקוחות (סביבות עבודה) - `create_workspace`: פתיחת לקוח חדש - `list_channels`: החשבונות המחוברים, לפי לקוח או קבוצה - `create_connect_link`: קישור שהלקוח מחבר דרכו את החשבונות שלו - `list_groups`: קבוצות חשבונות - `create_group`: יצירת קבוצה (סניפים, מותגים, קמפיין) - `upload_media_from_url`: העלאת תמונה או וידאו מכתובת - `create_post`: פוסט אחד לעשרות ומאות חשבונות, עם התאמה לכל רשת - `schedule_post`: תזמון עם פיזור שליחה בין חשבונות - `request_approval`: קישור אישור ללקוח - `get_post`: סטטוס הפרסום בכל חשבון, כולל שגיאות - `list_posts`: לוח התוכן - `get_analytics`: קליקים ולידים לפי חשבון ולפי פוסט - `cancel_post`: ביטול תזמון - `get_holidays`: undefined ## סוכן מבצע. אדם מחליט. - **שום דבר לא עולה בלי אדם:** סביבה שסוכן פתח נשארת במצב טיוטה עד שאדם מאשר אותה בקישור. - **מפתחות מוגבלים:** כל מפתח שייך לארגון אחד, ואפשר לבטל אותו בכל רגע. - **מגבלות קצב והיקף:** תקרות פרסום לחשבון וליום, ופיזור שליחה שמכבד את מגבלות הרשתות. - **יומן פעולות:** כל פעולה של סוכן נרשמת: מי, מה, מתי ובאיזה מפתח. - רשתות פעילות: Facebook (עמודים), Instagram (חשבונות מקצועיים), YouTube. בפיתוח: TikTok, LinkedIn. - פרסום רק דרך API רשמי, ורק בחשבונות שהמשתמש מנהל ומורשה לפרסם בהם. - מספרים באתר הם המחשה, אלא אם נאמר אחרת. ## קריא למכונות מקצה לקצה - `/llms.txt`: מפת האתר לסוכנים: מה זה שַׁגֵּר, ואיפה כל דף. - `/llms-full.txt`: כל התוכן הציבורי בקובץ Markdown אחד. - `/md/…`: גרסת Markdown לכל דף. לדוגמה: /md/pricing - `https://app.shager.ai/api/v1/openapi.json`: מפרט OpenAPI מלא של ממשק REST API. - `/sitemap.xml`: כל הדפים בשתי השפות, עם קישורי hreflang. ## מה עוד בונים - **התחברות OAuth לשרת MCP:** כניסה עם חשבון שַׁגֵּר ישירות מתוך לקוח MCP, בלי להעתיק מפתח. - **CLI:** שורת פקודה עם התחברות במכשיר, לסקריפטים ולצינורות CI. - **קישור תשלום לבעלים:** הסוכן שולח לאדם קישור לתשלום, ועובד בתוך תקציב שהאדם קובע. --- Source: https://shager.ai/agents # משלמים לפי חשבונות. כל השאר כלול. מתחילים בחינם עם החשבונות שכבר יש לכם, ומוסיפים חשבונות אחד אחד כשאתם גדלים. API, שרת MCP ומשתמשים ללא הגבלה בכל מסלול, גם בחינמי. 14 יום ניסיון בכל מסלול בתשלום, בלי כרטיס אשראי. | Plan | Price / month | Accounts | Includes | |---|---|---|---| | חינם | ₪0 ($0) | 3 | 3 חשבונות; 30 פוסטים בחודש; API ושרת MCP; 50 קרדיטים לעוזר AI | | יוצר | ₪29 ($9) | 10 | 10 חשבונות; פוסטים ללא הגבלה; ₪4 לכל חשבון נוסף; 150 קרדיטים לעוזר AI | | Pro | ₪59 ($19) | 25 | 25 חשבונות; UTM וקישורים קצרים לכל חשבון; ₪4 לכל חשבון נוסף; 300 קרדיטים לעוזר AI | | סוכנות | ₪209 ($69) | 60 | 60 חשבונות; קישורי חיבור ללקוח; קישורי אישור ללקוח; 1,000 קרדיטים לעוזר AI | | סוכנות+ | ₪389 ($129) | 150 | 150 חשבונות; כל מה שבסוכנות; 2,500 קרדיטים לעוזר AI; תמיכה מועדפת | | Scale | ₪899 ($299) | 500 | 500 חשבונות; ₪1.1 לכל חשבון נוסף; 6,000 קרדיטים לעוזר AI; תקרות API גבוהות | | Network | בהתאמה | 1,000+ | תמחור לפי חשבון; שרת ייעודי; הסכם רמת שירות; התקנה עצמית | המחירים בשקלים לפני מע״מ (18%). בתשלום שנתי, חודשיים מתנה. מדיה נשמרת 90 יום אחרי הפרסום. ## מה שלא תשלמו עליו בנפרד - **API ושרת MCP:** הסוכן שלכם מתחבר מהיום הראשון. בלי תוספת ובלי מסלול מפתחים. - **משתמשים ללא הגבלה:** כל הצוות, כל הלקוחות המאשרים. לא משלמים לפי כיסא. - **עברית מלאה:** ממשק מימין לשמאל, עוזר כתיבה בעברית ולוח חגים של כל הדתות. - **אירוח באירופה:** שרתים באיחוד האירופי ומפתחות מוצפנים, בלי עלות נוספת. ## פוסטים של סוכנים כלולים כל מסלול כולל 50 פוסטים של סוכן לחודש על כל חשבון (במסלול סוכנות: 3,000). מעבר לזה, ₪3 לכל 1,000 פוסטים, עם תקרה שאתם קובעים. קריאות ודוחות לא נספרים. ## שאלות על מחיר ### מה נחשב חשבון? כל עמוד פייסבוק, חשבון אינסטגרם או ערוץ יוטיוב מחובר נחשב חשבון אחד. חשבון מושהה לא נספר. ### למה יותר חשבונות? כל חשבון נוסף הוא עוד קהל שרואה את אותו תוכן. אם אתם כבר יוצרים פוסט אחד, להפיץ אותו לעשרה חשבונות לא דורש מכם יותר עבודה. לכן במסלולים יוצר ו־Pro אפשר להוסיף חשבון אחד בכל פעם, בלי לקפוץ מסלול. ### המחיר כולל מע״מ? לא. המחירים בשקלים לפני מע״מ 18%, ומקבלים חשבונית מס. ללקוחות מחוץ לישראל המחיר בדולרים. ### אפשר להתקין אצלנו? כן. גרסת Community חינמית עד 10 חשבונות. רישיון סוכנות (עד 200 חשבונות) ורישיון ללא הגבלה זמינים לפי בקשה. ### מה קורה בסוף הניסיון? בוחרים מסלול או עוברים לחינם. שום דבר לא נמחק, ואין חיוב אוטומטי, כי לא ביקשנו כרטיס אשראי. ### אפשר לעבור מסלול באמצע? כן, בכל רגע. משדרגים מיד ומשלמים רק על ההפרש היחסי. --- Source: https://shager.ai/pricing # צור קשר בקשת גישה, הדגמה או שאלה? ספרו לנו כמה חשבונות אתם מנהלים ובאילו רשתות. - Email: yaniv.presler@gmail.com - Form: https://shager.ai/contact --- Source: https://shager.ai/contact # בלוג: שיווק מותג, לידים והפצה בהיקף מדריכים מעשיים לסוכנויות: קול מותג אחיד, מדידת לידים לכל חשבון, אישור לקוח ופרסום בהיקף בלי להיחסם. - [איך סוכן AI מתזמן פוסטים לפי החגים של כל קהל, ולא רק לפי לוח אחד?](https://shager.ai/blog/holiday-aware-posting-for-agents): סוכן שמפרסם לעשרות חשבונות צריך להתאים כל קהל למסורת שלו. כך עובדים עם לוח החגים של שַׁגֵּר, הכלי get_holidays והשדה calendar_notes בלי פוסט צורם ביום אבל. - [מבריף ללקוח עד פוסט באוויר: מקרה עבודה מלא של סוכן AI עם שַׁגֵּר](https://shager.ai/blog/from-brief-to-published): מקרה עבודה מלא, צעד אחרי צעד: בריף של לקוח, טיוטות לכל חשבון, אישור לקוח בקישור, תזמון מדורג, בדיקת פרסום ולחיצות לכל חשבון, עם קריאות MCP אמיתיות לאורך הדרך. - [שיווק מותג מול שיווק לידים: איך סוכנות בונה את שניהם יחד](https://shager.ai/blog/b2b-brand-marketing-lead-generation): למה סוכנות לידים צריכה גם תוכן מותג, איך מחלקים את לוח התוכן בין השניים, איך מודדים כל אחד מהם ואיך מסבירים ללקוח למה זה משתלם. - [קישור הליד בתגובה הראשונה: איך סוכן בונה פוסט שמודד פניות מכל חשבון](https://shager.ai/blog/first-comment-lead-links-with-agents): איך סוכן AI מציב את קישור הליד בתגובה הראשונה בְּשַׁגֵּר: קישור מקוצר ותגיות UTM לכל חשבון, התנהגות שונה בכל רשת, ניסוח אחר לכל עמוד ובדיקת הלחיצות אחרי הפרסום. - [לפרסם בהיקף בלי להיחסם: קצב, גיוון ותוכן מקורי לכל רשת](https://shager.ai/blog/avoid-spam-blocks-when-posting-at-scale): איך סוכנות מפרסמת בעשרות חשבונות בלי להיתקל בחסימות: עבודה דרך API רשמי, קצב פרסום מדורג, תוכן מקורי לכל חשבון וכללים שהרשתות מפרסמות. - [צינור תוכן של סוכן מקצה לקצה: מבריף של לקוח ועד דוח לחיצות לפי עמוד](https://shager.ai/blog/agent-content-pipeline-end-to-end): איך נראה צינור תוכן מלא שסוכן AI מריץ מול שַׁגֵּר: בריף, ניסוח לכל חשבון, מדיה, טיוטה, אישור לקוח, פרסום מדורג ומדידה, ומה נשאר בידיים של אדם בכל אחד מהשלבים. - [איך לבחור פלטפורמת הפצה שסוכן AI יכול באמת להפעיל: 12 שאלות לפני שמתחייבים](https://shager.ai/blog/choosing-a-distribution-platform-for-agents): רוב כלי ההפצה נבנו לאדם מול מסך. 12 שאלות שבודקות אם פלטפורמה באמת מתאימה לסוכן AI: גישה, הרשאות, בקרה, ניסוח לכל חשבון, מדידה, תמחור ומיקום של הנתונים. - [סוכנים שכותבים עברית טובה: כיווניות, משלב, חגים והתאמה לקהל הישראלי](https://shager.ai/blog/hebrew-content-agents): איך גורמים לסוכן AI לכתוב עברית שנשמעת ישראלית ולא מתורגמת: בעיות RTL בטקסט מעורב, משלב ולשון פנייה, חגים ומועדים, ומה שַׁגֵּר נותן לעבודה שוטפת בעברית. - [הפצת וידאו קצר לכל הרשתות: התאמות פורמט, אורך וכיתוב](https://shager.ai/blog/video-first-distribution-reels-shorts): איך להפיץ סרטון קצר לרילס, לשורטס ולעמודי פייסבוק בלי לאבד איכות: יחס תצוגה, אזורים בטוחים, אורך, כתוביות, כיתוב לכל רשת ותזמון בהיקף. - [אתר שסוכנים יודעים לקרוא: llms.txt, גרסאות Markdown, OpenAPI וכרטיס שרת MCP](https://shager.ai/blog/agent-ready-websites-llms-txt): מה צריך כדי שסוכן AI יבין אתר ושירות בלי לנחש: קובץ llms.txt, עמודי Markdown, מפרט OpenAPI, קטלוג API וכרטיס שרת MCP, עם האתר shager.ai כדוגמה עובדת מלאה. - [תהליך אישור לקוח שלא תוקע את לוח התוכן](https://shager.ai/blog/client-approval-workflow-for-agencies): איך בונים תהליך אישור לקוח שעובד: מה מאשרים ומה לא, דדליינים ברורים, קישור אישור במקום שרשורי וואטסאפ, וכללים למקרה שהלקוח לא עונה. - [מפתחות API, הרשאות ויומן פעולות: איך נותנים לסוכן גישה לְשַׁגֵּר בלי לאבד שליטה](https://shager.ai/blog/api-keys-scopes-and-audit): מדריך להרשאות read, write, publish בְּשַׁגֵּר: מה כל הרשאה מאפשרת, איזה מפתח לתת לכל סוכן, איך שומרים את המפתח מחוץ לקוד, ומה רואים ביומן הפעולות של הסוכנים. - [MCP למשווקים: מה זה, למה זה חשוב לסוכנות ומה זה משנה בעבודה](https://shager.ai/blog/mcp-explained-for-marketers): MCP הוא תקן פתוח שמאפשר לסוכני AI להשתמש ישירות בכלים חיצוניים. הסבר בלי ז'רגון למשווקים: איך זה עובד, מה זה מאפשר לסוכנות, ואיך מחברים את שַׁגֵּר לסוכן שלכם היום. - [שגרת הפצה שבועית עם skill: כל יום ראשון בבוקר, טיוטות לכל הלקוחות מחכות לאישור](https://shager.ai/blog/skill-weekly-distribution-routine): איך בונים skill עבור Claude Code שמריץ שגרת הפצה שבועית מול שַׁגֵּר: קריאת בריף, טיוטות לכל חשבון, שליחה לאישור, דוח לחיצות, והרצה אוטומטית עם claude -p וגם cron. - [איך למדוד לידים מכל חשבון בנפרד: UTM, קישורים מקוצרים ותגובה ראשונה](https://shager.ai/blog/utm-per-account-lead-attribution): מדריך מעשי לשיוך לידים לכל עמוד וחשבון: מבנה UTM עקבי, קישור מקוצר לכל חשבון, תגובה ראשונה עם הקישור, והעברת הנתונים עד למערכת CRM. - [סוכן אחד, עשרים לקוחות: איך מפרידים בין לקוחות כשסוכן AI מנהל את ההפצה](https://shager.ai/blog/one-agent-many-clients): איך סוכנות מפעילה סוכן AI אחד לכמה לקוחות בְּשַׁגֵּר בלי לערבב ביניהם: סביבת עבודה לכל לקוח, קבוצות חשבונות, אישור לקוח, הוראות לכל מותג ובקרה ביומן הפעולות. - [שמירה על קול מותג אחיד כשמפרסמים בעשרות חשבונות](https://shager.ai/blog/brand-consistency-across-many-accounts): איך סוכנות שמנהלת עשרות עמודים וחשבונות שומרת על קול מותג אחד בלי לשכפל טקסטים: מדריך סגנון, תבניות, שכבות התאמה ובקרת איכות. - [איך בונים skill של Claude לעבודה עם שַׁגֵּר: SKILL.md אחד שמלמד את הסוכן להפיץ נכון](https://shager.ai/blog/build-a-claude-skill-for-shager): מדריך לבניית Agent Skill לְשַׁגֵּר: מבנה התיקייה, השדות name וגם description בקובץ SKILL.md, איפה הוא יושב בכלי Claude Code ובאתר claude.ai, ומה לכתוב בו כדי שיעבוד נכון. - [קישורי חיבור ללקוחות: איך מחברים עשרות חשבונות בלי לבקש אף סיסמה](https://shager.ai/blog/client-connect-links): קישור חיבור מאפשר ללקוח לחבר את פייסבוק, אינסטגרם או יוטיוב שלו בעצמו, בלי חשבון בְּשַׁגֵּר ובלי למסור לאף אחד סיסמה. כך זה עובד, ואיך סוכן AI מנהל את כל התהליך. - [דוח לקוח שבועי שהסוכן כותב לבד: לחיצות לכל חשבון, תקלות ומה עושים הלאה](https://shager.ai/blog/weekly-client-report-by-agent): איך סוכן AI מפיק דוח שבועי ללקוח מנתוני שַׁגֵּר: get_analytics לכל חשבון ולכל פוסט, בדיקת פוסטים שנכשלו, חיבור utm_content ללידים ותבנית דוח מוכנה בעברית. - [גיוון כיתובים לכל חשבון עם AI: אותו מסר, ניסוח אחר בכל עמוד](https://shager.ai/blog/caption-variation-per-account-with-ai): איך סוכן AI כותב כיתוב שונה לכל עמוד וחשבון בלי שום צורך לאבד את המסר: מה משתנה ומה נשאר קבוע, תבנית פרומפט, שימוש בשדה per_channel ובדיקת איכות לפני כל פרסום. - [ממשק REST API של שַׁגֵּר בעשר דקות: מהקריאה whoami ועד פוסט מתוזמן לעשרות חשבונות](https://shager.ai/blog/shager-rest-api-quickstart): מדריך מהיר לממשק REST API של שַׁגֵּר: אימות Bearer, מבנה תשובות ושגיאות, מגבלת קצב, ורצף קריאות אמיתי מסביבת עבודה, דרך העלאת מדיה וטיוטה, ועד תזמון ואנליטיקס. - [פרומפטים לסוכן תוכן: שש הוראות מוכנות להעתקה לעבודה עם שַׁגֵּר](https://shager.ai/blog/prompts-for-a-content-agent): שישה פרומפטים מלאים בעברית לסוכן תוכן שעובד עם שַׁגֵּר: הוראות קבועות, הפצה שבועית, גיוון כיתובים, וידאו קצר, בדיקת איכות לפני תזמון ודוח שבועי ללקוח. - [סוכן שפותח לעצמו חשבון: הרשמה עצמית לסביבת הניסוי (sandbox) של שַׁגֵּר, ואיך אדם לוקח בעלות](https://shager.ai/blog/agent-self-signup-and-claim): איך סוכן AI נרשם לְשַׁגֵּר בלי עזרה אנושית: קריאת POST אחת לנתיב agent/signup, מה מותר בסביבת sandbox, מה חסום עד אישור, ואיך אדם מאשר את הבעלות ובוחר אם לאפשר פרסום. - [עשרה כללי בטיחות לסוכן AI שמפרסם לעשרות חשבונות](https://shager.ai/blog/safety-rules-for-agents-posting-at-scale): לפני שנותנים לסוכן הרשאת פרסום לעשרות חשבונות, צריך כללים ברורים: הרשאה מינימלית, פיזור בזמן, ניסוח שונה לכל חשבון, בדיקת מדיה, מתג עצירה ויומן ביקורת. - [אסטרטגיית תזמון לסוכן: שעות, אזורי זמן, חגים וקצב פרסום בעשרות חשבונות](https://shager.ai/blog/scheduling-strategy-for-agents): איך מלמדים סוכן AI לתזמן פוסטים בְּשַׁגֵּר בלי טעויות: schedule_at עם היסט, מעבר לשעון חורף, חגים ושבת, פריסה מדורגת, זמן לאישור לקוח ובדיקה אחרי הפרסום. - [סוכן שמפיץ וידאו קצר: רילס, שורטס ועמודי פייסבוק מקובץ אחד](https://shager.ai/blog/agent-short-video-distribution): מדריך מעשי לסוכן AI שמפיץ סרטון קצר דרך שַׁגֵּר: העלאה עם מידות ואורך, בחירת פורמט לכל רשת, כותרת ליוטיוב, כיתוב שונה לכל חשבון ופריסה מדורגת בין העמודים. - [איך מודדים לידים מתוכן שסוכן AI הפיץ: חשבון אחרי חשבון, פוסט אחרי פוסט](https://shager.ai/blog/measuring-leads-from-agent-content): סוכן שמפיץ לעשרות חשבונות חייב לייצר במקביל גם מדידה ברמת החשבון. כך בונים שיוך לידים עם UTM, קישור מקוצר לכל חשבון, הפעולה get_analytics וחיבור למערכת CRM. - [שַׁגֵּר וגם ChatGPT: למה המחבר עוד לא עובד, ואילו שלוש דרכים כן עובדות היום](https://shager.ai/blog/shager-and-chatgpt): ChatGPT מתחבר לשרתי MCP רק עם OAuth או בלי אימות, וְשַׁגֵּר עובד היום עם מפתח API. הסבר כן על הפער, ושלוש דרכים מעשיות לעבוד עם מודלים של OpenAI וְשַׁגֵּר כבר עכשיו. - [שַׁגֵּר בתוך Cursor: קובץ mcp.json אחד, והסוכן שבונה את דף הנחיתה גם מפיץ אותו](https://shager.ai/blog/connect-shager-to-cursor): מדריך לחיבור שַׁגֵּר אל Cursor דרך .cursor/mcp.json: כתובת השרת, כותרת Authorization עם משתנה סביבה, הבדל בין הגדרה לפרויקט לגלובלית, ותרחיש עבודה שלם מהקוד להפצה. - [אישור אנושי לפוסטים של סוכן AI: איפה בדיוק לשים את נקודת העצירה](https://shager.ai/blog/human-approval-for-agent-posts): סוכן שמפרסם בלי בקרה הוא סיכון, וסוכן שכל פוסט שלו נבדק ידנית לא חוסך כלום. כך בונים שכבות אישור לפי רמת סיכון, עם הרשאות, אישור לקוח ובדיקת מצב שוטפת. - [מודל ההפעלה של סוכנות שעובדת עם סוכני AI: מי עושה מה, ומתי](https://shager.ai/blog/agency-operating-model-with-agents): איך בונים סוכנות שבה סוכני AI מריצים את ההפצה ואנשים מחזיקים את האסטרטגיה: תפקידים, שבוע עבודה קבוע, סביבת עבודה לכל לקוח, הרשאות, ומה בדיוק נמדד בסוף. - [חיבור שַׁגֵּר אל Codex CLI: שלוש שורות בקובץ config.toml ומפתח שלא נכנס לקובץ](https://shager.ai/blog/connect-shager-to-codex): איך מגדירים את שרת MCP של שַׁגֵּר בכלי Codex CLI של OpenAI: בלוק mcp_servers בקובץ config.toml, bearer_token_env_var במקום מפתח גלוי, הגדרה לפרויקט ובדיקה עם /mcp. - [שַׁגֵּר בתוך Claude Desktop: מה עובד היום עם מחבר מותאם, ומה עושים אם אין כותרות](https://shager.ai/blog/connect-shager-to-claude-desktop): איך מחברים את שַׁגֵּר אל Claude Desktop כמחבר מותאם עם כותרת Authorization, למה claude_desktop_config.json לא המקום לשרת מרוחק, ומה עושים כשאין Request headers. - [אין תוכן, אין קיום: מותג שלא מפרסם בעקביות פשוט לא נמצא](https://shager.ai/blog/no-content-no-existence): כשסוכנים ומנועי תשובות מחליטים מה אנשים רואים, הם בוחרים רק מתוך מה שפורסם ונגיש. מותג שלא מפרסם בעקביות לא מפסיד חשיפה. הוא פשוט לא קיים בשבילם, וזה כבר קורה. - [איך מחברים את שַׁגֵּר אל Claude Code: פקודה אחת, מפתח אחד ובדיקה שהכול עובד](https://shager.ai/blog/connect-shager-to-claude-code): מדריך מעשי לחיבור שרת MCP של שַׁגֵּר אל Claude Code: הפקודה claude mcp add עם כותרת Authorization, בחירת scope, קובץ .mcp.json לצוות ובדיקת חיבור ראשונה ומהירה. - [למה סוכן AI צריך להריץ את ההפצה ולא רק לכתוב את הפוסטים](https://shager.ai/blog/why-agents-should-run-distribution): כתיבה היא החלק הקל. ההפצה לעשרות חשבונות היא עבודה חוזרת, מבוססת חוקים ורגישה לטעויות, ובדיוק שם סוכן AI עם כלים נכונים ובקרה אנושית מחזיר את ההשקעה שלו. --- Source: https://shager.ai/blog # איך סוכן AI מתזמן פוסטים לפי החגים של כל קהל, ולא רק לפי לוח אחד? _2026-10-13 · סוכן שמפרסם לעשרות חשבונות צריך להתאים כל קהל למסורת שלו. כך עובדים עם לוח החגים של שַׁגֵּר, הכלי get_holidays והשדה calendar_notes בלי פוסט צורם ביום אבל._ סוכן שמתזמן פוסטים לעשרות חשבונות צריך לדעת לכל חשבון אילו מסורות חשובות לקהל שלו, ולבדוק כל מועד מול החגים של המסורות האלה לפני שהוא לוחץ על תזמון. בְּשַׁגֵּר זה עובד בשתי שכבות: הכלי `get_holidays` מחזיר את החגים בטווח תאריכים עם המלצת פרסום לכל יום, וכל פוסט שנוצר או מתוזמן חוזר עם השדה `calendar_notes`, שמראה מה קורה ביום שבו הוא ייצא. ההתאמה בין קהל למסורת נשארת אצלכם ואצל הסוכן, וזה בדיוק החלק שאסור לדלג עליו. ## למה לוח חגים אחד לא מספיק לסוכנות? תחשבו על חמישה לקוחות שיושבים באותה סביבת עבודה: עסק משפחתי בכפר דרוזי בגליל, רשת מרפאות שרוב המטופלים שלה בחברה הערבית, חנות שמוכרת לקהל חרדי, מרכז קהילתי לדוברי רוסית שחלק מהקהל שלו חוגג לפי הכנסייה האורתודוקסית, ומותג מסחר מקוון שמוכר לאירופה ולארצות הברית. אותו יום שלישי יכול להיות יום רגיל לארבעה מהם ויום שבו פוסט מבצע ייראה רע מאוד אצל החמישי. אדם שמנהל חמישה לקוחות זוכר את זה בראש. סוכן שמנהל מאה חשבונות לא זוכר שום דבר שלא כתבתם לו. לכן כל מי שמריץ [סוכן אחד על הרבה לקוחות](/blog/one-agent-many-clients) צריך לשמור לכל לקוח פרופיל קהל קצר, ובו שורה אחת שחשובה כאן: אילו מסורות רלוונטיות לקהל הזה. ## מה יש בלוח החגים של שַׁגֵּר? הלוח מכסה את המסורות הגדולות: יהודית וישראלית, מוסלמית, נוצרית מערבית, נוצרית אורתודוקסית, דרוזית, בהאית, הינדית, בודהיסטית, סיקית, ג'יינית, סינית ופרסית. בנוסף יש בו ימים בינלאומיים ומסחריים כמו ולנטיין, יום האישה, יום האם ויום האב האמריקאיים, האלווין, יום הרווקים, חג ההודיה, בלאק פריידיי, סייבר מאנדיי וראש השנה האזרחית. לכל יום מוצמדת המלצת פרסום באחת מארבע רמות: | המלצה | מה היא אומרת | דוגמאות | | --- | --- | --- | | `avoid` | לא לפרסם תוכן שיווקי לקהל הזה | יום כיפור, יום הזיכרון לשואה ולגבורה, יום הזיכרון לחללי מערכות ישראל | | `sensitive` | רק תוכן מכבד ומאופק | צומות, יום שישי הטוב, עאשורא, יום ערפה, ליילת אל קדר | | `opportunity` | מקום לברכה או לפוסט בנושא היום | עיד אל פיטר, חג המולד, דיוואלי, ראש השנה הסיני, בלאק פריידיי | | `normal` | אין סיבה לשנות את התוכנית | שאר הימים | באפליקציה עצמה הלוח מציג את כל המסורות עם מסנן, וכל יום צבוע לפי ההמלצה שלו. זה נוח לאדם שרוצה להסתכל על חודש שלם. סוכן צריך את אותו מידע בפורמט שהוא יכול לקרוא. ## איך הסוכן מושך את החגים? דרך שרת MCP זה הכלי `get_holidays`, ודרך REST זו אותה פעולה בדיוק, כפי שמתוארת [במפרט OpenAPI](https://app.shager.ai/api/v1/openapi.json): ```bash curl -s "https://app.shager.ai/api/v1/holidays?from=2026-11-01&to=2026-12-31&traditions=jewish,muslim&language=he" \ -H "Authorization: Bearer $SHAGER_API_KEY" ``` כשלא שולחים את `from` ואת `to`, הטווח הוא מהיום ועוד 60 יום, והטווח המקסימלי הוא 400 יום. הפרמטר `traditions` מצמצם את התשובה למסורות שביקשתם, והפרמטר `language` קובע אם שמות החגים יחזרו בעברית או באנגלית. התשובה נראית כך: ```json { "data": { "from": "2026-11-01", "to": "2026-12-31", "note": "...", "holidays": [ { "date": "YYYY-MM-DD", "tradition": "muslim", "name": "...", "key": "...", "advice": "sensitive", "guidance": "...", "approximate": true } ] } } ``` השדה `guidance` הוא משפט הסבר קצר שהסוכן יכול להעביר הלאה לאדם שמאשר. השדה `approximate` מופיע בתאריכים שעוד עשויים לזוז, ועליו בהמשך. ## רצף העבודה: מהחגים ועד פוסט מתוזמן ככה נראה סבב תזמון אחד אצלנו, בסדר הזה: ```text 1. get_holidays { from: "2026-11-01", to: "2026-11-30", traditions: "jewish,muslim,druze", language: "he" } 2. create_post { workspace_id: "ws_north", channel_ids: ["ch_druze_village_fb", "ch_clinic_nazareth_ig"], caption: "...", per_channel: [ { channel_id: "ch_druze_village_fb", caption: "..." }, { channel_id: "ch_clinic_nazareth_ig", caption: "..." } ], media_ids: ["med_7c21"] } 3. schedule_post { workspace_id: "ws_north", post_id: "pst_41b0", schedule_at: "2026-11-17T10:00:00+02:00" } 4. קריאת calendar_notes מהתשובה. אם יש שם יום avoid או sensitive במסורת של אחד החשבונות, cancel_post ותזמון מחדש. ``` הצעד הראשון קורה לפני שהסוכן כותב מילה. הוא מושך את החגים רק של המסורות שמופיעות בפרופילים של החשבונות בסבב, ומסמן ימים אסורים מראש. הצעד השני משתמש בשדה `per_channel`, שמאפשר כיתוב שונה לכל חשבון. זה המקום להוסיף ברכה לחג בחשבון אחד ולהשאיר את השני נקי, כמו שהסברתי במאמר על [התאמת כיתוב לכל חשבון](/blog/caption-variation-per-account-with-ai). הצעד הרביעי הוא רשת ביטחון. כל פוסט שחוזר מהכלים `create_post`, `get_post` וגם `schedule_post` כולל את `calendar_notes`, רשימת החגים שחלים ביום המתוזמן שלו עם ההמלצה לכל אחד. גם אם הסוכן פספס משהו בצעד הראשון, למשל כי מישהו שינה מועד ידנית, הוא רואה את זה כאן. נקודה אחת שקל לפספס: לפוסט אחד יש מועד אחד. אם ביום מסוים חשבון אחד בקבוצה נמצא ביום `avoid` והשאר לא, `per_channel` לא יפתור את זה. צריך לפצל לשני פוסטים, אחד לכל קבוצת קהל, עם מועדים שונים. ## למה זה משנה ש"החג מתחיל בערב"? ביהדות כל יום מתחיל בשקיעה, וחג שמופיע בלוח בתאריך מסוים מתחיל בערב שלפניו. [האתר של התנועה הרפורמית](https://reformjudaism.org/learning/answers-jewish-questions/why-do-jewish-holidays-begin-night) מסביר שזה נובע מסיפור הבריאה, שבו הערב קודם לבוקר. גם היום המוסלמי מתחיל בשקיעה. במחשבון של סוכן זה יוצר באג שקט. הלוח אומר שיום כיפור חל בתאריך מסוים, הסוכן בודק את התאריך של הפוסט, רואה תאריך אחר, ומתזמן פוסט מבצע לשבע בערב של היום הקודם. הפוסט ייצא בדיוק בתוך החג. בימי הזיכרון בישראל העניין חמור יותר כי הוא מעוגן בחוק. לפי [הספרייה היהודית הווירטואלית](https://www.jewishvirtuallibrary.org/yom-hazikaron-israeli-memorial-day), יום הזיכרון לחללי מערכות ישראל מתחיל בשקיעה בערב שלפני, ומקומות בילוי סגורים בו על פי חוק. גם ביום השואה, [מקומות בידור ציבוריים סגורים על פי חוק](https://en.wikipedia.org/wiki/Yom_HaShoah) בערב היום וביום עצמו. מותג שמפרסם באותן שעות פוסט עליז עם קוד הנחה לא עובר על החוק, אבל הקהל שלו יזכור. הכלל שאני כותב בהוראות: ביום `avoid` או `sensitive`, גם אחר הצהריים והערב של היום הקודם נחשבים חלק ממנו. ביום `opportunity` ההפך עובד לטובתכם, כי ברכה שעולה לפני כניסת החג מגיעה בזמן. ## למה תאריכים מוסלמיים מסומנים כמשוערים? שַׁגֵּר מחשב את התאריכים המוסלמיים לפי לוח אום אל קורא, הלוח הרשמי של ערב הסעודית, ומסמן אותם `approximate: true`. הסיבה היא שהלוח מחושב מראש, בעוד שתחילת החודשים הדתיים נקבעת לפי ראיית הירח. [כתבה באתר The New Arab](https://www.newarab.com/news/will-saudi-arabia-announce-wrong-date-ramadan) מצטטת את אתר הלוח עצמו, שכתב שהוא עשוי לא להתאים לנראות בפועל של הסהר. בנוסף, מדינות וקהילות שונות משתמשות בקריטריונים שונים לראייה, ולכן [חג עשוי להתחיל ביום אחר במדינות שונות](https://www.aljazeera.com/news/2023/3/16/infographic-when-is-ramadan-2023). בפועל המשמעות היא יום אחד לכאן או לכאן. מה שהסוכן צריך לעשות עם זה: 1. ביום `sensitive` משוער, להשאיר מרווח של יום לפני ויום אחרי. 2. ביום `opportunity` משוער כמו עיד אל פיטר, להכין את הברכה כטיוטה מראש ולתזמן אותה רק אחרי ההכרזה המקומית, או לנסח אותה כך שתתאים גם ליום שלפני. 3. אם ללקוח יש קהל בכמה מדינות, לא להניח שהתאריך זהה בכולן. ## הנחיה לדוגמה לסוכן זו ההנחיה שאני נותן לסוכן לפני סבב חודשי. היא נכנסת לקובץ ההוראות שלו, יחד עם הכללים מ[אסטרטגיית התזמון לסוכנים](/blog/scheduling-strategy-for-agents): ```text לפני שאתה מתזמן פוסט כלשהו החודש: 1. קרא את פרופיל הקהל של כל לקוח ורשום אילו מסורות רלוונטיות לו. 2. הפעל את get_holidays לטווח של כל החודש, עם המסורות האלה בלבד, language=he. 3. ימים עם advice=avoid: אין פוסט שיווקי לחשבונות של הקהל הזה, כולל אחר הצהריים והערב של היום הקודם. 4. ימים עם advice=sensitive: רק תוכן מכבד, בלי מבצעים, בלי הומור. 5. ימים עם advice=opportunity: הצע ברכה או פוסט בנושא, בכיתוב נפרד לכל חשבון בתוך השדה per_channel. 6. אם approximate=true, השאר יום מרווח או המתן להכרזה. 7. אחרי schedule_post, קרא את calendar_notes. אם יש התנגשות, בטל ותזמן מחדש, ודווח לי מה שינית ולמה. ``` ## רשימת בדיקה לפני כל תזמון 1. לכל חשבון יש פרופיל קהל עם רשימת מסורות, ולקוח בלי רשימה לא מתוזמן עד שמישהו ממלא אותה. 2. החגים נמשכים פעם אחת לכל הסבב, לטווח שמכסה את כל המועדים. 3. יום `avoid` חוסם גם את הערב שלפניו. 4. יום `sensitive` מקבל טון אחר, לא רק מועד אחר. 5. ימי `opportunity` נכתבים בנפרד לכל קהל, ולא כברכה כללית אחת לכולם. 6. תאריכים משוערים מקבלים מרווח של יום. 7. כשקהלים באותה קבוצה חלוקים על יום מסוים, הפוסט מתפצל לשניים. 8. אחרי כל תזמון הסוכן קורא את `calendar_notes` ומדווח על כל שינוי. שבת, אגב, היא כלל קבוע ולא אירוע בלוח. ללקוח שהקהל שלו שומר שבת כדאי לכתוב את זה בפרופיל כחלון זמן אסור, בנפרד מהחגים. אם הסוכן שלכם עוד לא מחובר, [עמוד הסוכנים](/agents) מסביר איך מתחילים. אחרי החיבור, הצעד הראשון שווה עשר דקות: לכתוב לכל לקוח את שורת המסורות בפרופיל ולהריץ `get_holidays` על החודשיים הקרובים. ## שאלות נפוצות ### האם שַׁגֵּר חוסם תזמון ביום שמסומן avoid? ההמלצה היא מידע, לא חסימה. שַׁגֵּר מחזיר אותה בתשובה של `get_holidays` ובשדה `calendar_notes` של כל פוסט, וההחלטה נשארת אצל הסוכן ואצל מי שמאשר. זה מכוון, כי אותו יום יכול להיות אסור לקהל אחד ורגיל לגמרי לקהל אחר. ### איך הסוכן יודע לאיזו מסורת שייך כל חשבון? הוא לא יודע לבד, ולא כדאי שינחש לפי שם העסק או לפי העיר. כתבו לכל לקוח בפרופיל הקהל את רשימת המסורות במפורש, ותנו לסוכן לקרוא אותה לפני כל סבב. כשהרשימה חסרה, ההוראה הנכונה היא לעצור ולשאול. ### מה עושים עם מותג בינלאומי שהקהל שלו מגוון? מותג כזה צריך בעיקר את הימים הבינלאומיים והמסחריים, ובנוסף את המסורות של השווקים הגדולים שלו. כדאי לפצל את החשבונות שלו לקבוצות לפי שוק, ולבדוק כל קבוצה מול המסורות שלה. ככה ברכה לחג המולד לא תצא לחשבון שפונה לקהל שחוגג באותו שבוע משהו אחר לגמרי. --- Source: https://shager.ai/blog/holiday-aware-posting-for-agents # מבריף ללקוח עד פוסט באוויר: מקרה עבודה מלא של סוכן AI עם שַׁגֵּר _2026-10-12 · מקרה עבודה מלא, צעד אחרי צעד: בריף של לקוח, טיוטות לכל חשבון, אישור לקוח בקישור, תזמון מדורג, בדיקת פרסום ולחיצות לכל חשבון, עם קריאות MCP אמיתיות לאורך הדרך._ הדרך מבריף לפוסט מפורסם בעשרות חשבונות, כשסוכן AI עושה את העבודה דרך שַׁגֵּר, היא שמונה שלבים: קריאת הבריף, בדיקת החשבונות, העלאת מדיה, טיוטה עם כיתוב לכל חשבון, בדיקה פנימית, אישור לקוח בקישור, תזמון, ובדיקה אחרי הפרסום. הסוכן מבצע את כולם. אדם עוצר אותו בשתי נקודות: לפני שהטיוטה הולכת ללקוח, ולפני התזמון. המאמר עוקב אחרי מקרה אחד מההתחלה ועד הסוף. הלקוח בדוי, אבל הקריאות, השדות והתשובות הן של שַׁגֵּר כפי שהוא עובד היום. ## הבריף רשת חנויות לציוד ספורט, "ריצה", עם שמונה סניפים. לכל סניף עמוד פייסבוק, ולמותג יש חשבון אינסטגרם וערוץ יוטיוב. הבריף מגיע במייל ביום ראשון: ```text השקה של נעל ריצה חדשה ביום חמישי הקרוב. סרטון קצר (30 שניות, אנכי) ותמונה של הנעל. מבצע: מדידה בחנות עם ייעוץ ריצה חינם, ביום חמישי ושישי. דף נחיתה להרשמה למדידה: https://example.co.il/fitting חשוב: לא לכתוב מחיר. הלקוח רוצה לאשר כל פוסט. ``` הסוכנות מעבירה את הבריף לסוכן, שעובד בתוך Claude Code ומחובר לְשַׁגֵּר. [המדריך לחיבור Claude Code](/blog/connect-shager-to-claude-code) מסביר את ההגדרה. ## שלב 1: הסוכן בודק עם מי הוא מדבר ```json whoami {} list_workspaces {} ``` `whoami` מחזיר את הארגון, אם זה סנדבוקס, ואת ההרשאות. במקרה שלנו המפתח הוא של הסוכנות, עם `read`, `write` ו`publish`. `list_workspaces` מחזיר את סביבות העבודה, והסוכן מוצא את "ריצה". אם סביבת העבודה לא הייתה קיימת, הוא היה עוצר ושואל, ולא יוצר אחת חדשה על דעת עצמו. ## שלב 2: אילו חשבונות פעילים? ```json list_channels { "workspace_id": "ws_ritza" } list_groups { "workspace_id": "ws_ritza" } ``` התשובה מראה עשרה ערוצים: שמונה עמודי פייסבוק, אינסטגרם ויוטיוב. אחד מעמודי הפייסבוק, סניף אשדוד, במצב שדורש חיבור מחדש. יש קבוצה בשם "כל הסניפים". כאן הסוכן לא ממשיך כאילו כלום. הוא מדווח: "עמוד אשדוד דורש חיבור מחדש. אפשר ליצור קישור חיבור לשלוח ללקוח". אחרי אישור: ```json create_connect_link { "workspace_id": "ws_ritza", "label": "חיבור מחדש, סניף אשדוד" } ``` הלקוח מקבל קישור, נכנס לפייסבוק ובוחר את העמוד, בלי חשבון בְּשַׁגֵּר ובלי למסור סיסמה. על התהליך הזה יש [מאמר נפרד על קישורי חיבור](/blog/client-connect-links). ## שלב 3: העלאת מדיה ```json upload_media_from_url { "workspace_id": "ws_ritza", "url": "https://cdn.example.co.il/ritza/launch-30s.mp4", "file_name": "launch-30s.mp4", "width": 1080, "height": 1920, "duration_ms": 30000 } upload_media_from_url { "workspace_id": "ws_ritza", "url": "https://cdn.example.co.il/ritza/shoe-hero.jpg", "file_name": "shoe-hero.jpg" } ``` לסרטון הסוכן מעביר מידות ואורך, כדי שֶׁשַּׁגֵּר יוכל לבדוק התאמה לרילס ולשורטס לפני הפרסום. פירוט נוסף יש במדריך להפצת וידאו קצר עם סוכן. ## שלב 4: טיוטה עם כיתוב לכל חשבון הסוכן מחליט על שני פוסטים: הסרטון כרילס בפייסבוק ובאינסטגרם וכשורט ביוטיוב, והתמונה כפוסט רגיל בעמודי הסניפים יום אחרי. נתמקד בראשון. ```json create_post { "workspace_id": "ws_ritza", "label": "השקת נעל, סרטון", "campaign": "shoe-launch-oct", "caption": "הנעל החדשה מגיעה ביום חמישי. מדידה וייעוץ ריצה בחנות, בלי עלות.", "media_ids": ["med_vid_launch"], "format": "REEL", "youtube_title": "נעל הריצה החדשה: 30 שניות לפני ההשקה", "youtube_privacy": "public", "per_channel": [ { "channel_id": "ch_fb_telaviv", "caption": "רצי תל אביב, ביום חמישי הנעל החדשה מגיעה לחנות בדיזנגוף. בואו למדידה עם ייעוץ ריצה.", "first_comment": "לשריון מדידה בסניף תל אביב:\nhttps://example.co.il/fitting" }, { "channel_id": "ch_fb_haifa", "caption": "חיפה, מי שרץ בכרמל יודע מה נעל טובה עושה בעליות. מדידה בחנות בחמישי ושישי.", "first_comment": "הרשמה למדידה:\nhttps://example.co.il/fitting" }, { "channel_id": "ch_ig_brand", "caption": "30 שניות על הנעל החדשה. מדידה וייעוץ בחנויות בחמישי ושישי, הקישור בביו." }, { "channel_id": "ch_yt_brand", "format": "SHORT", "caption": "הצצה לנעל הריצה החדשה לפני ההשקה ביום חמישי.\nהרשמה למדידה: https://example.co.il/fitting" } ] } ``` בפועל `per_channel` כולל את כל הערוצים הפעילים. קיצרתי לארבעה. בלי `schedule_at` הפוסט נשמר כטיוטה. כל קישור בכיתוב ובתגובה יוחלף בזמן הפרסום בקישור מקוצר ייחודי לחשבון, עם `utm_content` שמזהה אותו, כמו שמוסבר ב[מאמר על קישור הליד בתגובה הראשונה](/blog/first-comment-lead-links-with-agents). ## שלב 5: בדיקה פנימית הסוכן מציג טבלה של חשבון, פורמט, כיתוב ותגובה, ומריץ על עצמו את רשימת הבדיקה מתוך ההוראות: אין מחיר (הבריף אסר), אין שני כיתובים זהים, אין קישור באינסטגרם, שם העיר נכון בכל עמוד. מנהלת התוכן בסוכנות קוראת, מתקנת ניסוח אחד בעמוד באר שבע, והסוכן יוצר טיוטה מתוקנת. זו נקודת העצירה הראשונה. ## שלב 6: אישור לקוח בקישור ```json request_approval { "workspace_id": "ws_ritza", "post_id": "pst_launch_v2", "reviewer_name": "מיכל, מנהלת שיווק", "reviewer_email": "michal@example.co.il", "send_email": true } ``` הקריאה מחזירה קישור אישור, ועם `send_email` גם שולחת אותו במייל. הלקוחה פותחת את הקישור, רואה את הפוסט לכל חשבון, ומאשרת או מבקשת שינויים, בלי להתחבר לְשַׁגֵּר. סביבת העבודה של "ריצה" מוגדרת עם `approval_required`, ולכן בלי האישור שלה `schedule_post` ייכשל. על שכבת האישור ולמה היא שווה את הזמן, ראו [מאמר על אישור אנושי לפוסטים של סוכנים](/blog/human-approval-for-agent-posts). ## שלב 7: תזמון הלקוחה אישרה ביום שלישי. ההשקה ביום חמישי בבוקר, והסוכן מחשב: עשרה ערוצים, רובם פייסבוק, עם פריסה מדורגת בברירת המחדל של `[30, 90]` שניות בין עמודים. שמונה עמודי פייסבוק יתפרסו על פני כעשר דקות. הוא מציע שמונה בבוקר, מנהלת התוכן מאשרת, וזו נקודת העצירה השנייה. ```json schedule_post { "workspace_id": "ws_ritza", "post_id": "pst_launch_v2", "schedule_at": "2026-09-10T08:00:00+03:00" } ``` ההיסט `+03:00` נכון כי התאריך לפני סוף שעון הקיץ. פוסט אחרי 25 באוקטובר היה מקבל `+02:00`, כמו שמוסבר במאמר על אסטרטגיית התזמון לסוכנים. ## שלב 8: אחרי הפרסום ביום חמישי בשמונה ורבע הסוכן מריץ `get_post`. תשעה ערוצים פורסמו עם קישור חי. סניף אשדוד, שחובר מחדש, פורסם גם הוא. ערוץ אחד במצב שגיאה? במקרה שלנו לא, אבל אם היה, הסוכן היה מדווח את ההודעה כלשונה ולא מנסה לפרסם מחדש. ביום ראשון שאחרי: ```json get_analytics { "workspace_id": "ws_ritza", "from": "2026-09-10T00:00:00+03:00", "to": "2026-09-13T23:59:59+03:00" } ``` התשובה מפרקת לחיצות לפי חשבון ולפי פוסט. הסוכן מכניס אותה לתבנית הדוח השבועי, ומשווה לנרשמים למדידה שהלקוחה מייצאת מהמערכת שלה לפי `utm_content`. התבנית המלאה נמצאת ב[מאמר על דוח לקוח שבועי בידי סוכן](/blog/weekly-client-report-by-agent). ## מה עשה הסוכן ומה עשו אנשים | שלב | מי | |---|---| | קריאת בריף, בדיקת חשבונות, העלאה, טיוטות | סוכן | | קריאת טיוטה ותיקון ניסוח | מנהלת התוכן | | שליחה לאישור | סוכן, אחרי אישור פנימי | | אישור הפוסט | הלקוחה, בקישור | | בחירת מועד | סוכן מציע, אדם מאשר | | בדיקת פרסום ודוח | סוכן | הזמן האנושי בכל התהליך היה קריאה של טבלה, תיקון אחד, ואישור מועד. כל השאר, כולל הדברים המייגעים כמו עשרה כיתובים שונים וקישור מסומן לכל עמוד, נעשה בידי הסוכן. אם אתם רוצים לנסות את התהליך הזה, הסוכן יכול להתחיל לבד: הרשמה עצמית לפי [auth.md](/auth.md) נותנת סנדבוקס שבו אפשר להעלות מדיה וליצור טיוטות, ואדם בסוכנות תובע אותו כשמגיע הזמן לחבר חשבונות ולפרסם. ## שאלות נפוצות ### כמה זמן לוקח לסוכן להכין טיוטה לעשרה חשבונות? זה תלוי בכלי ובמודל, ואין לי מדידה שאני יכול להציג. בפועל, החלק האיטי בתהליך הוא כמעט תמיד הבדיקה האנושית והאישור של הלקוח, לא הכתיבה. ### מה קורה אם הלקוח מבקש שינויים בקישור האישור? הפוסט חוזר עם ההערות, והסוכן יוצר טיוטה מתוקנת ושולח אותה שוב ב`request_approval`. אפשר לראות את מצב הפוסטים עם `list_posts` ולסנן לפי `CHANGES_REQUESTED`. ### האם אפשר לדלג על אישור הלקוח? כן, אם סביבת העבודה לא מוגדרת עם `approval_required`. ההחלטה היא של הסוכנות מול הלקוח. אני ממליץ להתחיל עם אישור, ולהוריד אותו רק אחרי שהלקוח ראה כמה שבועות של עבודה בלי הפתעות. --- Source: https://shager.ai/blog/from-brief-to-published # שיווק מותג מול שיווק לידים: איך סוכנות בונה את שניהם יחד _2026-10-11 · למה סוכנות לידים צריכה גם תוכן מותג, איך מחלקים את לוח התוכן בין השניים, איך מודדים כל אחד מהם ואיך מסבירים ללקוח למה זה משתלם._ רוב הלקוחות של סוכנויות לידים באים עם בקשה אחת: עוד פניות, במחיר נמוך יותר. זו בקשה הוגנת, וזה גם מה שהם משלמים עליו. אבל סוכנות שעונה עליה רק בפוסטים של "השאירו פרטים" מגלה אחרי כמה חודשים שהתוצאות נשחקות: הקהל כבר ראה את ההצעה, העלות לליד עולה, והעמודים נראים כמו לוח מודעות. המאמר הזה עוסק בשאלה איך משלבים תוכן מותג בתוך עבודת לידים, בלי לאבד את הפוקוס על התוצאה שהלקוח מודד. ## שני תפקידים שונים לאותו פיד **שיווק לידים** פונה למי שכבר מוכן/ה לפעול עכשיו. המסר ישיר, יש הצעה, יש קריאה לפעולה, והמדד הוא פניות. **שיווק מותג** פונה לכל השאר: מי שעוד לא צריך את השירות, מי שצריך אבל לא מכיר אתכם, ומי שמכיר אבל עוד לא סומך. המסר רחב יותר, והמטרה היא שכשיגיע הרגע, השם הראשון שיעלה יהיה של הלקוח שלכם. הבעיה היא שבכל רגע נתון רק חלק קטן מהקהל נמצא במצב של "מוכן/ה לפעול". סוכנות שמדברת רק אליו מתחרה כל הזמן על אותה קבוצה קטנה, ונאלצת לשלם עליה יותר ויותר. ## למה פוסטים של לידים לבד נשחקים כמה דפוסים שחוזרים אצל סוכנויות שעובדות רק על פוסטים ישירים: 1. **עייפות הצעה**: אותו מבצע, באותו ניסוח, שבוע אחרי שבוע. הקהל מפסיק לראות אותו. 2. **אמון נמוך**: עמוד שכל הפוסטים בו הם בקשה למשהו לא נותן סיבה לסמוך עליו. 3. **לידים קרים יותר**: מי שמשאיר/ה פרטים בלי להכיר את העסק נוטה לענות פחות לשיחת המכירה. 4. **תלות מלאה בתקציב ממומן**: בלי קהל אורגני שמכיר את המותג, כל ליד צריך להיקנות. אין כאן נתון אחד שמתאים לכל תחום, וכדאי לבדוק את זה אצל הלקוחות שלכם. אבל אם אתם רואים את הדפוסים האלה, סביר שחסר רכיב מותג. ## איך נראה תוכן מותג אצל סוכנות לידים תוכן מותג לא חייב להיות סרטון תדמית יקר. בעבודה עם עסקים מקומיים ושירותים, הוא בדרך כלל פשוט יותר: 1. **הצגת אנשים**: מי עונה לטלפון, מי מגיע/ה לבית, מי מטפל/ת בתיק 2. **מאחורי הקלעים**: איך נראה יום עבודה, איך מתבצע השירות 3. **ידע מקצועי**: טיפ, טעות נפוצה, תשובה לשאלה שלקוחות שואלים כל הזמן 4. **הוכחות אמיתיות**: פרויקט שהושלם, לפני ואחרי, עם אישור הלקוח הקצה 5. **נוכחות מקומית**: אירוע בעיר, שיתוף פעולה עם עסק שכן המשותף לכל אלה הוא שהם לא מבקשים כלום. הם נותנים לקהל סיבה לזכור ולסמוך. ## חלוקת לוח התוכן אין יחס אחד נכון, והוא תלוי בתחום, במחזור המכירה ובמידת ההיכרות של הקהל עם המותג. נקודת פתיחה סבירה לבדיקה: | סוג תוכן | תפקיד | דוגמה | |---|---|---| | מותג | היכרות ואמון | הכירו את הצוות של הסניף | | ערך | ידע שימושי | שלוש שאלות לשאול לפני שבוחרים ספק | | הוכחה | אמינות | פרויקט שהסתיים החודש | | לידים | פעולה | מבצע עם קישור להשארת פרטים | התחילו עם חלוקה שבה חלק משמעותי מהפוסטים אינו פוסט מכירה, ושנו לפי התוצאות. מה שחשוב הוא שהחלוקה תהיה מתוכננת ולא תוצאה של "לא היה מה לפרסם השבוע". ### בהיקף של עשרות חשבונות כשמפרסמים לסניפים רבים, תוכן מותג הוא גם הדרך הטבעית ביותר לגוון. פוסט לידים של קמפיין ארצי יהיה דומה בכל הסניפים, אבל פוסט שמציג את הצוות של סניף מסוים הוא מקורי מעצם הגדרתו. זה עוזר גם לקהל וגם להפצה. ## איך מודדים כל אחד מהם הטעות הנפוצה היא למדוד תוכן מותג לפי לידים ישירים, ולהסיק שהוא "לא עובד". ### מדדים לתוכן לידים 1. לחיצות על הקישור, לכל חשבון 2. לידים שנכנסו למערכת CRM עם שיוך לחשבון ולקמפיין 3. עלות לליד ואיכות הליד לפי משוב מהמכירות ### מדדים לתוכן מותג 1. טווח הגעה ומעורבות לאורך זמן, לא לפוסט בודד 2. צמיחה בעוקבים ובצפיות חוזרות 3. חיפושים לפי שם המותג, אם יש לכם גישה לנתונים האלה 4. שינוי בשיעור ההמרה של פוסטי הלידים לאורך חודשים המדד האחרון הוא הקשר בין השניים: אם אחרי כמה חודשים של תוכן מותג פוסטי הלידים באותם חשבונות ממירים טוב יותר, זה הסימן שהשילוב עובד. ## איך מציגים את זה ללקוח לקוח שמשלם על לידים יחשוד בצדק בכל פוסט שלא מביא פניות. כמה דרכים לבנות אמון בגישה: 1. **הציגו את זה כחלק מהאסטרטגיה מההתחלה**, לא כתירוץ כשהלידים יורדים 2. **התחייבו לאותו יעד לידים**, ותסבירו שתוכן המותג נועד להחזיק אותו לאורך זמן 3. **דווחו על שני המסלולים בנפרד**, כדי שהלקוח יראה מה כל אחד תורם 4. **הריצו בדיקה**: קבוצת חשבונות אחת עם שילוב, אחת בלי, והשוו אחרי תקופה סבירה ## צ'קליסט לבניית לוח שמשלב מותג ולידים 1. הוגדרה חלוקה מתוכננת בין סוגי התוכן לכל לקוח 2. יש מאגר של רעיונות מותג לכל חשבון או סניף 3. תוכן המותג כולל פרטים מקומיים ואנשים אמיתיים 4. כל פוסט לידים מסומן עם UTM וקישור לכל חשבון 5. תוכן מותג נמדד במדדים משלו, לאורך זמן 6. הלקוח יודע מראש למה יש פוסטים שלא מבקשים פרטים 7. יש תוכנית לבדוק אם השילוב משפר את ההמרה ## לסיכום שיווק מותג ושיווק לידים הם לא שתי אסטרטגיות מתחרות. הם שני חלקים של אותו מנגנון: אחד בונה את הקהל ואת האמון, והשני הופך אותם לפניות. סוכנות שמחזיקה את שניהם יחד בונה ללקוחות שלה תוצאות שלא נשחקות אחרי רבעון, ובונה לעצמה לקוחות שנשארים. שַׁגֵּר עוזר להחזיק את שני המסלולים באותו לוח: קבוצות חשבונות שמאפשרות לתכנן תוכן מותג מקומי לצד קמפיינים ארציים, תגיות UTM וקישורים מקוצרים שמודדים את הלידים מכל חשבון, ועוזר כתיבה בעברית שעוזר לייצר את שני סוגי התוכן בקול של כל לקוח. --- Source: https://shager.ai/blog/b2b-brand-marketing-lead-generation # קישור הליד בתגובה הראשונה: איך סוכן בונה פוסט שמודד פניות מכל חשבון _2026-10-09 · איך סוכן AI מציב את קישור הליד בתגובה הראשונה בְּשַׁגֵּר: קישור מקוצר ותגיות UTM לכל חשבון, התנהגות שונה בכל רשת, ניסוח אחר לכל עמוד ובדיקת הלחיצות אחרי הפרסום._ כשסוכן כותב פוסט לעשרות חשבונות דרך שַׁגֵּר, הוא שם את קישור הליד בשדה `first_comment` או בשדה `cta_url`, וְשַׁגֵּר דואג לשאר: כל כתובת בכיתוב ובתגובה הראשונה מוחלפת, לכל חשבון בנפרד, בקישור מקוצר משלו עם תגיות UTM, והתגובה יוצאת מיד אחרי הפוסט. הסוכן לא בונה UTM ולא מקצר קישורים. הוא צריך רק לבחור איפה הקישור יושב ולנסח אותו אחרת בכל עמוד. את הרקע, למה קישור לכל חשבון ולמה תגובה ראשונה, כתבתי ב[מאמר על שיוך לידים לכל חשבון](/blog/utm-per-account-lead-attribution). כאן הפוקוס הוא על מה שהסוכן עושה בפועל. ## מה קורה לקישור בדרך מהסוכן לרשת? נניח שהסוכן שולח פוסט לשלושים עמודי פייסבוק עם הכתובת `https://example.co.il/consult` בתגובה הראשונה. בזמן הפרסום, לכל אחד מהשלושים, שַׁגֵּר: 1. מוצא את הכתובות בכיתוב ובתגובה הראשונה של אותו חשבון. 2. יוצר לכל כתובת קישור מקוצר ייחודי לחשבון ולפוסט. 3. מוסיף ליעד תגיות UTM: `utm_source` לפי הרשת, `utm_medium` של `social` לפוסט רגיל או `video` לווידאו, `utm_campaign` מהשדה `campaign` של הפוסט, ו`utm_content` שמזהה את החשבון. 4. מחליף את הכתובת בטקסט בקישור המקוצר. 5. מפרסם את הפוסט, ומיד אחריו את התגובה. הסוכן כותב כתובת אחת. שלושים עמודים מקבלים שלושים קישורים שונים. ב`get_analytics` רואים את הלחיצות לכל חשבון, ובכלי האנליטיקס או במערכת CRM של הלקוח אפשר לפצל לפי `utm_content`. ## first_comment מול cta_url: מה ההבדל? `first_comment` הוא טקסט חופשי שמתפרסם כתגובה הראשונה. הסוכן מחליט על הניסוח ועל מיקום הקישור בתוכו. אפשר להגדיר אותו לכל הפוסט, או לכל חשבון בנפרד בתוך `per_channel`, ואז התגובה של החשבון גוברת על זו הכללית. `cta_url` הוא הקישור המרכזי של הפוסט, ואפשר להוסיף לו `cta_text`. אם הסוכן לא שם את הכתובת הזו בעצמו בכיתוב או בתגובה, שַׁגֵּר מציב אותה: ברשתות שבהן קישור בכיתוב עובד הוא מתווסף לסוף הכיתוב, ובאחרות הוא עובר לתגובה הראשונה אם לא הוגדרה תגובה. בשני המקרים הוא עובר את אותו תהליך של קיצור ותגיות. ההמלצה שלי לסוכנים: כשרוצים שליטה על הניסוח, `first_comment` לכל חשבון. כשרוצים פשטות, `cta_url` עם `cta_text`, וְשַׁגֵּר יציב את הקישור לפי הרשת. ## איך זה מתנהג בכל רשת? | רשת | תגובה ראשונה | קישור לחיץ | |---|---|---| | עמוד פייסבוק | נתמכת | בכיתוב ובתגובה | | ערוץ יוטיוב | בסרטונים ציבוריים בלבד | בתיאור ובתגובה | | אינסטגרם מקצועי | נתמכת | לא בכיתוב ולא בתגובה | השורה של אינסטגרם היא זו שסוכנים מפספסים. קישור בכיתוב או בתגובה באינסטגרם לא לחיץ, ולכן אין טעם לשים אותו שם. בחשבונות אינסטגרם הסוכן צריך לכתוב "הקישור בביו" או להפנות לסטורי, ולהשאיר את `first_comment` לשאלה או למידע נוסף. ביוטיוב, אם הסרטון מתפרסם כ`unlisted` או `private`, לא תצא תגובה ראשונה. ## הפוסט המלא כך נראה פוסט של משרד רואי חשבון עם שישה סניפים, שלושה עמודי פייסבוק וחשבון אינסטגרם בדוגמה: ```json create_post { "workspace_id": "ws_cpa_firm", "label": "סוף שנת מס, שיחת ייעוץ", "campaign": "year-end-tax-2026", "caption": "שלושה חודשים לסוף שנת המס. זה הזמן לבדוק אם יש החזר שמגיע לכם.", "media_ids": ["med_a81c"], "per_channel": [ { "channel_id": "ch_fb_petahtikva", "caption": "עצמאים בפתח תקווה, נשארו שלושה חודשים לסוף שנת המס. בואו נבדוק יחד מה עוד אפשר לעשות.", "first_comment": "לקביעת שיחת ייעוץ בסניף פתח תקווה:\nhttps://example.co.il/consult" }, { "channel_id": "ch_fb_holon", "caption": "שכירים עם הכנסה נוספת? בסניף חולון בודקים החזרי מס עד סוף השנה.", "first_comment": "השאירו פרטים ונחזור אליכם השבוע:\nhttps://example.co.il/consult" }, { "channel_id": "ch_fb_rishon", "caption": "בראשון לציון כבר מתכוננים לסוף השנה. שיחה של חצי שעה יכולה לחסוך הרבה.", "first_comment": "לתיאום שיחה:\nhttps://example.co.il/consult" }, { "channel_id": "ch_ig_brand", "caption": "סוף שנת המס מתקרב. שיחת ייעוץ קצרה, הקישור בביו.", "first_comment": "איזו שאלה על החזרי מס הייתם רוצים שנענה בפוסט הבא?" } ], "stagger_seconds": [30, 90] } ``` שימו לב לשלושה דברים. הקישור בכל תגובה נמצא בשורה נפרדת, מה שמונע בעיות כיווניות בעברית. הניסוח של התגובה שונה בכל עמוד, כי תגובה זהה מילה במילה בשלושים עמודים נראית בדיוק כמו מה שהיא. ובאינסטגרם אין קישור בכלל. על הכללים האלה בהיקף רחב יותר יש [מאמר על כללי בטיחות לסוכנים](/blog/safety-rules-for-agents-posting-at-scale). אותו פוסט בממשק REST, לפי [מפרט OpenAPI](https://app.shager.ai/api/v1/openapi.json): ```bash curl -X POST "https://app.shager.ai/api/v1/workspaces/ws_cpa_firm/posts" \ -H "Authorization: Bearer $SHAGER_API_KEY" \ -H "Content-Type: application/json" \ -d @year-end-post.json ``` ## פרומפט שמייצר את זה ```text סביבת עבודה: "רואי חשבון כהן ושות'". קבוצה: "סניפים". דף נחיתה: https://example.co.il/consult campaign: year-end-tax-2026 1. הרץ list_channels ו list_groups, וזהה לכל חשבון את הרשת ואת העיר. 2. כתוב כיתוב שונה לכל חשבון, 1 עד 2 משפטים, עם העיר. 3. בעמודי פייסבוק: first_comment עם משפט הנעה לפעולה שונה בכל עמוד, ואחריו הקישור בשורה נפרדת. 4. באינסטגרם: אין קישור. "הקישור בביו" בכיתוב, ובתגובה הראשונה שאלה לקהל. 5. אל תכתוב בתגובה מחיר, הנחה או הבטחה שלא הופיעו כאן. 6. צור טיוטה והצג טבלה: חשבון, רשת, כיתוב, תגובה ראשונה. אל תתזמן. ``` ## לבדוק אחרי הפרסום אחרי שהפוסט התפרסם, `get_post` מראה לכל חשבון את המצב ואת הקישור החי. אם הפוסט עלה והתגובה לא, הפוסט נשאר מפורסם: כישלון בתגובה נרשם, אבל לא מכשיל את הפוסט. הסוכן צריך לדווח על זה, כי פוסט בלי הקישור הוא פוסט שלא יביא פניות. כמה ימים אחר כך, `get_analytics` עם `from` ו`to` מחזיר לחיצות לכל חשבון ולכל פוסט. כשמשווים את זה ללידים במערכת של הלקוח לפי `utm_content`, רואים אילו סניפים מביאים פניות ואילו רק לחיצות. איך הופכים את זה לדוח קבוע מוסבר ב[מאמר על דוח לקוח שבועי בידי סוכן](/blog/weekly-client-report-by-agent). ## טעויות נפוצות של סוכנים בתגובה הראשונה 1. **אותה תגובה בכל העמודים.** זה הדבר הראשון שבולט, גם לגולשים וגם לרשתות. 2. **קישור באמצע משפט עברי.** בכיווניות של טקסט מעורב הוא עלול להיראות שבור. 3. **קישור באינסטגרם.** לא לחיץ, ונראה רשלני. 4. **כתובת שונה בכל עמוד שהסוכן "שיפר".** אם הסוכן הוסיף פרמטרים משלו או שינה את הנתיב, הקישורים יובילו לעמודים שונים והדוח יתפצל. ההוראה: הכתובת מועתקת כמו שהיא. 5. **UTM שהסוכן הוסיף בעצמו.** שַׁגֵּר מוסיף את התגיות. סוכן שמוסיף גם הוא יוצר כפילות. אם עוד לא חיברתם סוכן לְשַׁגֵּר, התחילו ב[עמוד הסוכנים](/agents). הפוסט הראשון שלכם עם תגובה ראשונה יכול להיות טיוטה בסנדבוקס עוד לפני שמישהו בסוכנות נכנס למערכת. ## שאלות נפוצות ### מה קורה לתגיות UTM שכבר קיימות בכתובת? שַׁגֵּר מוסיף את התגיות לכתובת היעד של הקישור המקוצר. כדי למנוע כפילויות ובלבול בדוחות, הכי פשוט לתת לסוכן כתובת נקייה בלי UTM, ולהגדיר את שם הקמפיין בשדה `campaign`. ### מה קורה אם אין לפוסט קישור בכלל? אז אין קישורים מקוצרים ואין לחיצות למדוד. הפוסט מתפרסם רגיל. זה לגיטימי לפוסטים של מותג, אבל בפוסט שמטרתו לידים כדאי שההוראות של הסוכן יחייבו קישור. ### האם התגובה הראשונה יוצאת בזמן שונה בכל חשבון? כן, כי הפוסט עצמו יוצא בזמן מדורג לכל חשבון לפי `stagger_seconds`, והתגובה יוצאת מיד אחרי הפוסט של אותו חשבון. --- Source: https://shager.ai/blog/first-comment-lead-links-with-agents # לפרסם בהיקף בלי להיחסם: קצב, גיוון ותוכן מקורי לכל רשת _2026-10-07 · איך סוכנות מפרסמת בעשרות חשבונות בלי להיתקל בחסימות: עבודה דרך API רשמי, קצב פרסום מדורג, תוכן מקורי לכל חשבון וכללים שהרשתות מפרסמות._ מי שמנהל/ת עשרות חשבונות מכיר/ה את התרחיש: קמפיין יוצא לכל העמודים, ואחרי כמה שעות מגיעה הודעה על הגבלה, פוסטים שנעלמו מהפיד או חשבון שמבקש אימות. לרוב התגובה הראשונה היא לחפש "טריק" שיעקוף את המערכת. זו בדיוק הגישה שמובילה לחסימה הבאה. הרשתות לא נלחמות בסוכנויות. הן נלחמות בספאם, בפעילות לא אותנטית ובתוכן משוכפל, ומי שמפרסם בהיקף נראה לפעמים דומה מבחוץ. המטרה של המאמר הזה היא לעזור לכם להיראות, ולהיות, מה שאתם באמת: עסק שמפרסם תוכן לגיטימי בשם לקוחות אמיתיים. ## מה הרשתות מגדירות כספאם לפני שמדברים על קצב ועל כלים, כדאי לקרוא את הכללים עצמם. Meta מפרטת ב[סטנדרטים הקהילתיים בנושא ספאם](https://transparency.meta.com/policies/community-standards/spam/) התנהגויות שהיא מגבילה, ויוטיוב מפרטת ב[מדיניות הספאם וההטעיה שלה](https://support.google.com/youtube/answer/2801973) מה נחשב תוכן ספאמי או מטעה. המסמכים משתנים מעת לעת, ולכן שווה לחזור אליהם לפני קמפיין גדול. החוט המשותף ברוב הכללים האלה: 1. **תוכן זהה או כמעט זהה שמופץ שוב ושוב**, בחשבונות רבים או באותו חשבון 2. **הנעה מלאכותית למעורבות**: לייקים, תגובות או שיתופים שלא נוצרו מעניין אמיתי 3. **הטעיה לגבי היעד**: קישורים שמובילים למקום אחר ממה שהפוסט מבטיח 4. **שימוש באוטומציה שלא דרך הממשקים המותרים** שימו לב שאף אחד מהסעיפים האלה לא אוסר על סוכנות לנהל הרבה חשבונות. הם אוסרים על התנהגות מסוימת. ## עיקרון ראשון: רק ממשקים רשמיים הצעד הכי משמעותי להפחתת סיכון הוא לפרסם רק דרך ממשק API רשמי של כל רשת, עם הרשאות שבעל/ת החשבון נתן/ה במפורש. ### למה זה חשוב 1. **הרשת יודעת מי מפרסם.** פוסט שיוצא דרך אפליקציה רשומה ומאושרת מזוהה ככזה. פוסט שיוצא מדפדפן אוטומטי, מכתובת IP משותפת, עם התחברות מעשרות חשבונות, נראה בדיוק כמו פעילות של בוטים. 2. **אין שיתוף סיסמאות.** הלקוח מאשר גישה, יכול לבטל אותה בכל רגע, ולא צריך למסור סיסמה לאף אחד. 3. **המגבלות שקופות.** לממשקים רשמיים יש מגבלות קצב ומכסות מתועדות. למשל, Meta מפרטת ב[מדריך הפרסום של אינסטגרם](https://developers.facebook.com/docs/instagram-platform/content-publishing) את מגבלת הפרסומים דרך ממשק API לכל חשבון בחלון של 24 שעות, ויוטיוב מפרטת את [עלות כל פעולה במכסה היומית](https://developers.google.com/youtube/v3/determine_quota_cost). כלים שמבטיחים "פרסום בלי הגבלה" או עובדים דרך הדמיה של משתמש בדפדפן חוסכים אולי זמן בטווח הקצר, אבל מעמידים את החשבונות של הלקוחות בסיכון. ## עיקרון שני: תוכן מקורי לכל חשבון זה העיקרון הכי חשוב, וגם הכי מתיש. אותו טקסט בדיוק, עם אותה תמונה, בעשרות עמודים, הוא הדפוס הקלאסי שמערכות לזיהוי ספאם מחפשות. גם אם כל העמודים שייכים ללקוח אחד. ### מה נחשב "מקורי מספיק" אין לזה הגדרה מספרית, ולא כדאי לחפש אחת. השאלה הנכונה היא: **האם הפוסט הזה נכתב בשביל הקהל של החשבון הזה?** דרכים מעשיות להגיע לשם: 1. **פתיחה שונה** לכל קבוצת חשבונות 2. **פרט מקומי אמיתי**: שם הסניף, שכונה, אירוע מקומי, איש או אשת צוות 3. **ויזואל מגוון**: כמה תמונות או גרסאות של סרטון, ולא קובץ אחד לכולם 4. **קריאה לפעולה בניסוח אחר** 5. **לא כל פוסט לכל חשבון**: אם הסניף לא משתתף במבצע, הוא לא צריך את הפוסט עוזרי כתיבה מבוססי בינה מלאכותית יכולים לייצר וריאציות מהר. הם עוזרים כשהם משנים את התוכן באמת, ולא רק מחליפים מילים נרדפות. וריאציה שנבדלת רק בכמה מילים היא עדיין שכפול. ## עיקרון שלישי: קצב מדורג גם תוכן מקורי, אם הוא יוצא לחמישים חשבונות באותה שנייה, יוצר דפוס חריג. פריסה בזמן היא דרך פשוטה להיראות כמו מה שאתם: צוות שמפרסם בשם לקוחות שונים. ### כללי אצבע לתזמון 1. **פזרו את הפרסום** של אותו קמפיין על פני כמה שעות, ובקמפיינים גדולים על פני יום או יותר 2. **הוסיפו מרווח משתנה** בין חשבונות, ולא קצב קבוע של פוסט כל דקה בדיוק 3. **כבדו את המגבלה לכל חשבון** ואת המכסה הכוללת של האפליקציה. כשמתקרבים אליהן, עדיף לדחות פרסום מאשר לנסות שוב ושוב 4. **שימו לב לשגיאות**: אם הרשת מחזירה שגיאת קצב או הגבלה, זה סימן לעצור ולהאט, לא לנסות שוב מיד ## עיקרון רביעי: מעורבות אמיתית בלבד חלק מהחסימות לא נובעות מהפרסום עצמו, אלא ממה שקורה אחריו. כמה דברים שכדאי להימנע מהם: 1. עמודים של אותו לקוח שמגיבים ומשתפים זה את זה באופן שיטתי 2. בקשות כמו "תייגו שלושה חברים" או "הגיבו 'כן' כדי לקבל" שנועדו לנפח מעורבות 3. תגובה ראשונה עם קישור שמתפרסמת שוב ושוב בניסוח זהה בכל העמודים 4. קישורים מקוצרים שמסתירים את היעד או מובילים לדף לא קשור תגובה ראשונה עם קישור היא דבר לגיטימי לגמרי. היא צריכה לעמוד באותם כללים כמו הפוסט: מגוונת, רלוונטית ומובילה למה שהיא מבטיחה. ## מה עושים כשחשבון בכל זאת הוגבל 1. **עוצרים את הפרסום לאותו חשבון**, ולא מנסים לעקוף. 2. **קוראים את ההודעה מהרשת**. לרוב היא מציינת את הסיבה הכללית. 3. **בודקים את התוכן האחרון** מול הכללים: שכפול, קישורים, ניסוחים. 4. **מגישים ערעור** דרך הערוץ הרשמי אם ההגבלה נראית שגויה. 5. **מעדכנים את התהליך** כך שזה לא יקרה בחשבונות אחרים. ## צ'קליסט לפרסום בהיקף בלי חסימות 1. כל החשבונות מחוברים דרך API רשמי, בהרשאת בעל/ת החשבון 2. אין שיתוף סיסמאות ואין אוטומציה של דפדפן 3. לכל קבוצת חשבונות יש ניסוח וויזואל משלה 4. יש פרט מקומי או רלוונטי בכל פוסט 5. הפרסום מפוזר בזמן עם מרווחים משתנים 6. המגבלות לכל חשבון ולכל אפליקציה ידועות ומכובדות 7. שגיאות קצב עוצרות את הפרסום ולא מפעילות ניסיונות חוזרים מיידיים 8. אין מעורבות מלאכותית בין עמודים של אותו לקוח 9. הקישורים מובילים בדיוק למה שהפוסט מבטיח 10. מישהו/י בצוות קרא/ה את מדיניות הרשתות בחודשים האחרונים ## לסיכום אין טריק שמאפשר לפרסם בהיקף בלי להיחסם, ולא צריך כזה. מה שעובד הוא שילוב של ממשקים רשמיים, תוכן שנכתב לקהל של כל חשבון, קצב שמכבד את המגבלות ומעורבות אמיתית. זה דורש יותר עבודה מהעתק והדבק, אבל זה גם מה שמביא תוצאות, כי קהל מגיב לתוכן שמדבר אליו. שַׁגֵּר נבנה על העקרונות האלה: הוא מפרסם רק דרך ממשק API רשמי של כל רשת, פורס את השליחה בקצב שמכבד את המגבלות של כל רשת וכל חשבון, ועוזר הכתיבה שלו מייצר וריאציות שונות באמת לכל קבוצת חשבונות, כדי שכל עמוד יקבל תוכן שנכתב בשבילו. --- Source: https://shager.ai/blog/avoid-spam-blocks-when-posting-at-scale # צינור תוכן של סוכן מקצה לקצה: מבריף של לקוח ועד דוח לחיצות לפי עמוד _2026-10-06 · איך נראה צינור תוכן מלא שסוכן AI מריץ מול שַׁגֵּר: בריף, ניסוח לכל חשבון, מדיה, טיוטה, אישור לקוח, פרסום מדורג ומדידה, ומה נשאר בידיים של אדם בכל אחד מהשלבים._ צינור תוכן של סוכן מקצה לקצה הוא רצף של שמונה שלבים: בריף, תכנון מסרים, ניסוח שונה לכל חשבון, הכנת מדיה, טיוטה בְּשַׁגֵּר, אישור לקוח, פרסום מדורג ומדידה. הסוכן עושה את רוב העבודה בשלבים שבהם יש הרבה טקסט והרבה חשבונות. אדם מחליט בשלושה מקומות: מה המסר, מה מאשרים, ומה לומדים מהתוצאות. שַׁגֵּר אחראי על מה שאסור שייפול בין הכיסאות: בדיקה מול כללי הרשת, פיזור זמני השליחה, קישור ופרמטרי UTM לכל חשבון, וספירת הלחיצות. רוב המדריכים שלנו מתמקדים בשלב אחד, כמו חיבור כלי או בניית skill. המדריך הזה מחבר את כולם, כדי שיהיה ברור איפה כל חלק יושב ומה עובר בין השלבים. ## מי עושה מה? לפני השלבים עצמם, הטבלה שהכי עוזרת לסוכנויות לחשוב על זה: | שלב | הסוכן | אדם | שַׁגֵּר | |---|---|---|---| | 1. בריף | מסכם, שואל שאלות חסרות | כותב ומאשר | | | 2. מסרים | מציע זוויות ומבנה | בוחר | | | 3. ניסוח לכל חשבון | כותב כיתוב שונה לכל עמוד | דוגם ובודק | | | 4. מדיה | מעלה מכתובת URL עם מידות ואורך | מספק או מאשר | בודק התאמה לפורמט | | 5. טיוטה | יוצר פוסט עם `per_channel` | | בודק מול כללי הרשת | | 6. אישור | שולח בקשת אישור | הלקוח מאשר בקישור | מנהל את הסטטוס | | 7. פרסום | מתזמן, אם יש לו הרשאה | מתזמן, אם אין | שולח מדורג, תגובה ראשונה | | 8. מדידה | מושך נתונים ומסכם | מסיק מסקנות | סופר לחיצות לכל חשבון | שימו לב שבעמודה של האדם אין "מעתיק ומדביק". זה כל העניין. ## שלב 1: בריף שסוכן יכול לעבוד ממנו הבריף הוא הנקודה שבה רוב הצינורות נשברים, ולא בגלל הסוכן. בריף כמו "פוסטים על המבצע" לא נותן לסוכן שום דבר לעבוד איתו, והתוצאה תהיה גנרית. בריף שימושי כולל: ההצעה במשפט אחד, למי היא מיועדת, קישור לדף הנחיתה, מה אסור להגיד, אילו קבוצות חשבונות, ובאילו ימים. הסוכן יכול לעזור כאן בדבר אחד חשוב: לשאול. הנחיה טובה לסוכן היא "לפני שאתה כותב, רשום מה חסר בבריף ושאל". זה חוסך סבב תיקונים שלם. ## שלב 2: מסרים לפני ניסוחים לפני שכותבים ארבעים כיתובים, כדאי שהסוכן יציע שלוש או ארבע זוויות למסר, ואדם יבחר. למשל, עבור מבצע של רשת מרפאות: זווית של זמינות ("תור תוך שבוע"), זווית משפחתית ("בדיקה לכל המשפחה בביקור אחד"), וזווית מקומית ("הסניף שלכם בשכונה"). הבחירה הזו לוקחת לאדם דקה, והיא קובעת את האיכות של כל מה שבא אחריה. ## שלב 3: ניסוח שונה לכל חשבון כאן הסוכן מרוויח את מקומו. אדם לא יכתוב ארבעים ניסוחים שונים באמת לאותו פוסט, וגם לא כדאי שינסה. סוכן יכול, בתנאי שנותנים לו חומר: שם הסניף, העיר, משהו ספציפי לכל מקום. ניסוח שמחליף רק את שם העיר הוא לא ניסוח שונה. בְּשַׁגֵּר זה נכנס לשדה `per_channel`, שבו לכל `channel_id` יש `caption` משלו, ואם צריך גם `first_comment` וגם `format` משלו. שַׁגֵּר ממליץ על זה במפורש, כי אותו טקסט בדיוק בעשרות עמודים בפרק זמן קצר נראה כמו ספאם, גם לקוראים וגם לרשתות. הרחבנו על איך עושים את זה טוב ב[מדריך על גיוון כיתובים לכל חשבון](/blog/caption-variation-per-account-with-ai). ## שלב 4: מדיה שעוברת בפעם הראשונה הסוכן מעלה את המדיה עם `upload_media_from_url`. לסרטונים קצרים, השדות `width`, `height` וגם `duration_ms` הם לא פרט טכני שולי. הם מה שמאפשר לְשַׁגֵּר לבדוק מראש אם הסרטון מתאים לפורמט Reel, Short או Story, ולא לגלות את זה כשהפוסט כבר בדרך. סרטון אחד יכול לשמש כמה פורמטים, והשדה `format` ברמת החשבון קובע איך הוא יעלה בכל אחד. ## שלב 5: טיוטה, לא פרסום הסוכן יוצר את הפוסט עם `create_post`, בלי `schedule_at`, כלומר כטיוטה. בפוסט עצמו נכנסים גם `cta_url` לדף הנחיתה, `first_comment` עם הזמנה ללחוץ, `campaign` שיהפוך לפרמטר `utm_campaign`, וגם `label` עם שם פנימי שיאפשר למצוא את הפוסט אחר כך. בשלב הזה שַׁגֵּר כבר בודק את הפוסט מול הכללים של כל רשת. אם משהו לא יעבור, הסוכן מקבל שגיאה מסוג `rejected` עם הסבר, ויכול לתקן לפני שמישהו בכלל רואה את הטיוטה. ## שלב 6: אישור הלקוח `request_approval` שולח ללקוח קישור לאישור. הלקוח פותח, רואה את הפוסט, מאשר או מבקש שינויים, בלי חשבון ובלי סיסמה. הסטטוסים בְּשַׁגֵּר משקפים את זה: `IN_REVIEW`, `CHANGES_REQUESTED`, `APPROVED`. סוכן שמריץ `list_posts` עם סטטוס `CHANGES_REQUESTED` יודע בדיוק מה צריך לתקן. לא כל לקוח צריך אישור על כל פוסט. בְּשַׁגֵּר אפשר להגדיר ברמת סביבת העבודה אם אישור הוא חובה. החשיבה על מתי דורשים אישור אנושי ומתי לא מפורטת במדריך [על אישור אנושי לפוסטים של סוכנים](/blog/human-approval-for-agent-posts). ## שלב 7: פרסום מדורג אחרי אישור, מתזמנים עם `schedule_post` וזמן בפורמט ISO 8601 עם offset, למשל `2026-10-11T09:00:00+03:00`. השאלה היא מי מתזמן. אם למפתח של הסוכן יש הרשאת `publish`, הוא יכול לעשות את זה בעצמו. אם לא, אדם עושה את זה בְּשַׁגֵּר. שתי האפשרויות לגיטימיות, וההחלטה נעשית כשאדם מאשר את המפתח. כשהפוסט יוצא, שַׁגֵּר לא שולח לכל החשבונות באותה שנייה. בין חשבונות של אותה רשת יש השהיה אקראית, כברירת מחדל 30 עד 90 שניות, ואפשר לשנות אותה עם `stagger_seconds`. התגובה הראשונה עולה מיד אחרי הפוסט בכל חשבון, עם הקישור המקוצר של אותו חשבון. ## שלב 8: מדידה שחוזרת לבריף `get_analytics` מחזיר לחיצות לפי חשבון ולפי פוסט בטווח תאריכים. מכיוון שכל חשבון קיבל קישור מקוצר ותגית `utm_content` משלו, אפשר לראות לא רק כמה לחצו, אלא איפה. העקרונות מאחורי זה מוסברים ב[מדריך לשיוך לידים לכל חשבון](/blog/utm-per-account-lead-attribution). החלק שרוב הצינורות מפספסים הוא הסגירה של המעגל. הסוכן מסכם את הנתונים, אבל אדם צריך להחליט מה עושים איתם: איזו זווית עבדה, אילו עמודים חלשים באופן קבוע, מה משנים בבריף של השבוע הבא. המסקנות האלה נכתבות לקובץ הבריף, והסוכן יקרא אותן בהרצה הבאה. ## איך מחברים את זה לשגרה שמונה שלבים נשמעים כמו הרבה, אבל בפועל הם מתחלקים לשני רגעים בשבוע. רגע אחד הוא ההכנה: שלבים 1 עד 6, שסוכן מריץ ברצף מתוך skill. הרגע השני הוא אחרי האישור: שלב 7, ובסוף השבוע שלב 8. את הגרסה המעשית, עם קובץ `SKILL.md` מלא והרצה מתוזמנת, בנינו במדריך [על שגרת הפצה שבועית](/blog/skill-weekly-distribution-routine). ## כמה החלטות שכדאי לקבל מראש 1. **איזה מפתח לכל שלב.** מפתח עם `read` וגם `write` להכנה, ומפתח עם `publish` רק לתזמון, אם בכלל. 2. **מה הסוכן עושה כשחסר משהו.** עוצר ושואל, ולא ממציא. 3. **מי מקבל את דוח השבוע.** מנהלת התיק, הלקוח, או שניהם. 4. **מה הקצב.** כמה פוסטים בשבוע לכל קבוצת חשבונות, ובאילו ימים. סוכן יכול לייצר הרבה יותר ממה שהקהל רוצה לקרוא. ההחלטות האלה לא טכניות, ולכן אף כלי לא יקבל אותן בשבילכם. אבל ברגע שהן כתובות, הסוכן יכול לעבוד לפיהן באופן עקבי. את כל דרכי החיבור לְשַׁגֵּר, כולל הרשמה עצמית של סוכן, תמצאו ב[עמוד הסוכנים](/agents). הצעד הבא הוא לבחור לקוח אחד וקמפיין אחד, ולהריץ את שמונת השלבים פעם אחת ידנית, עם הסוכן בצ'אט. אחרי ריצה אחת כזו יהיה לכם ברור איפה הבריף שלכם חלש, איפה הסוכן צריך הנחיות חדות יותר, ומה כדאי להפוך לשגרה. ## שאלות נפוצות ### האם הסוכן יכול להריץ את כל הצינור לבד? טכנית כן, אם המפתח שלו כולל `publish` וסביבת העבודה לא דורשת אישור לקוח. בפועל אנחנו ממליצים להשאיר לאדם לפחות את בחירת המסר ואת האישור, במיוחד בחודשים הראשונים עם לקוח. ### איפה הסוכן שומר את הבריף ואת המסקנות? שַׁגֵּר לא מחזיק בריפים, הוא מחזיק פוסטים, חשבונות ונתונים. את הבריף כדאי לשמור במקום שהסוכן קורא ממנו, כמו תיקייה בריפו או מסמך משותף, ולעדכן בו את המסקנות מכל שבוע. ### מה קורה אם פוסט נכשל בחלק מהחשבונות? הסטטוס שלו יהיה `PARTIALLY_PUBLISHED`, והפעולה `get_post` תראה באילו חשבונות הוא עלה ובאילו לא. סוכן יכול לבדוק את זה אחרי כל פרסום ולדווח, כדי שאדם יחליט אם לנסות שוב או לוותר על חשבון מסוים. --- Source: https://shager.ai/blog/agent-content-pipeline-end-to-end # איך לבחור פלטפורמת הפצה שסוכן AI יכול באמת להפעיל: 12 שאלות לפני שמתחייבים _2026-10-06 · רוב כלי ההפצה נבנו לאדם מול מסך. 12 שאלות שבודקות אם פלטפורמה באמת מתאימה לסוכן AI: גישה, הרשאות, בקרה, ניסוח לכל חשבון, מדידה, תמחור ומיקום של הנתונים._ פלטפורמת הפצה מתאימה לסוכן AI אם סוכן יכול לבצע בה את כל התהליך בלי לגעת בממשק, עם הרשאות מדורגות, בקרה אנושית במקומות הנכונים ומדידה ברמת החשבון. רוב הכלים בשוק נבנו לאדם שיושב מול מסך, וממשק API או חיבור לסוכנים נוספו להם אחר כך. ההבדל מורגש ברגע שמנסים להריץ סוכן על תהליך אמיתי, ולא על הדגמה. בחרתי לנסח את זה כשאלות ולא כרשימת פיצ'רים, כי פיצ'ר שמופיע בעמוד המוצר לא אומר הרבה. השאלה היא אם הוא עובד מהצד של סוכן. לכל שאלה צירפתי גם איך בודקים אותה בפועל, בחצי שעה, לפני שמתחייבים. ## קבוצה ראשונה: האם סוכן יכול בכלל לעבוד שם? ### 1. האם יש שרת MCP מרוחק, ולא רק API? API מיועד למפתחים שכותבים קוד. [MCP](https://modelcontextprotocol.io/specification/2025-06-18) מיועד לסוכנים: הוא מתאר את הפעולות בצורה שמודל יכול להבין ולבחור בהן לבד. פלטפורמה עם שרת MCP מרוחק מאפשרת לחבר את Claude Code, Claude Desktop, Cursor או Codex בהגדרה של דקות, בלי לכתוב קוד. **איך בודקים:** מחברים את הסוכן ומבקשים ממנו לרשום את הכלים שהוא רואה. אם הרשימה קצרה או שהתיאורים לא ברורים, הסוכן ינחש. ### 2. האם כל פעולה בממשק זמינה גם לסוכן? זה המקום שבו הרבה כלים נופלים. ממשק API מאפשר ליצור פוסט, אבל לא לשלוח לאישור לקוח, לא לנהל קבוצות, או לא למשוך נתונים. ברגע שחסרה פעולה אחת, אדם צריך לחזור לממשק, והתהליך נשבר. **איך בודקים:** כותבים את התהליך השבועי שלכם, צעד אחרי צעד, ובודקים שלכל צעד יש פעולה מקבילה. ### 3. האם יש מפרט מכונה? מפרט OpenAPI מאפשר לסוכן, ולמפתח שעובד איתו, להבין את כל הפעולות בלי לנחש. בְּשַׁגֵּר יש מפרט OpenAPI 3.1 פומבי, ואותן פעולות בדיוק זמינות גם בשרת MCP. ### 4. האם סוכן יכול להתחיל לבד? נשמע כמו פרט קטן, אבל זה משנה את כל חוויית ההתחלה. אם כדי שסוכן ינסה את המערכת צריך שאדם יפתח חשבון, יאמת מייל, יצור מפתח ויעתיק אותו, רוב הניסויים לא יקרו. בְּשַׁגֵּר סוכן יכול לפתוח לעצמו ארגז חול בקריאה אחת, ליצור טיוטות ולבדוק את המערכת, ורק כשאדם תובע את הסביבה אפשר לתזמן ולפרסם. המתכון המלא נמצא ב[מתכון ההרשמה לסוכנים](/auth.md). ## קבוצה שנייה: בקרה ואחריות ### 5. האם יש הפרדה בין כתיבה לפרסום? שאלו אם אפשר לתת לסוכן מפתח שיכול ליצור טיוטות אבל לא לפרסם. אם התשובה היא "כל מפתח יכול הכל", זו בעיה. בְּשַׁגֵּר למפתחות יש שלוש הרשאות, `read`, `write` וגם `publish`, ואדם בוחר אילו לתת. ### 6. האם יש יומן ביקורת של פעולות הסוכן? כשמשהו משתבש, הדבר הראשון שתרצו לדעת הוא מה הסוכן עשה. יומן שמתעד כל קריאה, עם זמן וסביבת עבודה, הוא תנאי ולא תוספת. ### 7. האם הלקוח יכול לאשר בלי להתחבר? אישור לקוח שדורש מהלקוח להיכנס למערכת נוספת לא יקרה בזמן. חפשו קישור אישור שנפתח בלי התחברות, שהסוכן יכול ליצור בעצמו, ושחוסם תזמון עד שהלקוח אישר. הרחבתי על זה ב[מאמר על אישור אנושי לפוסטים של סוכן](/blog/human-approval-for-agent-posts). ## קבוצה שלישית: פרסום בהיקף בלי לשרוף חשבונות ### 8. האם הפרסום עובר רק דרך ממשקים רשמיים? כלים שמפרסמים דרך אוטומציה של דפדפן או דרך שירותי ביניים לא רשמיים חושפים את החשבונות לסיכון שאין לכם שליטה עליו. [מדיניות הספאם של Meta](https://transparency.meta.com/policies/community-standards/spam/) אוסרת פעילות בתדירות גבוהה מאוד, ידנית או אוטומטית, ופלטפורמה צריכה לעבוד בתוך הכללים, לא מסביבם. ### 9. האם אפשר לנסח אחרת לכל חשבון, ולפזר בזמן? שתי היכולות האלה הן מה שמבדיל בין הפצה לבין הצפה. בדקו אם יש שדה שמאפשר כיתוב שונה לכל חשבון באותה קריאה, ואם הפרסום מתפזר בין חשבונות כברירת מחדל. בְּשַׁגֵּר אלה השדות `per_channel` וגם `stagger_seconds` בפעולה `create_post`, עם המתנה אקראית של 30 עד 90 שניות כברירת מחדל. **איך בודקים:** יוצרים פוסט טיוטה לחמישה חשבונות עם ניסוח שונה לכל אחד, ומוודאים שכל ניסוח נשמר במקומו. ### 10. האם יש בדיקה לפני שליחה? סרטון שלא מתאים לפורמט, כיתוב ארוך מדי או חשבון שהחיבור שלו פג. פלטפורמה טובה תופסת את זה לפני השליחה ומחזירה לסוכן סיבה ברורה, ולא אחרי שחצי מהחשבונות כבר פרסמו. ## קבוצה רביעית: מדידה, נתונים וכסף ### 11. האם המדידה היא ברמת החשבון? סוכן שמפיץ לשישים חשבונות צריך לדעת איזה מהם עובד. חפשו קישור מקוצר ותיוג UTM נפרד לכל חשבון שנוצרים אוטומטית, ופעולה שמחזירה לחיצות לפי חשבון ולפי פוסט. פירטתי איך בונים את זה מקצה לקצה ב[מאמר על מדידת לידים מתוכן של סוכן](/blog/measuring-leads-from-agent-content). ### 12. איך התמחור מתנהג כשמוסיפים סוכנים? כלים שמתמחרים לפי משתמש נשברים כשמוסיפים סוכנים, כי כל סוכן הופך ל"משתמש". שאלו על מה בדיוק משלמים. בְּשַׁגֵּר משלמים לפי מספר החשבונות, וגישת API, שרת MCP ומספר בלתי מוגבל של משתמשים כלולים בכל המסלולים, כולל ניסיון של 14 יום בלי כרטיס אשראי. הפרטים ב[עמוד המחירים](/pricing). ## שאלות נוספות שכדאי לשאול מעבר לשתים עשרה, יש כמה שאלות שתלויות בסוג הסוכנות: 1. **איפה הנתונים יושבים?** לסוכנויות שעובדות עם לקוחות אירופאים או עם לקוחות רגישים זה חשוב. שַׁגֵּר מאוחסן באיחוד האירופי, בפינלנד, ואפשר גם להריץ אותו על שרתים שלכם עם Docker. 2. **האם הלקוח יכול לחבר את החשבונות שלו בלי למסור סיסמה?** קישורי חיבור חוסכים ימים בקליטת לקוחות. כתבתי עליהם ב[מאמר על קישורי חיבור ללקוחות](/blog/client-connect-links). 3. **האם הפלטפורמה עצמה קריאה לסוכנים?** קובץ llms.txt, גרסאות Markdown של עמודים וקובץ סקיל מוכן מקצרים את הזמן שבו סוכן לומד את המערכת. 4. **אילו רשתות זמינות היום, ואילו רק "בקרוב"?** בְּשַׁגֵּר עמודי פייסבוק, חשבונות אינסטגרם מקצועיים וערוצי יוטיוב זמינים היום. טיקטוק ולינקדאין בפיתוח. ## טבלת סיכום לבדיקה מהירה | שאלה | למה זה חשוב | איך בודקים בחצי שעה | |---|---|---| | שרת MCP מרוחק | סוכן עובד בלי קוד | מחברים ומבקשים רשימת כלים | | שוויון בין הממשק לבין API | תהליך לא נשבר באמצע | ממפים את התהליך השבועי | | הרשמה עצמית של סוכן | ניסויים קורים | נותנים לסוכן להירשם לבד | | הרשאות מדורגות | בטיחות | יוצרים מפתח עם כתיבה בלבד | | יומן ביקורת | אחריות | מריצים פעולה ובודקים שנרשמה | | אישור בלי התחברות | הלקוח מאשר בזמן | שולחים לעצמכם קישור אישור | | ממשקים רשמיים | סיכון לחשבונות | שואלים ובודקים בתיעוד | | ניסוח שונה ופיזור | לא נראה כמו ספאם | טיוטה לחמישה חשבונות | | מדידה לפי חשבון | יודעים מה עובד | בודקים את פלט הנתונים | | תמחור לפי חשבונות | סוכנים לא מייקרים | קוראים את עמוד המחירים | ## שאלות נפוצות ### האם API מספיק, או שצריך דווקא MCP? API מספיק אם יש לכם מפתח שיכתוב ויתחזק את הקוד. MCP מאפשר לסוכן לעבוד ישירות מתוך הכלי שבו הוא רץ, בלי קוד ביניים. בפלטפורמה טובה שניהם חושפים את אותן פעולות, ואתם בוחרים לפי מי שמפעיל. ### האם אפשר לבדוק פלטפורמה בלי לחבר חשבונות אמיתיים? בְּשַׁגֵּר כן. סוכן יכול לפתוח ארגז חול, ליצור סביבות עבודה ולבנות טיוטות בלי לחבר אף חשבון ובלי שום פרסום. כשאתם מוכנים, אדם תובע את הסביבה ומחבר חשבונות אמיתיים. ### מה הדבר הראשון שצריך לבדוק? את השאלה השנייה: האם כל צעד בתהליך השבועי שלכם זמין לסוכן. פלטפורמה שעוברת את הבדיקה הזו כנראה נבנתה לסוכנים מההתחלה, ופלטפורמה שנכשלת בה תחייב אתכם לחזור לממשק בכל שבוע. הדרך הכי מהירה לבדוק את שַׁגֵּר מול הרשימה הזו היא לתת לסוכן שלכם לעשות את זה. הפנו אותו ל[עמוד הסוכנים](/agents), תנו לו להירשם לבד, ובקשו ממנו לעבור על השאלות אחת אחת ולדווח לכם מה מצא. --- Source: https://shager.ai/blog/choosing-a-distribution-platform-for-agents # סוכנים שכותבים עברית טובה: כיווניות, משלב, חגים והתאמה לקהל הישראלי _2026-10-06 · איך גורמים לסוכן AI לכתוב עברית שנשמעת ישראלית ולא מתורגמת: בעיות RTL בטקסט מעורב, משלב ולשון פנייה, חגים ומועדים, ומה שַׁגֵּר נותן לעבודה שוטפת בעברית._ סוכן AI יכול לכתוב עברית טובה, אבל רק אם אומרים לו במפורש מה זה "טובה": משלב מקצועי ולא מליצי, פנייה עקבית בלשון רבים, משפטים שנכתבו בעברית ולא תורגמו מאנגלית, וטקסט מעורב שלא נשבר בכיווניות. בלי הוראות כאלה, אפילו מודל חזק יחזיר עברית תקינה דקדוקית שאף ישראלי לא היה כותב. המאמר הזה מרכז את מה שלמדנו בכתיבת תוכן עברי עם סוכנים, ואת מה שֶׁשַּׁגֵּר עושה כדי שזה יעבוד בהיקף. ## למה עברית של מודל נשמעת מתורגמת? רוב הטקסט שמודלים למדו ממנו הוא באנגלית, וזה ניכר במבנה המשפט. הסימנים מוכרים לכל עורך תוכן ישראלי: 1. **פתיחים מנופחים.** "אנו נרגשים להכריז", "בעידן שבו", "הצטרפו אלינו למסע". אף בית קפה בחיפה לא מדבר ככה. 2. **סמיכות מלאכותית ושרשראות של "של".** "הגרסה החדשה של התפריט של הסתיו של הרשת". 3. **"כאשר" במקום "כש".** תקין, אבל רשמי מדי לפוסט. 4. **פעלים סבילים.** "התפריט הושק על ידי הרשת" במקום "השקנו תפריט". 5. **שלשות.** "טעים, איכותי ומשתלם" בכל משפט שני. 6. **סימני קריאה כפולים ומילים באנגלית שאין להן סיבה**, כשיש מילה עברית טבעית. הפתרון הוא לא לבקש "עברית טבעית", כי זה לא אומר לסוכן כלום. הפתרון הוא רשימה מפורשת של מה אסור, ושתיים או שלוש דוגמאות של פוסטים שהלקוח באמת אהב. ## משלב ולשון פנייה עברית מחייבת החלטה שאנגלית לא מחייבת: מגדר. "תזמינו" או "תזמין" או "תזמיני". רוב המותגים הישראליים פונים בלשון רבים, וזה פותר את רוב הבעיות. אבל צריך להגיד את זה לסוכן, אחרת הוא יתחיל ברבים ויעבור לזכר יחיד באמצע. ההוראה שאני משתמש בה לכל לקוח: ```text 1. פנייה לקהל בלשון רבים בלבד ("בואו", "תזמינו"). אסור לשון זכר יחיד, אסור "את/ה". 2. המותג מדבר בגוף ראשון רבים ("פתחנו", "אצלנו"). 3. משלב: עברית מדוברת מקצועית. כמו שבעל העסק היה כותב בעצמו, לא כמו הודעה לעיתונות. 4. "כש" ולא "כאשר". "אבל" ולא "אולם". "גם" ולא "אף". 5. אסור: "אנו נרגשים", "בעידן", "מסע", "חוויה בלתי נשכחת", "הצטרפו אלינו", "מהפכה". 6. מילים באנגלית רק כשזה מה שהקהל אומר: אפליקציה, וובינר, Wi-Fi. לא "אונליין" כשאפשר "באתר". 7. מספרים בספרות. מחירים עם ₪ אחרי המספר: 49 ₪. 8. אם לא בטוח בניקוד, בכתיב או במגדר של מילה, בחר ניסוח אחר. ``` הסעיף האחרון חוסך הרבה. מודלים נוטים להתבלבל במגדר של מילים כמו "שולחן" או "רוח", ובמקום לתקן, עדיף לעקוף. ## כיווניות: למה הנקודה קופצת להתחלה? טקסט עברי עם מילים באנגלית, מספרים או קישורים הוא טקסט דו כיווני. הדפדפן והאפליקציה מסדרים אותו לפי אלגוריתם הכיווניות של יוניקוד, והתוצאה לא תמיד מה שהתכוונתם. הדוגמה הקלאסית: משפט שמסתיים במילה באנגלית ואחריה נקודה. בתצוגה, הנקודה יכולה להופיע בצד הלא נכון של השורה. בעמוד אינטרנט הפתרון המומלץ הוא סימון כיווניות במבנה הדף, כמו שמסביר ארגון W3C ב[מאמר על סימון כיווניות בטקסט](https://www.w3.org/International/articles/inline-bidi-markup/). בפוסט ברשת חברתית אין לכם HTML, ולכן הכלי היחיד הוא תווי בקרה של יוניקוד, כמו סימן ימין לשמאל (RLM, U+200F). ארגון W3C מסביר את התווים האלה ומתי להשתמש בהם ב[שאלות ותשובות על תווי בקרה לכיווניות](https://www.w3.org/International/questions/qa-bidi-unicode-controls). בפועל, רוב הבעיות נפתרות בכתיבה ולא בתווים נסתרים. אלה הכללים שאני נותן לסוכן: ```text 1. קישור תמיד בשורה נפרדת, בסוף הפוסט. אף פעם לא באמצע משפט. 2. אל תסיים משפט במילה באנגלית או במספר. סדר את המשפט כך שהמילה האחרונה בעברית. 3. מספר טלפון בשורה נפרדת, בלי טקסט אחריו באותה שורה. 4. שמות מותגים באנגלית מותרים באמצע משפט, לא בסופו ולא בתחילתו. 5. האשטגים בסוף הפוסט, בשורה נפרדת. ``` כלל 2 נשמע קיצוני, אבל הוא חוסך את רוב התקלות שראיתי. משפט שמסתיים בשם החנות Google Play ואחריו נקודה יכול להיראות שבור. "את האפליקציה שלנו תמצאו בחנויות Google Play וגם App Store, בחיפוש לפי השם שלנו" נקרא נכון, כי השורה מסתיימת בעברית. ## חגים ומועדים לוח השנה העברי זז ביחס ללוח הלועזי, ולכן סוכן לא יכול להסתמך על "ראש השנה בספטמבר". הוא צריך לוח חגים אמיתי לשנה הנוכחית. בְּשַׁגֵּר יש לוח תוכן עם חגי ישראל, אבל ההחלטה מה לפרסם סביבם היא של הסוכנות, וצריך לכתוב אותה כהוראה. | מועד | מה הסוכן צריך לדעת | |---|---| | ראש השנה | ברכה מקובלת: "שנה טובה". פוסט ברכה בערב החג. | | יום כיפור | ללקוחות רבים אין פרסום בכלל. ברכה מקובלת לפני: "גמר חתימה טובה". | | סוכות ופסח | חופשות משפחתיות, תוכן של בילוי ואירוח. "חג שמח". | | חנוכה | שמונה ימים, מקום לסדרת פוסטים. | | יום הזיכרון ויום השואה | אין תוכן שיווקי. פוסט, אם בכלל, רק אחרי אישור אנושי. | | יום העצמאות | מגיע מיד אחרי יום הזיכרון. המעבר בין השניים רגיש. | וגם ההיבט שאנשים שוכחים: הרבה עסקים ישראליים לא מפרסמים בשבת, ולקוחות מסוימים מקפידים על זה גם בתוכן מתוזמן. על כללי התזמון סביב שבת וחגים יש פירוט ב[מאמר על אסטרטגיית תזמון לסוכנים](/blog/scheduling-strategy-for-agents). ## התאמה לחשבון: עברית אחרת לכל סניף הכלל שלא מפרסמים אותו טקסט מילה במילה בשלושים חשבונות חשוב בעברית במיוחד, כי קל לזהות טקסט משוכפל בשפה שבה הקהל קטן. השדה `per_channel` ב`create_post` מאפשר כיתוב שונה לכל חשבון, ובעברית יש הרבה מרחב לגיוון בלי לשנות את המסר: פנייה לשכונה, סדר מילים, פתיחה בשאלה או בתיאור. ```json create_post { "workspace_id": "ws_bakery", "campaign": "rosh-hashana-2026", "caption": "עוגות דבש לראש השנה, בהזמנה מראש.", "group_ids": ["grp_branches"], "per_channel": [ { "channel_id": "ch_fb_ramatgan", "caption": "רמת גן, עוגות הדבש חזרו. אפשר להזמין מראש ולאסוף בערב החג." }, { "channel_id": "ch_fb_modiin", "caption": "במודיעין כבר מזמינים עוגות דבש לחג. השנה גם בגרסה בלי אגוזים." }, { "channel_id": "ch_ig_brand", "caption": "עוגת דבש, תה חם ושנה טובה. הזמנות דרך הקישור בביו." } ] } ``` עוד על השיטה ב[מאמר על גיוון כיתובים לכל חשבון](/blog/caption-variation-per-account-with-ai). ## מה שַׁגֵּר נותן לעבודה בעברית שַׁגֵּר נבנה בעברית קודם, עם אתר מלא באנגלית. בפועל זה אומר כמה דברים שמשנים לסוכנות ישראלית. הממשק כולו מימין לשמאל, כך שמה שאתם רואים בעורך קרוב למה שהקהל יראה. יש עוזר כתיבה בעברית בתוך העורך, למי שכותב בעצמו או עורך אחרי הסוכן. לוח התוכן כולל את חגי ישראל. סביבת עבודה חדשה נוצרת עם אזור הזמן `Asia/Jerusalem` כברירת מחדל. והמחירים מוצגים גם בשקלים, כמו שמופיע ב[עמוד המחירים](/pricing). לסוכן, החלק החשוב הוא שאין שום תרגום בדרך. הכיתוב שהסוכן כותב בעברית הוא הכיתוב שמגיע לרשת, והבדיקה של שַׁגֵּר מול כללי הרשתות לפני השליחה עובדת על אותו טקסט. ## פרומפט מלא: פוסט חג בעברית לכל הסניפים ```text לקוח: מאפיית "שיבולת", 9 סניפים. סביבת עבודה: "מאפיית שיבולת". קרא את clients/shibolet/brief.md לפני שאתה מתחיל. כתוב פוסט לראש השנה לכל החשבונות בקבוצה "סניפים". 1. המסר: הזמנות מראש לעוגות דבש וחלות עגולות, איסוף עד הצהריים של ערב החג. 2. כיתוב שונה לכל חשבון, שמזכיר את העיר. 2 עד 3 משפטים. 3. לפי hebrew_style ו rtl_rules שבהוראות הקבועות. 4. בעמודי פייסבוק, הקישור להזמנות בתגובה הראשונה, בשורה נפרדת. 5. צור כטיוטה. בדוק את תאריך ערב החג בלוח החגים וכתוב לי אותו. אל תתזמן. ``` השלב החמישי מכריח את הסוכן לבדוק את התאריך ולא להניח אותו. זה המקום שבו טעויות קורות. אם הסוכן שלכם עוד לא מחובר לְשַׁגֵּר, [עמוד הסוכנים](/agents) מסביר איך, וממנו אפשר לעבור ל[פרומפטים המוכנים לסוכן תוכן](/blog/prompts-for-a-content-agent) ולהוסיף להם את כללי העברית שלמעלה. ## שאלות נפוצות ### האם עדיף לכתוב באנגלית ולתרגם לעברית? כמעט אף פעם. תרגום מביא איתו את מבנה המשפט האנגלי, וזה בדיוק מה שגורם לטקסט להישמע זר. עדיף לתת לסוכן את הבריף, גם אם הוא באנגלית, ולבקש ממנו לכתוב ישר בעברית לפי כללי הסגנון. ### האם צריך תווי RLM בכל פוסט? לא. ברוב המקרים מספיק לכתוב כך שהשורה מתחילה ומסתיימת בעברית ושהקישורים בשורות נפרדות. תווי בקרה הם פתרון למקרים שבהם אי אפשר לנסח אחרת, והם לא נראים בעין, ולכן קשה לתחזק אותם. ### האם הסוכן יכול להשתמש בעוזר הכתיבה של שַׁגֵּר? עוזר הכתיבה זמין בעורך של שַׁגֵּר, לאנשים שעובדים בממשק. סוכן שמחובר דרך MCP כותב את הטקסט בעצמו ושולח אותו ב`create_post`, כך שכללי הסגנון צריכים לשבת בהוראות של הסוכן. --- Source: https://shager.ai/blog/hebrew-content-agents # הפצת וידאו קצר לכל הרשתות: התאמות פורמט, אורך וכיתוב _2026-10-03 · איך להפיץ סרטון קצר לרילס, לשורטס ולעמודי פייסבוק בלי לאבד איכות: יחס תצוגה, אזורים בטוחים, אורך, כתוביות, כיתוב לכל רשת ותזמון בהיקף._ סרטון אנכי קצר הפך לפורמט ברירת המחדל כמעט בכל רשת. לסוכנויות זו הזדמנות: סרטון אחד טוב יכול לעבוד בעמוד פייסבוק, ברילס באינסטגרם ובשורטס ביוטיוב, ולהגיע לעשרות חשבונות של אותו לקוח. אבל "אותו סרטון בכל מקום" עובד רק אם מכינים אותו נכון מראש. המדריך הזה עוסק בצד המעשי: איך מכינים קובץ מאסטר אחד, מה משתנה בין הרשתות, ואיך מפיצים אותו להרבה חשבונות בלי שהוא ייראה כמו העתק מכני. ## קובץ מאסטר אחד, נכון מההתחלה רוב הבעיות בהפצת וידאו נולדות בעריכה. סרטון שנערך לרוחב ואחר כך "נחתך" לאנכי, או סרטון שהטקסט עליו יושב בדיוק מתחת לכפתורים של האפליקציה, ייראה רע בכל רשת. ### הגדרות בסיס מומלצות 1. **יחס 9:16**, ברזולוציה של 1080×1920. זה הפורמט שכל הרשתות הגדולות מציגות במסך מלא בפיד הווידאו הקצר. 2. **צילום אנכי מלכתחילה** כשאפשר. חיתוך של צילום רוחבי מאבד הרבה מהתמונה. 3. **סאונד נקי ומאוזן**, בלי מוזיקה שאין לכם זכויות להשתמש בה בפרסום מסחרי. 4. **כתוביות צרובות** בעברית. חלק גדול מהצפייה בפיד קורה בלי סאונד, וכתוביות הן ההבדל בין סרטון שמובן לסרטון שמגללים הלאה. ### אזורים בטוחים בכל רשת יש שכבה של ממשק מעל הסרטון: שם החשבון והכיתוב בתחתית, כפתורי לייק ושיתוף בצד. המיקום המדויק משתנה בין הרשתות ובין גרסאות של האפליקציות, ולכן הכלל הבטוח הוא להשאיר את הטקסט, הלוגו והפרטים החשובים במרכז המסך, הרחק מהשוליים התחתונים ומהצד. בעברית שימו לב במיוחד לצד: הכפתורים יושבים בצד ימין, בדיוק במקום שבו מתחילה שורת טקסט מיושרת לימין. ## אורך: מתחילים מהמסר, לא מהמגבלה המגבלות על אורך סרטון קצר השתנו בכמה רשתות בשנים האחרונות, וימשיכו להשתנות. לכן לא כדאי לבנות תהליך סביב מספר שנכון היום. בדקו את המגבלות העדכניות בעזרה הרשמית של כל רשת לפני קמפיין גדול. מה שכן יציב הוא העיקרון: **סרטון צריך להיות ארוך בדיוק כמו שהמסר דורש**. בקמפיינים של לידים, מבנה שעובד הרבה פעמים הוא: 1. **שניות ראשונות**: הבעיה או ההבטחה, בטקסט על המסך ובקול 2. **אמצע**: הוכחה אחת, הדגמה או דוגמה מוחשית 3. **סוף**: קריאה לפעולה אחת, ברורה, שמתאימה למה שכתוב בכיתוב אם יש לכם סרטון ארוך, עדיף לחתוך ממנו כמה סרטונים קצרים עם מסר אחד כל אחד, מאשר לדחוס הכול לאחד. ## מה משתנה בין הרשתות הקובץ יכול להיות אותו קובץ. ההקשר שונה. | | עמוד פייסבוק | רילס באינסטגרם | שורטס ביוטיוב | |---|---|---|---| | איפה הקישור | בכיתוב או בתגובה הראשונה | בביו או בסטורי, לא בכיתוב | בתיאור או בתגובה | | תפקיד הכיתוב | הקשר וקריאה לפעולה | משפט פתיחה קצר, האשטגים מעטים | כותרת ברורה, חיפושית | | מה חשוב בכותרת | פחות רלוונטי | אין כותרת נפרדת | כותרת היא חלק מהגילוי | ### פייסבוק בעמוד עסקי הכיתוב יכול להיות ארוך יותר ולתת הקשר: מה הבעיה, למי ההצעה מתאימה, ומה הצעד הבא. הקישור יכול לשבת בכיתוב או בתגובה הראשונה, לפי מה שעובד אצלכם. ### אינסטגרם קישורים בכיתוב לא לחיצים, ולכן הכיתוב צריך להפנות למקום אחר: "הקישור בביו" או "שלחו לנו הודעה". השורה הראשונה היא העיקר, כי רוב הצופים לא יפתחו את ההמשך. ### יוטיוב ביוטיוב הכותרת והתיאור משפיעים על חיפוש והמלצות, כך שכדאי לנסח אותם כמו שמישהו/י היה מחפש/ת את הנושא. סרטון מסווג כשורט לפי הפורמט והאורך שלו, ולא לפי סימון נפרד, כך שאותו קובץ אנכי שהועלה דרך [ממשק API רשמי להעלאת סרטונים](https://developers.google.com/youtube/v3/docs/videos/insert) יכול להופיע כשורט אם הוא עומד בתנאים. ## הפצה להרבה חשבונות בלי להיראות כמו שכפול כאן סוכנויות טועות הכי הרבה. אותו סרטון, אותו כיתוב, באותה דקה, בשלושים עמודים, נראה לקהל ולמערכות של הרשתות כמו פעילות לא אותנטית. כמה עקרונות: 1. **גוונו את הכיתוב**: פתיחה אחרת, פרט מקומי, קריאה לפעולה בניסוח אחר. גם שינוי קטן עדיף על העתק מלא. 2. **שקלו כמה גרסאות של הסרטון**: פתיח אחר, כתובית אחרת בשנייה הראשונה, או סיום עם פרטי הסניף. עריכה אחת עם שלוש פתיחות חלופיות היא השקעה קטנה עם הרבה גיוון. 3. **פזרו את הפרסום בזמן**: לא כל החשבונות באותה דקה. פריסה של כמה שעות, או לאורך יום, נראית טבעית יותר ומכבדת את מגבלות הקצב של כל רשת. 4. **אל תפרסמו סרטון לחשבון שהוא לא רלוונטי לו**: לא כל סניף צריך כל סרטון. ## העלאה דרך ממשק API רשמי כשמפרסמים להרבה חשבונות, הכלי שבו משתמשים צריך לעבוד דרך הממשקים הרשמיים של הרשתות ולא דרך אוטומציה של הדפדפן או שיתוף סיסמאות. מעבר לסיכון לחשבונות, לממשק API רשמי יש מגבלות מוגדרות שאפשר לתכנן לפיהן. למשל, Meta מתעדת ב[מדריך הפרסום של אינסטגרם](https://developers.facebook.com/docs/instagram-platform/content-publishing) את מגבלת הפרסומים דרך ממשק API לכל חשבון בחלון של 24 שעות, ויוטיוב מחשבת לכל העלאה עלות במכסה היומית של הפרויקט, כפי שמפורט ב[טבלת עלויות המכסה](https://developers.google.com/youtube/v3/determine_quota_cost). כלי הפצה רציני צריך להכיר את המגבלות האלה ולתזמן בהתאם. ## צ'קליסט לפני הפצת סרטון לכל החשבונות 1. הסרטון ביחס 9:16, ברזולוציה 1080×1920, עם כתוביות צרובות בעברית 2. טקסט ולוגו במרכז, מחוץ לאזורי הממשק 3. נבדקה מגבלת האורך העדכנית בכל רשת 4. יש קריאה לפעולה אחת, שמתאימה לכיתוב 5. הכיתוב הותאם לכל רשת: קישור, כותרת, אורך 6. הוכנו לפחות שתי וריאציות של כיתוב 7. הפרסום מפוזר בזמן בין החשבונות 8. הזכויות למוזיקה ולתמונות מאפשרות שימוש מסחרי 9. נבדקה תצוגה מקדימה בטלפון לפני התזמון ## לסיכום וידאו קצר הוא אחד הנכסים היעילים ביותר לסוכנות שמפיצה תוכן להרבה חשבונות, בתנאי שמכינים אותו כקובץ מאסטר נכון ומתאימים את ההקשר לכל רשת. ההבדל בין סרטון שמביא פניות לסרטון שנבלע בפיד הוא לרוב לא באיכות ההפקה, אלא בכתוביות, בשנייה הראשונה ובכיתוב שמסביב. בְּשַׁגֵּר אפשר להעלות סרטון פעם אחת, לכתוב כיתוב שונה לכל רשת ולכל קבוצת חשבונות בעזרת עוזר הכתיבה בעברית, וּלְשַׁגֵּר אותו לעמודי פייסבוק, לאינסטגרם וליוטיוב בפריסה מדורגת שמכבדת את המגבלות של כל רשת, דרך הממשקים הרשמיים בלבד. --- Source: https://shager.ai/blog/video-first-distribution-reels-shorts # אתר שסוכנים יודעים לקרוא: llms.txt, גרסאות Markdown, OpenAPI וכרטיס שרת MCP _2026-10-02 · מה צריך כדי שסוכן AI יבין אתר ושירות בלי לנחש: קובץ llms.txt, עמודי Markdown, מפרט OpenAPI, קטלוג API וכרטיס שרת MCP, עם האתר shager.ai כדוגמה עובדת מלאה._ אתר מוכן לסוכנים הוא אתר שבו סוכן AI יכול למצוא, בלי לגרד HTML ובלי לנחש, שלושה דברים: מה השירות עושה, איך מתחברים אליו, ואיך מבצעים בו פעולה. בפועל זה חמישה קבצים או נקודות קצה: `llms.txt` עם תקציר ומפת קישורים, גרסת Markdown לכל עמוד, מפרט OpenAPI שמתאר את ממשק התכנות, קטלוג ב`/.well-known/api-catalog`, וכרטיס שרת MCP. shager.ai מפרסם את כולם, ולכן אשתמש בו כדוגמה. חשוב להגיד מה זה לא. אף אחד מהקבצים האלה לא מבטיח שמנוע חיפוש או מודל שפה יקרא אותו או ימליץ עליכם. הם מורידים את העלות של סוכן להבין אתכם נכון, וזה הכל. אבל כשסוכן מחליט עם איזה שירות לעבוד, שירות שאפשר להבין בשלוש קריאות עדיף על שירות שצריך לגרד. ## מה זה llms.txt ומה צריך להיות בו? `llms.txt` הוא הצעה שפרסם Jeremy Howard בספטמבר 2024, ומתוחזקת ב[llmstxt.org](https://llmstxt.org/). זו לא תקינה של IETF או של W3C, אלא מוסכמה פתוחה. הקובץ יושב בשורש האתר, `/llms.txt`, ונכתב בפורמט Markdown במבנה קבוע: 1. כותרת H1 עם שם הפרויקט או האתר. זה החלק היחיד שהוא חובה. 2. ציטוט (blockquote) עם תקציר קצר. 3. פסקאות חופשיות עם מידע נוסף, בלי כותרות. 4. אפס או יותר רשימות קבצים, כל אחת תחת H2, שבהן כל פריט הוא קישור Markdown ואחריו, אם רוצים, נקודתיים והערה. לפי ההצעה, לרשימה שנקראת `Optional` יש משמעות מיוחדת: אלה קישורים שסוכן יכול לדלג עליהם כשהוא צריך הקשר קצר יותר. ככה זה נראה ב[llms.txt של שַׁגֵּר](https://shager.ai/llms.txt), בקיצור: ```markdown # Shager > Shager (שגר) is agent-first distribution infrastructure for agencies and marketers: ... ## For AI agents - MCP server: https://app.shager.ai/api/mcp (Authorization: Bearer ; OAuth sign-in is coming) - REST API: https://app.shager.ai/api/v1 ... ## Product - [Shager for AI agents](https://shager.ai/md/en/agents): Connect Claude, ChatGPT or Cursor to Shager ... ## Optional - [Sitemap](https://shager.ai/sitemap.xml) ``` שלוש החלטות שקיבלנו ואני ממליץ עליהן. התקציר אומר במפורש מה לא קיים עדיין (טיקטוק ולינקדאין בפיתוח), כי סוכן שמסיק יכולת שלא קיימת יטעה את המשתמש שלו. הקטע "For AI agents" מופיע לפני רשימת העמודים, כי סוכן שמגיע לקובץ צריך קודם כל לדעת איך מתחברים. והקישורים ברשימות מובילים לגרסאות Markdown ולא לעמודי HTML. ### ומה עם `llms-full.txt`? `llms-full.txt` הוא קובץ אחד עם כל התוכן של האתר בפורמט Markdown. הוא לא חלק מההצעה שבאתר llmstxt.org, אבל הוא מוסכמה נפוצה, וְשַׁגֵּר מפרסם אותו [בכתובת קבועה](https://shager.ai/llms-full.txt). הוא שימושי לסוכן שרוצה לטעון את כל ההקשר בקריאה אחת, ופחות שימושי כשהאתר גדול. ## גרסת Markdown לכל עמוד ההצעה שבאתר llmstxt.org ממליצה שלכל עמוד עם מידע שימושי תהיה גרסת Markdown נקייה, ומתארת גילוי שלה דרך `rel="alternate"` עם `type="text/markdown"`, כאלמנט `` בקוד העמוד או ככותרת `Link` בתשובת השרת. באתר shager.ai יש שלוש דרכים להגיע לגרסת Markdown של כל עמוד, ושלושתן עובדות: ```bash # 1. נתיב ייעודי תחת /md curl https://shager.ai/md/pricing # 2. משא ומתן על תוכן: אותה כתובת, כותרת Accept אחרת curl -H "Accept: text/markdown" https://shager.ai/pricing # 3. גילוי דרך כותרת Link בתשובת ה HTML curl -sI https://shager.ai/agents | grep -i '^link' # link: ; rel="api-catalog", ; rel="describedby"; type="text/plain", ; rel="alternate"; type="text/markdown" ``` הדרך השנייה נשענת על משא ומתן על תוכן, מנגנון שמוגדר ב[RFC 9110 של HTTP](https://www.rfc-editor.org/rfc/rfc9110#name-content-negotiation). היתרון שלה הוא שסוכן לא צריך לדעת על מוסכמת `/md` מראש. הוא מבקש Markdown ומקבל Markdown. בעמודי Markdown כדאי להוריד ניווט, כפתורים וטקסט שיווקי שתלוי בעיצוב, ולהשאיר טבלאות, קוד ועובדות. באתר shager.ai הגרסה העברית יושבת תחת `/md/...` והאנגלית תחת `/md/en/...`. ## OpenAPI: החוזה של ממשק התכנות `llms.txt` מספר לסוכן מה קיים. מפרט [OpenAPI 3.1](https://spec.openapis.org/oas/v3.1.0) מספר לו בדיוק איך לקרוא לכל פעולה: נתיב, שדות, סוגים, ערכים מותרים ושגיאות. [מפרט OpenAPI של שַׁגֵּר](https://app.shager.ai/api/v1/openapi.json) מתאר את כל הפעולות שזמינות גם ככלי MCP, עם `operationId` זהה לשם הכלי, כך שסוכן שקרא את המפרט יודע שהכלי `create_post` והקריאה `POST /workspaces/{workspace_id}/posts` הם אותה פעולה. כמה דברים שהופכים מפרט OpenAPI לשימושי לסוכן, ולא רק לגנרטור קוד: 1. **תיאור לכל שדה, שמסביר למה הוא משמש.** אצלנו `stagger_seconds` מתואר כהפסקה אקראית בשניות בין חשבונות באותה רשת, עם ברירת המחדל. 2. **דוגמאות בתוך התיאור** במקומות שבהם הפורמט מכשיל, כמו `schedule_at` שמקבל ISO 8601 עם היסט. 3. **ערכים מותרים כרשימה סגורה (enum)**, כמו `FEED`, `REEL`, `STORY`, `SHORT`, `VIDEO`. 4. **סימון ההרשאה הנדרשת** לכל פעולה. אצלנו זה שדה הרחבה `x-scope`. ## קטלוג API: איפה ממשק התכנות נמצא [RFC 9727](https://www.rfc-editor.org/rfc/rfc9727) מגדיר כתובת קבועה, `/.well-known/api-catalog`, שבה מפרסם מתאר את ממשקי התכנות שלו ומקשר אליהם. לפי התקן, הקטלוג מתפרסם בפורמט Linkset עם סוג התוכן `application/linkset+json`, ובקשת HEAD לכתובת צריכה להחזיר כותרת `Link` עם היחס `api-catalog`. [הקטלוג של שַׁגֵּר](https://shager.ai/.well-known/api-catalog) מקשר את כתובת הבסיס של ממשק התכנות לשני דברים: `service-desc` שמצביע על מפרט OpenAPI (למכונה), ו`service-doc` שמצביע על עמוד הסוכנים בגרסת HTML ובגרסת Markdown (לאדם או למודל). היחסים האלה מוגדרים בתקן RFC 8631, ותקן הקטלוג משתמש בהם בדוגמאות שלו. ```json {"linkset":[{"anchor":"https://app.shager.ai/api/v1", "service-desc":[{"href":"https://app.shager.ai/api/v1/openapi.json","type":"application/openapi+json"}], "service-doc":[{"href":"https://shager.ai/en/agents","type":"text/html"}, {"href":"https://shager.ai/md/en/agents","type":"text/markdown"}]}]} ``` ## כרטיס שרת MCP כרטיס שרת MCP הוא מסמך JSON סטטי שמתאר שרת MCP מרוחק לפני שמתחברים אליו: שם, גרסה, תיאור, נקודות קצה וכותרות נדרשות. ההגדרה היא הרחבה של פרוטוקול MCP, [`SEP-2127`](https://modelcontextprotocol.io/seps/2127-mcp-server-cards), והסכמה המחייבת מתוחזקת במאגר נפרד של ההרחבה. לפי ההצעה, הכרטיס יכול לשבת בכל כתובת, והמיקום המומלץ הוא כתובת השרת עם `/server-card` בסוף. לגילוי לפי דומיין ההצעה מפנה לקטלוג AI בכתובת `/.well-known/ai-catalog.json`, ויש מימושים שמפרסמים את הכרטיס עצמו גם תחת `/.well-known/mcp/`. שַׁגֵּר מפרסם את הכרטיס בשני המקומות: [`app.shager.ai/api/mcp/server-card`](https://app.shager.ai/api/mcp/server-card) וגם [`shager.ai/.well-known/mcp/server-card.json`](https://shager.ai/.well-known/mcp/server-card.json). החלק החשוב בו הוא `remotes`: ```json "remotes": [{ "type": "streamable-http", "url": "https://app.shager.ai/api/mcp", "headers": [{ "name": "Authorization", "description": "Bearer shgr_… API key (self-signup: POST /api/v1/agent/signup)", "isRequired": true, "isSecret": true }] }] ``` מכאן לקוח MCP יודע בלי תיעוד נוסף שזה שרת Streamable HTTP, שצריך כותרת `Authorization`, ואיפה משיגים מפתח. ההצעה מסבירה שהכרטיס במתכונתו הראשונה לא אמור לפרסם את רשימת הכלים, כי כלים יכולים להשתנות לפי משתמש, ושהמקור המחייב לכלים הוא `tools/list` בזמן החיבור. שַׁגֵּר מוסיף רשימת כלים לכרטיס כמידע עזר, אבל סוכן צריך לסמוך על מה שהשרת מחזיר בחיבור. ## שני קבצים נוספים שאינם תקן `auth.md` הוא מוסכמה שלנו, לא תקן: מתכון קצר בשפה פשוטה שמסביר לסוכן איך נרשמים, מה מותר בסנדבוקס ואיך אדם תובע אותו. [הקובץ נמצא כאן](/auth.md). והסקיל ב`https://shager.ai/skills/shager/SKILL.md` כתוב בפורמט [Agent Skills](https://code.claude.com/docs/en/skills), כך שאפשר להוריד אותו כמו שהוא לתיקיית הסקילים של Claude Code. איך בונים סקיל כזה בעצמכם מוסבר ב[מדריך לבניית סקיל לְשַׁגֵּר](/blog/build-a-claude-skill-for-shager). ## רשימת בדיקה לאתר שלכם | רכיב | איפה | בדיקה מהירה | |---|---|---| | llms.txt | `/llms.txt` | H1, תקציר, קישורים לגרסאות Markdown | | Markdown לכל עמוד | `/md/...` או `Accept: text/markdown` | `curl -H "Accept: text/markdown"` מחזיר Markdown | | כותרת Link | כל עמוד HTML | `rel="alternate"` עם `type="text/markdown"` | | OpenAPI | כתובת קבועה | תיאור לכל שדה, enum, שגיאות | | קטלוג API | `/.well-known/api-catalog` | `application/linkset+json`, כותרת Link בבקשת HEAD | | כרטיס שרת MCP | `/server-card` | `remotes` עם כותרות נדרשות | כדי לראות את כל זה מנקודת המבט של סוכן, אפשר להתחיל מ[עמוד הסוכנים](/agents), שגם הוא זמין בגרסת Markdown. ## שאלות נפוצות ### האם llms.txt משפר דירוג בגוגל? אין לי מקור רשמי שאומר שכן, ולכן לא הייתי מבטיח את זה ללקוח. הקובץ מיועד לסוכנים ולכלים שקוראים אותו במפורש. העלות שלו נמוכה, והתועלת העיקרית היא שסוכן שמגיע אליכם מבין אתכם נכון. ### צריך גם llms.txt וגם sitemap.xml? כן, כי הם משרתים קוראים שונים. sitemap מפרט כתובות לסורק של מנוע חיפוש, והקובץ llms.txt נותן לסוכן תקציר ומפה מוערת של מה שחשוב. באתר shager.ai מפת האתר מופיעה בתוך llms.txt תחת `Optional`. ### מה עדיף לסוכן, OpenAPI או שרת MCP? תלוי איפה הסוכן רץ. סוכן בתוך Claude Code, Cursor או Codex עובד הכי טבעי עם שרת MCP. סקריפט או שירות בקוד ישתמשו בממשק REST לפי מפרט OpenAPI. בְּשַׁגֵּר שניהם חושפים את אותן פעולות, כך שאין צורך לבחור פעם אחת ולתמיד. --- Source: https://shager.ai/blog/agent-ready-websites-llms-txt # תהליך אישור לקוח שלא תוקע את לוח התוכן _2026-09-30 · איך בונים תהליך אישור לקוח שעובד: מה מאשרים ומה לא, דדליינים ברורים, קישור אישור במקום שרשורי וואטסאפ, וכללים למקרה שהלקוח לא עונה._ בכל סוכנות יש את הרגע הזה: לוח התוכן מוכן, הסרטונים ערוכים, הכיתובים כתובים, והכול מחכה ל"מאשר/ת" מהצד של הלקוח. יום עובר, עוד יום, ובסוף מגיעה הודעה בוואטסאפ בעשר בלילה עם שלושה תיקונים, אחד מהם סותר את מה שסוכם בשבוע שעבר. אישור לקוח הוא חלק לגיטימי ונחוץ בעבודה. הבעיה היא לא האישור עצמו, אלא תהליך שלא הוגדר. המאמר הזה מציע דרך לבנות תהליך אישור שמגן על הלקוח ועל המותג שלו, בלי להפוך את הסוכנות לבת ערובה. ## למה אישורים נתקעים ברוב המקרים זה לא חוסר רצון. אישורים נתקעים כי: 1. **לא ברור מה צריך לאשר**: הלקוח מקבל קובץ עם ארבעים פוסטים ולא יודע מאיפה להתחיל. 2. **האישור מפוזר בין ערוצים**: חלק במייל, חלק בוואטסאפ, חלק בשיחה. אף אחד לא יודע מה הגרסה האחרונה. 3. **אין דדליין**: "תאשרו כשתוכלו" שווה "לא עכשיו". 4. **יש יותר מדי מאשרים**: כל אחד מוסיף הערה, ואין מי שמכריע. 5. **הלקוח לא רואה את הפוסט כמו שהוא ייראה**: טקסט בקובץ ותמונה בקובץ נפרד לא מרגישים כמו פוסט, ולכן קשה להחליט. כל אחת מהסיבות האלה ניתנת לפתרון בתהליך, לא בכוח רצון. ## מה הלקוח צריך לאשר, ומה לא השאלה הכי חשובה, והכי פחות נשאלת. כשסוכנות מפרסמת בעשרות חשבונות, אישור של כל פוסט בנפרד פשוט לא מחזיק. צריך להחליט מראש על רמת האישור. ### שלוש רמות אישור נפוצות | רמה | מה מאשרים | מתאים ל | |---|---|---| | אישור קמפיין | מסר, הצעה, קריאה לפעולה, קריאייטיב מרכזי | לקוחות עם הרבה חשבונות דומים | | אישור לוח שבועי | כל הפוסטים של השבוע בתצוגה אחת | לקוחות עם נפח בינוני | | אישור פוסט אחר פוסט | כל פוסט בנפרד | תחומים רגישים או רגולטוריים | ברוב העבודה של סוכנויות לידים, אישור ברמת הקמפיין הוא הנכון: הלקוח מאשר את המסר ואת הקריאייטיב, והסוכנות אחראית לווריאציות ולהתאמות לכל חשבון. כדאי לסכם את זה בכתב בתחילת ההתקשרות. ### מה תמיד צריך אישור מפורש 1. מחירים, הנחות ותנאי מבצע 2. טענות על תוצאות, איכות או השוואה למתחרים 3. שימוש בתמונות של אנשים, עובדים או לקוחות 4. תוכן בתחומים מפוקחים כמו בריאות, פיננסים או נדל"ן ## קישור אישור אחד במקום שרשור הודעות הדבר שהכי משפר תהליך אישור הוא להוציא אותו מהוואטסאפ. קישור אישור ייעודי, שבו הלקוח רואה את הפוסטים כמו שהם ייראו ברשת, עם התמונה או הסרטון, הכיתוב ותאריך הפרסום, משנה את הדינמיקה. מה צריך להיות בו: 1. **תצוגה מקדימה אמיתית** של הפוסט, לא טקסט בנפרד מהמדיה 2. **כפתור אישור וכפתור "צריך תיקון"** עם שדה להערה צמודה לפוסט 3. **בלי צורך בהרשמה או סיסמה** ללקוח. כל צעד נוסף מוריד את הסיכוי שיענה 4. **תיעוד**: מי אישר, מתי, ואיזו גרסה כך כל ההערות נמצאות במקום אחד, צמודות לפוסט שאליו הן מתייחסות, ואין ויכוח אחר כך על "אבל אמרתי לכם". ## דדליינים שעובדים דדליין לאישור הוא לא חוסר נימוס. הוא הדרך היחידה שבה לוח תוכן מחזיק. ### כלל אצבע מעשי 1. **שליחה לאישור**: לפחות שלושה ימי עבודה לפני תאריך הפרסום הראשון בסבב 2. **מועד אחרון לאישור**: יום עבודה אחד לפני הפרסום, בשעה מוגדרת 3. **סבב תיקונים**: אחד כלול. סבב שני ומעלה מזיז את הלו"ז בהתאם את המספרים האלה כל סוכנות צריכה להתאים לעצמה. מה שחשוב הוא שהם כתובים, מוסכמים ומופיעים בכל בקשת אישור. ## מה עושים כשהלקוח לא עונה זה המקרה שבו רוב התהליכים קורסים. כדאי להחליט מראש, ולסכם עם הלקוח, מה קורה אם המועד האחרון עובר. אפשרויות נפוצות: 1. **הפוסט לא יוצא.** הבטוח ביותר, אבל משאיר את החשבונות שקטים ופוגע בקמפיין. 2. **הפוסט יוצא כפי שהוא.** מתאים רק אם יש אישור קמפיין מראש והפוסטים הם וריאציות שלו. 3. **יוצא תוכן חלופי שאושר מראש.** פוסטים "ירוקים", בלי מחירים או הבטחות, שהלקוח אישר פעם אחת לשימוש כגיבוי. האפשרות השלישית היא לרוב הפשרה הטובה: הלוח לא מתרוקן, והלקוח לא מופתע מתוכן שלא ראה. ## מאשר/ת אחד/ת, לא ועדה כשחמישה אנשים בצד של הלקוח מעירים על אותו פוסט, הסוכנות נקלעת לתיווך בין דעות. בקשו מהלקוח להגדיר מאשר/ת אחד/ת לכל חשבון או קבוצת חשבונות, שאחראי/ת לאסוף את ההערות הפנימיות ולהחזיר תשובה אחת. אם יש כמה בעלי עניין, אפשר לשלוח להם את קישור האישור לצפייה, אבל ההחלטה הסופית נשארת אצל אדם אחד. ## אישור כשמפרסמים לעשרות חשבונות כשקמפיין אחד יוצא לשלושים סניפים, לא שולחים ללקוח שלושים פוסטים לאישור. שולחים לו את מה שבאמת דורש החלטה שלו: 1. **את פוסט הבסיס** של הקמפיין, כולל המדיה והקריאה לפעולה 2. **דוגמה אחת מכל קבוצת חשבונות**, כדי שיראה איך נראית ההתאמה המקומית 3. **רשימה של החשבונות** שאליהם הקמפיין ייצא, ותאריכי הפרסום אחרי שהבסיס אושר, הסוכנות אחראית לשאר. אם הלקוח רוצה לראות הכול, אפשר לתת לו גישת צפייה ללוח המלא, בלי להפוך כל וריאציה לנקודת עצירה. ## צ'קליסט להקמת תהליך אישור 1. סוכם בכתב מה רמת האישור לכל לקוח 2. הוגדרו סוגי תוכן שתמיד דורשים אישור מפורש 3. יש מאשר/ת אחד/ת לכל לקוח או קבוצת חשבונות 4. האישור נעשה דרך קישור עם תצוגה מקדימה, לא בהודעות 5. כל בקשת אישור כוללת דדליין ברור 6. הוגדר מה קורה כשהדדליין עובר 7. יש מאגר של תוכן גיבוי מאושר מראש 8. נשמר תיעוד של מי אישר כל גרסה ## לסיכום תהליך אישור טוב לא מאט את העבודה, הוא מאיץ אותה. כשברור מה מאשרים, איפה, עד מתי ומה קורה אם אין תשובה, הלקוח מרגיש שליטה במותג שלו והסוכנות יכולה לתכנן שבועות קדימה. רוב החיכוך נעלם כשמפסיקים לנהל אישורים בשרשורי הודעות. בְּשַׁגֵּר אפשר לשלוח ללקוח קישור אישור שבו הוא רואה את הפוסטים כמו שהם ייראו, מאשר או מבקש תיקון צמוד לכל פוסט, בלי להירשם. הפוסטים ממתינים לאישור לפני שהם יוצאים לחשבונות, ויש תיעוד של מי אישר ומתי. --- Source: https://shager.ai/blog/client-approval-workflow-for-agencies # מפתחות API, הרשאות ויומן פעולות: איך נותנים לסוכן גישה לְשַׁגֵּר בלי לאבד שליטה _2026-09-29 · מדריך להרשאות read, write, publish בְּשַׁגֵּר: מה כל הרשאה מאפשרת, איזה מפתח לתת לכל סוכן, איך שומרים את המפתח מחוץ לקוד, ומה רואים ביומן הפעולות של הסוכנים._ לכל מפתח API בְּשַׁגֵּר יש אחת או יותר משלוש הרשאות: `read` לקריאה, `write` ליצירת טיוטות, מדיה וקבוצות, ו`publish` לתזמון ופרסום. הכלל הוא לתת לכל סוכן את המינימום שהוא צריך, מפתח נפרד לכל תפקיד, ולבדוק את יומן הפעולות בדף [ניהול הסוכנים](https://app.shager.ai/dashboard/agents), שבו מתועדת כל קריאה של סוכן. רק אדם יוצר ומבטל מפתחות. מאמר זה מיועד לאדם שאחראי על החשבון בסוכנות, לא לסוכן. הוא מסביר מה כל הרשאה פותחת בפועל, איך לבחור, ומה עושים כשמשהו נראה לא תקין. ## מה כל הרשאה מאפשרת? הטבלה מבוססת על השדה `x-scope` שמופיע לכל פעולה ב[מפרט OpenAPI של שַׁגֵּר](https://app.shager.ai/api/v1/openapi.json). אותן פעולות זמינות ככלים בשרת MCP של שַׁגֵּר, עם אותן הרשאות. | הרשאה | פעולות | |---|---| | `read` | `whoami`, `list_workspaces`, `list_channels`, `list_groups`, `list_posts`, `get_post`, `get_analytics` | | `write` | `create_workspace`, `create_connect_link`, `create_group`, `upload_media_from_url`, `create_post` (כטיוטה), `request_approval`, `cancel_post` | | `publish` | `schedule_post`, ו`create_post` עם `schedule_at` | שתי נקודות שכדאי לשים לב אליהן. הראשונה היא שההרשאות לא מכילות זו את זו: מפתח עם `publish` בלבד לא יכול ליצור טיוטה, ולכן סוכן שכותב ומתזמן צריך `read`, `write` ו`publish` יחד. השנייה היא ש`cancel_post` נמצא תחת `write`. סוכן שיכול ליצור טיוטות יכול גם לבטל תזמון של פוסט שעוד לא התחיל להתפרסם. ברוב הסוכנויות זה רצוי, כי עצירה היא פעולה בטוחה. ## איזה מפתח לתת לאיזה סוכן? | תפקיד | הרשאות | למה | |---|---|---| | סוכן דוחות | `read` | קורא נתונים ולא יוצר כלום | | סוכן תוכן בתקופת הרצה | `read`, `write` | כותב טיוטות, אדם מתזמן | | סוכן תוכן ותיק | `read`, `write`, `publish` | אחרי כמה שבועות בלי טעויות | | סקריפט ייבוא מדיה | `write` | מעלה קבצים ולא קורא נתוני לקוחות | שימו לב שגם עם `publish`, פוסט בסביבת עבודה שמוגדרת עם אישור לקוח לא יתוזמן בלי האישור. `schedule_post` ייכשל עם סיבה ברורה. ההרשאה קובעת מה הסוכן רשאי לנסות, וההגדרות של סביבת העבודה קובעות מה יעבור. על שכבת האישור כתבתי ב[מאמר על אישור אנושי לפוסטים של סוכנים](/blog/human-approval-for-agent-posts). ## ומה עם סוכן שנרשם בעצמו? סוכן יכול לפתוח סנדבוקס בלי אדם, בקריאה ל`POST /api/v1/agent/signup`, לפי [המתכון שבקובץ auth.md](/auth.md). הוא מקבל מפתח שמוצג פעם אחת וקישור תביעה. בסנדבוקס הוא יכול ליצור עד חמש סביבות עבודה, להעלות מדיה, ליצור טיוטות ולקרוא. הוא לא יכול לתזמן, לפרסם, ליצור קישורי חיבור או לשלוח בקשות אישור, וכל ניסיון כזה מחזיר `sandbox_unclaimed`. כשאדם פותח את קישור התביעה ונכנס, הוא הופך לבעלים ובוחר אם המפתח של הסוכן יקבל גם הרשאת `publish`. זו ההחלטה החשובה ביותר בכל התהליך, וכדאי לקבל אותה בכוונה ולא מתוך הרגל. סנדבוקס שלא נתבע תוך שבעה ימים פג. התהליך המלא מפורט ב[מאמר על הרשמה עצמית ותביעה](/blog/agent-self-signup-and-claim). ## איך שומרים את המפתח מחוץ לקוד? מפתח של שַׁגֵּר מתחיל ב`shgr_live_`, וְשַׁגֵּר שומר רק גיבוב שלו, כך שאי אפשר לשחזר אותו אחרי היצירה. אם הוא אבד, יוצרים חדש ומבטלים את הישן. הסיכון האמיתי הוא לא אובדן אלא דליפה: מפתח שנכנס לקובץ שנשמר במאגר קוד, או שהודבק בשיחה שנשמרת. בכלי Claude Code, הקובץ `.mcp.json` תומך בהרחבת משתני סביבה בכותרות, כך שהמפתח נשאר במשתנה סביבה והקובץ עצמו בטוח לשמירה במאגר. התחביר מתועד ב[תיעוד של Claude Code על MCP](https://code.claude.com/docs/en/mcp): ```json { "mcpServers": { "shager": { "type": "http", "url": "https://app.shager.ai/api/mcp", "headers": { "Authorization": "Bearer ${SHAGER_API_KEY}" } } } } ``` ובסקריפטים, אותו עיקרון: ```bash export SHAGER_API_KEY="shgr_live_..." # מתוך מנהל הסודות, לא מקובץ במאגר curl https://app.shager.ai/api/v1/me \ -H "Authorization: Bearer $SHAGER_API_KEY" ``` הקריאה ל`/me`, שהיא `whoami` בגרסת MCP, מחזירה את הארגון, האם זה עדיין סנדבוקס, ואת רשימת ההרשאות של המפתח. זו הקריאה הראשונה שכל סוכן צריך לעשות בתחילת עבודה, ואני כותב את זה בהוראות הקבועות. ## מה רואים ביומן הפעולות? כל קריאה של סוכן נרשמת ביומן, גם כשהיא נכשלת. ביומן רואים איזה מפתח קרא, לאיזו פעולה, מתי, ואם הקריאה הצליחה. קריאה שנכשלה נרשמת עם ההודעה שלה. שלושה דברים שאני בודק ביומן פעם בשבוע: 1. **כשלים חוזרים של `forbidden`.** סוכן שמנסה שוב ושוב פעולה שאין לו הרשאה אליה הוא סוכן שההוראות שלו לא ברורות, או שמישהו ביקש ממנו משהו שלא תוכנן. 2. **פעולות בשעות לא צפויות.** סוכן דוחות שרץ בשלוש בלילה ביום שלישי, כשהוא אמור לרוץ פעם בשבוע, מצדיק בדיקה. 3. **מפתחות שלא היו בשימוש זמן רב.** מפתח שאף אחד לא משתמש בו הוא רק סיכון. מבטלים אותו. ## אילו שגיאות הסוכן יכול לקבל? כל שגיאה מוחזרת במבנה `{ "error": { "code", "message" } }`. ההודעה מנוסחת כך שסוכן יכול להבין אותה ולדווח, והוראה טובה היא לדווח אותה כלשונה. | קוד | מצב HTTP | משמעות | |---|---|---| | `unauthorized` | 401 | אין מפתח, או שהמפתח לא תקף, פג או בוטל | | `forbidden` | 403 | למפתח אין את ההרשאה שהפעולה דורשת | | `sandbox_unclaimed` | 403 | סנדבוקס שעוד לא נתבע מנסה לפרסם או לחבר | | `rate_limited` | 429 | מעל 120 בקשות בדקה למפתח | | `rejected` | 422 | הפוסט לא עומד בכללים של אחת הרשתות, עם הסבר | | `invalid_input` | 400 | שדה חסר או בפורמט לא נכון | `rejected` היא השגיאה המעניינת. היא אומרת שהבדיקה של שַׁגֵּר מול כללי הרשת תפסה בעיה לפני השליחה. סוכן טוב מתקן לפי ההסבר ומנסה שוב. סוכן שמנסה שוב בלי לשנות כלום צריך הוראה מפורשת שלא לעשות את זה. ## מתי לבטל מפתח? מבטלים מיד כשמפתח הופיע בקובץ במאגר קוד, בצילום מסך, בשיחה ששותפה, או אצל עובד שעזב. מבטלים גם כשמחליפים כלי, למשל מחליפים את Claude Desktop בכלי Cursor, ואין סיבה שהמפתח הישן ימשיך לחיות. הביטול נעשה בדף ניהול הסוכנים, והוא מיידי: הקריאה הבאה עם המפתח תחזיר `unauthorized`. אם עוד לא חיברתם סוכן, [עמוד הסוכנים](/agents) מתחיל בהרשמה ובחיבור, ומשם המפתח הראשון שתיצרו יכול כבר להיות עם ההרשאות הנכונות. ## שאלות נפוצות ### האם שרת MCP של שַׁגֵּר תומך בהתחברות OAuth? עדיין לא. היום החיבור הוא עם מפתח בכותרת `Authorization: Bearer`. התחברות עם OAuth בדרך, ועד אז כלים שתומכים רק במחברים מבוססי OAuth צריכים לחכות, או לעבוד מול ממשק REST מתוך קוד. ### האם כמה סוכנים יכולים להשתמש באותו מפתח? טכנית כן, אבל אז מגבלת 120 הבקשות לדקה משותפת להם, והיומן לא יבדיל ביניהם. מפתח לכל סוכן עולה כלום ונותן יומן קריא. ### מי יכול ליצור מפתחות? רק אדם שמחובר לְשַׁגֵּר, בדף ניהול הסוכנים. סוכן לא יכול ליצור לעצמו מפתח נוסף או להרחיב את ההרשאות של המפתח שלו. הדרך היחידה של סוכן לקבל מפתח בלי אדם היא הרשמה עצמית, שמסתיימת בסנדבוקס מוגבל. --- Source: https://shager.ai/blog/api-keys-scopes-and-audit # MCP למשווקים: מה זה, למה זה חשוב לסוכנות ומה זה משנה בעבודה _2026-09-29 · MCP הוא תקן פתוח שמאפשר לסוכני AI להשתמש ישירות בכלים חיצוניים. הסבר בלי ז'רגון למשווקים: איך זה עובד, מה זה מאפשר לסוכנות, ואיך מחברים את שַׁגֵּר לסוכן שלכם היום._ MCP, או Model Context Protocol, הוא תקן פתוח שמגדיר איך סוכן AI מתחבר למערכות חיצוניות ומשתמש בהן. במקום שהמודל רק יכתוב טקסט ואתם תעתיקו אותו למערכת, הוא יכול לקרוא ישירות לפעולות של המערכת, כמו "צור פוסט" או "הבא לי נתוני לחיצות", ולקבל תשובה מסודרת. למשווק זה אומר דבר אחד: הסוכן מפסיק להיות עוזר כתיבה והופך למי שמבצע את העבודה בכלים שאתם כבר משתמשים בהם. אני כותב את זה למשווקים ולמנהלי סוכנויות, לא למפתחים. אין כאן קוד מעבר לשורה אחת של הגדרה, ואין צורך להבין JSON כדי להבין למה זה חשוב. ## מאיפה זה הגיע? אנתרופיק [הכריזה על MCP בנובמבר 2024](https://www.anthropic.com/news/model-context-protocol) כתקן פתוח לחיבור עוזרי AI למערכות שבהן נמצא המידע. הרעיון היה לפתור בעיה שכל מי שעבד עם מודלים הכיר: כל חיבור בין מודל לבין מערכת היה צריך להיבנות מחדש, בנפרד, לכל שילוב של מודל ומערכת. מאז נוספה תמיכה בתקן בהרבה כלים. Claude Code, Claude Desktop, Codex וגם Cursor תומכים בחיבור לשרתי MCP, כל אחד עם דרך הגדרה משלו. לכל אחד מהם כתבתי מדריך חיבור נפרד, למשל [המדריך לחיבור שַׁגֵּר אל Claude Code](/blog/connect-shager-to-claude-code). ## איך להסביר את זה ללקוח בשלושה משפטים הדימוי שעובד לי הכי טוב הוא שקע חשמל. לפני שהיה תקן, כל מכשיר היה צריך חיבור מיוחד לכל בית. אחרי שיש תקן, כל מכשיר שעומד בו עובד בכל שקע שעומד בו. MCP הוא השקע. מצד אחד יש "לקוחות", כלומר הכלים שבהם הסוכן רץ, כמו Claude Desktop. מצד שני יש "שרתים", כלומר המערכות שמציעות פעולות, כמו שַׁגֵּר. כל לקוח שתומך בתקן יכול לעבוד עם כל שרת שתומך בו. ## מה שרת MCP בעצם מציע לפי [המפרט הרשמי](https://modelcontextprotocol.io/specification/2025-06-18), שרת יכול להציע לסוכן שלושה סוגי דברים: כלים (פעולות שהסוכן יכול לבצע), משאבים (מידע שהוא יכול לקרוא) ופרומפטים (תבניות מוכנות). בעבודה של סוכנות, הכלים הם העיקר. כלי הוא פעולה עם שם, תיאור ורשימת פרמטרים. בְּשַׁגֵּר, למשל, יש כלי שנקרא `create_post`, והתיאור שלו מסביר לסוכן שהוא יוצר פוסט לכמה חשבונות, עם כיתוב, מדיה, קישור למדידה ואפשרות לניסוח שונה לכל חשבון. הסוכן קורא את התיאור, מבין מתי להשתמש בכלי, וממלא את הפרמטרים. הנה רשימת הכלים ששרת MCP של שַׁגֵּר חושף, בקבוצות: | קבוצה | כלים | למה זה משמש | |---|---|---| | זיהוי וסביבות | `whoami`, `list_workspaces`, `create_workspace` | לדעת מי אני ועל אילו לקוחות אני עובד | | חשבונות | `list_channels`, `create_connect_link`, `list_groups`, `create_group` | לראות ולארגן את החשבונות, ולשלוח ללקוח קישור חיבור | | מדיה ופוסטים | `upload_media_from_url`, `create_post`, `schedule_post`, `cancel_post` | להכין, לתזמן ולבטל | | אישור ומעקב | `request_approval`, `get_post`, `list_posts` | לשלוח לאישור לקוח ולבדוק מצב | | מדידה | `get_analytics` | לחיצות לכל חשבון ולכל פוסט | אותן פעולות בדיוק זמינות גם דרך REST API רגיל, עם [מפרט OpenAPI](https://app.shager.ai/api/v1/openapi.json). אין יכולת שקיימת רק באחד מהם. ## איך זה נראה בשיחה עם סוכן נניח שאתם עובדים עם Claude Desktop, וְשַׁגֵּר מחובר אליו. אתם כותבים: ```text תכין לי טיוטה של הסרטון הזה לכל הסניפים של "רשת הקפה", עם ניסוח שונה לכל סניף, וקישור להזמנה בתגובה הראשונה. אל תתזמן. תשלח לי לבדיקה. ``` הסוכן לא כותב לכם טקסט ומחכה. הוא קורא לכלי `list_workspaces` כדי למצוא את הלקוח, לכלי `list_channels` כדי לראות את הסניפים, לכלי `upload_media_from_url` כדי להעלות את הסרטון, ולבסוף לכלי `create_post` עם ניסוח שונה לכל סניף. בסוף הוא מחזיר לכם תשובה: נוצרה טיוטה, הנה המזהה, הנה הווריאציות. אתם פותחים את הממשק ובודקים. המפרט עצמו קובע שהאפליקציה צריכה לקבל את הסכמת המשתמש לפני שהיא מפעילה כלי, ולכן רוב הכלים יבקשו מכם אישור לפני כל קריאה, לפחות בהתחלה. זה נשמע מעייף, אבל זה בדיוק מה שצריך בשבועות הראשונים, כדי לראות מה הסוכן מנסה לעשות. ## איך שרת מרוחק עובד, ולמה זה משנה המפרט מגדיר [שתי דרכי תקשורת סטנדרטיות](https://modelcontextprotocol.io/specification/2025-06-18/basic/transports): stdio, שבה השרת רץ כתהליך על המחשב שלכם, וגם Streamable HTTP, שבה השרת רץ בענן ומקבל בקשות דרך האינטרנט. שַׁגֵּר משתמש בשרת מרוחק מסוג Streamable HTTP, בכתובת `https://app.shager.ai/api/mcp`. המשמעות המעשית למשווק: לא צריך להתקין שום דבר. מספיק להוסיף את הכתובת ומפתח API ללקוח שבו אתם עובדים. עם Claude Code, למשל, זו פקודה אחת, לפי [התיעוד הרשמי](https://code.claude.com/docs/en/mcp): ```bash claude mcp add --transport http shager https://app.shager.ai/api/mcp \ --header "Authorization: Bearer shgr_live_..." ``` ## ומה עם ChatGPT? היום החיבור לשרת של שַׁגֵּר נעשה עם מפתח API בכותרת הבקשה. כלים שתומכים רק בחיבור דרך OAuth, כמו המחברים המותאמים של ChatGPT, לא יכולים להתחבר כך. התחברות דרך OAuth לשרת MCP של שַׁגֵּר עוד בדרך. עד אז, אפשר לעבוד עם REST API מתוך קוד. פירטתי את האפשרויות ב[מאמר על שַׁגֵּר מול ChatGPT](/blog/shager-and-chatgpt). ## מה זה משנה בפועל בסוכנות שלושה דברים, לפי הסדר שבו הם מורגשים: 1. **פחות העתק והדבק.** הסוכן מבצע ישירות בכלי, ולכן נעלם שלב שלם של העברת טקסטים ממקום למקום. 2. **תהליכים שאפשר לחזור עליהם.** כשהסוכן עובד דרך כלים מוגדרים, אפשר לכתוב תהליך פעם אחת, למשל כסקיל, ולהריץ אותו כל שבוע עם אותן תוצאות. כתבתי על זה ב[מדריך לבניית סקיל של Claude לְשַׁגֵּר](/blog/build-a-claude-skill-for-shager). 3. **בקרה ברורה יותר.** כל קריאה של סוכן לְשַׁגֵּר נרשמת ביומן ביקורת, ולכל מפתח יש הרשאות מוגדרות: `read`, `write` וגם `publish`. אתם יודעים בדיוק מה הסוכן יכול לעשות ומה הוא עשה. ## איך סוכן מגלה את שַׁגֵּר מלכתחילה שאלה שעולה הרבה: איך סוכן יודע בכלל שיש שרת כזה, ואיך הוא לומד להשתמש בו? חלק מהתשובה הוא שאתם מחברים אותו. חלק אחר הוא שאתרים יכולים להיות קריאים לסוכנים. שַׁגֵּר מפרסם קובץ llms.txt, גרסאות Markdown של העמודים, כרטיס שרת MCP בכתובת קבועה וקובץ סקיל מוכן, כך שסוכן שמגיע לאתר יכול לקרוא איך מתחברים בלי שמישהו יסביר לו. סוכן יכול אפילו להירשם לבד ולקבל סביבת ניסוי, כמו שמתואר ב[מתכון ההרשמה לסוכנים](/auth.md). זה כיוון שאני מצפה שעוד מערכות יאמצו, כי סוכנים הולכים להיות חלק גדול מהמשתמשים של כלים עסקיים. ## על מה צריך להיזהר MCP הוא צינור, לא שיקול דעת. הוא מאפשר לסוכן לבצע פעולות, ולכן חשוב לתת לו רק את ההרשאות שהוא צריך. התחילו עם מפתח שיכול לקרוא וליצור טיוטות בלבד. הוסיפו הרשאת פרסום רק אחרי שראיתם שהתהליך עובד. ועוד דבר: התחברו רק לשרתים שאתם סומכים עליהם. המפרט עצמו מזהיר שתיאורי כלים משרת שאינו מהימן צריכים להיחשב לא אמינים, כי הם משפיעים על ההתנהגות של הסוכן. ## שאלות נפוצות ### האם צריך להיות מתכנת כדי לעבוד עם MCP? לא. בכלים כמו Claude Desktop או Claude Code ההגדרה היא כתובת שרת ומפתח, ומשם עובדים בשפה טבעית. מי שרוצה לבנות תהליכים קבועים ירוויח מהיכרות בסיסית עם סקילים, אבל זה לא תנאי. ### מה ההבדל בין MCP לבין API רגיל? API רגיל מיועד למפתחים שכותבים קוד שקורא לו. MCP מיועד לסוכנים: הוא מתאר את הכלים בצורה שמודל יכול להבין ולבחור בהם לבד. בְּשַׁגֵּר שניהם חושפים את אותן פעולות, כך שאפשר לבחור לפי מי שמפעיל. ### האם הסוכן יכול לפרסם לבד דרך MCP? רק אם המפתח שלו כולל הרשאת `publish`. סוכן שנרשם לבד מתחיל בארגז חול שבו הוא יכול רק להכין טיוטות, ואדם צריך לתבוע את הסביבה ולבחור אם לתת לו הרשאת פרסום. אם אתם רוצים לנסות, הדרך הקצרה היא [עמוד הסוכנים](/agents), שמרכז את כתובת השרת, את המפרט ואת קובץ הסקיל, וממנו אפשר לחבר את הלקוח שבו אתם כבר עובדים. --- Source: https://shager.ai/blog/mcp-explained-for-marketers # שגרת הפצה שבועית עם skill: כל יום ראשון בבוקר, טיוטות לכל הלקוחות מחכות לאישור _2026-09-29 · איך בונים skill עבור Claude Code שמריץ שגרת הפצה שבועית מול שַׁגֵּר: קריאת בריף, טיוטות לכל חשבון, שליחה לאישור, דוח לחיצות, והרצה אוטומטית עם claude -p וגם cron._ שגרת הפצה שבועית עם skill היא קובץ `SKILL.md` אחד בכלי Claude Code שמגדיר לסוכן מה לעשות כל שבוע: לקרוא את הבריף של הלקוח, לבדוק מה עבד בשבוע הקודם עם `get_analytics`, להכין טיוטות לכל החשבונות עם ניסוח שונה לכל אחד, ולשלוח אותן לאישור. מפעילים אותה ידנית עם `/shager-weekly` ושם הלקוח, או אוטומטית עם `claude -p` מתוך cron. התזמון בפועל נשאר אצל אדם, או אצל הסוכן רק אחרי אישור מפורש. המדריך ממשיך את המדריך [על בניית skill לְשַׁגֵּר](/blog/build-a-claude-skill-for-shager). שם בנינו skill כללי שמלמד את הסוכן להשתמש בְּשַׁגֵּר נכון. כאן אנחנו בונים skill צר יותר, עם משימה אחת שחוזרת כל שבוע. ## למה שגרה ולא בקשה חופשית? סוכנות שמנהלת עשרה לקוחות עם עשרות עמודים כל אחד לא צריכה סוכן יצירתי שממציא כל שבוע תהליך חדש. היא צריכה סוכן שעושה את אותו דבר באותו סדר, ומשאיר לאנשים את ההחלטות. כשהשגרה כתובה, קל לראות איפה היא נכשלה, קל לשפר אותה, וקל להסביר ללקוח מה קורה עם התוכן שלו כל שבוע. יש גם יתרון פחות צפוי: כשמנהלת תיק יוצאת לחופשה, מי שמחליף אותה לא צריך ללמוד שיטה אישית. הוא מריץ את אותה פקודה, על אותה תיקייה, ומקבל את אותה תוצאה. ## המבנה בריפו הנחת העבודה כאן היא ריפו אחד לכל התוכן של הסוכנות, עם תיקייה לכל לקוח: ```text content-ops/ ├── .mcp.json ├── .claude/ │ └── skills/ │ └── shager-weekly/ │ ├── SKILL.md │ └── assets/ │ └── weekly-report-template.md └── clients/ ├── acme/ │ ├── brand.md │ └── weeks/ │ └── 2026-w40.md └── dental-north/ ├── brand.md └── weeks/ ``` הקובץ `brand.md` מחזיק את מה שקבוע ללקוח, ומשתנה רק כשהלקוח משנה כיוון: טון, מילים אסורות, מזהה סביבת העבודה בְּשַׁגֵּר, קבוצות החשבונות ושם הסוקר אצל הלקוח. קובץ השבוע מחזיק את מה שמשתנה: מסרים, קישורים, מדיה, ימים מועדפים. מנהלת התיק כותבת אותו ביום חמישי, והסוכן עובד ממנו ביום ראשון. החיבור לְשַׁגֵּר מוגדר בקובץ `.mcp.json` עם משתנה סביבה, כמו שהסברנו במדריך [לחיבור שַׁגֵּר אל Claude Code](/blog/connect-shager-to-claude-code). ## קובץ SKILL.md ```markdown --- name: shager-weekly description: Weekly distribution routine for one client in Shager. Use when asked to run the weekly routine, prepare this week's posts, or "shager weekly" for a client. disable-model-invocation: true argument-hint: [client-folder] allowed-tools: Read Glob mcp__shager__whoami mcp__shager__list_workspaces mcp__shager__list_channels mcp__shager__list_groups mcp__shager__list_posts mcp__shager__get_post mcp__shager__get_analytics mcp__shager__upload_media_from_url mcp__shager__create_post mcp__shager__request_approval --- # Weekly routine for clients/$ARGUMENTS 1. Read clients/$ARGUMENTS/brand.md and the newest file in clients/$ARGUMENTS/weeks/. If there is no file for this week, stop and say so. 2. get_analytics for the last 7 days. Note the 3 accounts with the most clicks and the 3 with the fewest. 3. list_posts with status SCHEDULED to avoid double posting. 4. For every post in the week file: a. upload_media_from_url with width, height, duration_ms for video. b. create_post as a draft with group_ids from brand.md, per_channel with a different caption for every account, cta_url, first_comment, campaign and a label " ". 5. request_approval for each draft with the reviewer from brand.md. 6. Fill assets/weekly-report-template.md and print it. Never call schedule_post in this routine. ``` כמה בחירות שכדאי להסביר. `disable-model-invocation: true` אומר שהמודל Claude לא יטען את הסקיל (skill) לבד, רק כשמישהו מקליד `/shager-weekly`. זה שדה של Claude Code, ו[התיעוד על skills](https://code.claude.com/docs/en/skills) ממליץ עליו בדיוק לזרימות עם השפעות חיצוניות. החיסרון הוא שה skill הזה לא יתאים להעלאה לאתר claude.ai, שמקבל רק את שדות המפרט הפתוח. לשגרה שרצה מהטרמינל זה בסדר גמור. `$ARGUMENTS` מוחלף במה שכותבים אחרי שם הסקיל. `/shager-weekly acme` יריץ את השגרה על התיקייה `clients/acme`. `allowed-tools` מאשר מראש את הכלים שהשגרה צריכה, כך שהיא לא נעצרת לשאול על כל קריאה. שימו לב שהפעולה `schedule_post` לא ברשימה, וגם `cancel_post` לא. אם הסוכן ינסה להשתמש בהם, הוא ייעצר לבקש אישור, ובהרצה אוטומטית הבקשה פשוט תידחה. ### הגנה נוספת בצד של שַׁגֵּר הרשימה בשדה `allowed-tools` היא שכבה אחת. השכבה החזקה יותר היא המפתח. אם המפתח שהשגרה משתמשת בו נוצר בלי הרשאת `publish`, שום דבר בצד של Claude Code לא יוכל לתזמן פוסט, גם אם מישהו ישנה את הסקיל. בכתובת `https://app.shager.ai/dashboard/agents` יוצרים מפתח ייעודי לשגרה, ויומן הביקורת מראה בדיוק מה הוא עשה בכל הרצה. ## הרצה ידנית ביום ראשון הדרך הפשוטה ביותר: מנהלת התיק פותחת `claude` בריפו ומקלידה: ```text /shager-weekly acme ``` הסוכן קורא את הקבצים, בודק את השבוע הקודם, מכין טיוטות ושולח אותן לאישור. בסוף הוא מדפיס דוח קצר: כמה טיוטות נוצרו, לכמה חשבונות, אילו חשבונות הביאו הכי הרבה לחיצות בשבוע שעבר, ומה מחכה לאישור. הלקוח מקבל קישור אישור ומאשר בלי להתחבר לשום מערכת. התהליך מצד הלקוח מתואר במדריך [על תהליך אישור לקוחות בסוכנות](/blog/client-approval-workflow-for-agencies). ## הרצה אוטומטית עם `claude -p` כשהשגרה יציבה, אפשר להריץ אותה בלי אדם מול המסך. [התיעוד על הרצה לא אינטראקטיבית](https://code.claude.com/docs/en/headless) מסביר שמיומנויות (skills) שמופעלות ידנית עובדים גם במצב `-p`: כוללים את `/skill-name` בפרומפט, והכלי Claude Code מרחיב אותו לפני ההרצה. ```bash cd ~/content-ops && claude -p "/shager-weekly acme" \ --permission-mode dontAsk \ --output-format json > logs/acme-$(date +%Y-%m-%d).json ``` במצב `dontAsk`, כל פעולה שהייתה דורשת אישור נדחית, ורק מה שמאושר מראש רץ. זו בדיוק ההתנהגות שרוצים בהרצה ללא השגחה. מי שרוצה שכבת ביטחון נוספת יכול להעביר את אותה רשימת כלים גם בדגל `--allowedTools` של הפקודה, כך שההרשאות מוגדרות גם בסקריפט עצמו ולא רק בתוך הסקיל. כך, גם אם מישהו ישנה את הסקיל בטעות, הפקודה עדיין לא תאפשר יותר ממה שהגדרתם בה. את הפקודה מכניסים לתזמון cron, למשל כל יום ראשון בשבע בבוקר: ```text 0 7 * * 0 cd ~/content-ops && ./run-weekly.sh ``` עוד שתי הערות מהתיעוד. הראשונה: אל תשתמשו כאן בדגל `--bare`. מצב bare מדלג על skills ועל שרתי MCP מהקובץ `.mcp.json`, ואז השגרה לא תמצא לא את הסקיל ולא את שַׁגֵּר. השנייה: הרצת `-p` בתיקייה טוענת את ההגדרות ואת שרתי MCP שלה בלי לשאול. הריצו אותה רק בריפו שאתם שולטים בו. משתנה הסביבה עם המפתח של שַׁגֵּר צריך להיות זמין לתזמון cron, שבדרך כלל לא טוען את קובץ ההגדרות של המעטפת (shell) שלכם. את זה פותרים בסקריפט העוטף, שטוען את המשתנה מקובץ סודות לפני ההרצה. ## מה עושים ביום שני השגרה מכינה ושולחת לאישור. מה שקורה אחרי זה הוא החלטה שלכם. יש שתי גישות נפוצות: 1. **אדם מתזמן.** מנהלת התיק נכנסת לְשַׁגֵּר ביום שני, רואה מה אושר, ומתזמנת. זו הגישה הבטוחה, ומתאימה ללקוחות חדשים. 2. **skill שני מתזמן.** skill נפרד, למשל `/shager-schedule-approved`, שמריץ `list_posts` עם סטטוס `APPROVED` ומתזמן לפי הימים בקובץ השבוע. הוא רץ עם מפתח אחר, שיש לו `publish`, ואדם מפעיל אותו ידנית. הפרדה בין "הכנה" לבין "תזמון" לשני skills ושני מפתחות נראית כמו עבודה כפולה, אבל היא מה שמאפשר לישון בשקט. ואם יוצא שבוע עם חג, עדיף שאדם יעבור על התאריכים. לוח השנה של שַׁגֵּר מציג חגים ישראליים, וזה המקום הנוח לבדוק את זה. ## דוח השבוע התבנית `assets/weekly-report-template.md` היא מה שהופך את השגרה לשימושית גם ללקוח. היא יכולה להיות פשוטה: טבלה של חשבונות עם לחיצות בשבוע שעבר, שלושת הפוסטים המובילים, ומה מתוכנן לשבוע הבא. מכיוון שכל חשבון מקבל בְּשַׁגֵּר קישור מקוצר ותגיות UTM משלו, הנתונים ברמת החשבון זמינים בלי שום הגדרה נוספת. הצעד הבא הוא להרחיב מלקוח אחד לכמה. התחילו בלקוח אחד במשך שלושה שבועות, תקנו את הסקיל לפי מה שלא עבד, ורק אז הוסיפו שורה לתזמון cron לכל לקוח נוסף. את התמונה המלאה, מבריף ועד דוח, פרשנו ב[מדריך לצינור תוכן של סוכן מקצה לקצה](/blog/agent-content-pipeline-end-to-end). ## שאלות נפוצות ### אפשר להריץ את השגרה הזו באתר claude.ai במקום בכלי Claude Code? לא בצורה הזו. השדות `disable-model-invocation`, `allowed-tools` וגם `argument-hint` שייכים לכלי Claude Code, וההרצה האוטומטית עם `claude -p` ועם cron היא יכולת של הטרמינל. באתר claude.ai אפשר להעלות גרסה פשוטה יותר עם `name` וגם `description` בלבד ולהפעיל אותה בשיחה. ### מה קורה אם קובץ השבוע חסר? השלב הראשון במיומנות אומר לסוכן לעצור ולדווח. זה חשוב: סוכן שממציא תוכן כשאין בריף מייצר בדיוק את הפוסטים שאף לקוח לא רוצה לראות. ### כמה זמן לוקחת הרצה כזו? זה תלוי במספר הפוסטים ובכמות המדיה, ולא מדדנו מספר שאפשר להתחייב אליו. קריאה אחת לפעולה `create_post` עם `group_ids` מכסה עשרות חשבונות, כך שהצוואר בקבוק הוא בדרך כלל כתיבת הניסוחים ולא הקריאות לְשַׁגֵּר. --- Source: https://shager.ai/blog/skill-weekly-distribution-routine # איך למדוד לידים מכל חשבון בנפרד: UTM, קישורים מקוצרים ותגובה ראשונה _2026-09-26 · מדריך מעשי לשיוך לידים לכל עמוד וחשבון: מבנה UTM עקבי, קישור מקוצר לכל חשבון, תגובה ראשונה עם הקישור, והעברת הנתונים עד למערכת CRM._ סוכנות שמפרסמת את אותו קמפיין בארבעים עמודים מקבלת בסוף החודש שאלה אחת מהלקוח: "מאיפה הגיעו הלידים?". אם התשובה היא "מהרשתות החברתיות", היא לא שווה הרבה. הלקוח רוצה לדעת איזה סניף, איזה עמוד ואיזה פוסט הביאו פניות, כדי להחליט איפה להשקיע. התשובה הזו לא נבנית בדוח. היא נבנית בשלב שבו מכינים את הקישור, עוד לפני שהפוסט יוצא. המדריך הזה מסביר איך לבנות שיוך ברמת החשבון, משלב הקישור ועד הליד במערכת של הלקוח. ## למה "תנועה מפייסבוק" זה לא מספיק כלי אנליטיקס מזהים בדרך כלל שהגולש הגיע מפייסבוק או מאינסטגרם. הם לא יודעים מאיזה עמוד, כי מבחינתם כל העמודים הם אותו דומיין מפנה. בנוסף, חלק מהמעברים מאפליקציות מגיעים בלי מידע על המקור בכלל ונרשמים כתנועה ישירה. התוצאה: ארבעים עמודים, דוח אחד מאוחד, ואפס יכולת לומר לאיזה עמוד יש קהל שמתעניין באמת. כדי לפצל את זה צריך לסמן כל קישור לפני שהוא יוצא. ## שכבה ראשונה: UTM עקבי לכל חשבון פרמטרי UTM הם תוספות לכתובת שכלי אנליטיקס כמו Google Analytics קוראים ומשייכים לביקור. גוגל מתעדת את הפרמטרים הנתמכים ואת אופן השימוש בהם ב[מדריך הרשמי לאיסוף נתוני קמפיין](https://support.google.com/analytics/answer/10917952). ### מבנה מומלץ | פרמטר | מה לשים בו | דוגמה | |---|---|---| | utm_source | הרשת | facebook | | utm_medium | סוג התנועה | social | | utm_campaign | שם הקמפיין | spring-sale-2026 | | utm_content | מזהה החשבון | branch-haifa | הבחירה להשתמש בפרמטר utm_content לזיהוי החשבון היא החלטה מעשית: הפרמטרים source וגם medium נשארים נקיים ומאפשרים להשוות רשתות, campaign מאפשר להשוות קמפיינים, והפרמטר content מפצל לפי עמוד. יש סוכנויות שמעדיפות להכניס את מזהה החשבון לפרמטר utm_term או לשלב אותו בפרמטר campaign. זה פחות חשוב מאשר לבחור שיטה אחת ולהיצמד אליה. ### כללים שחוסכים דוחות שבורים 1. **אותיות קטנות בלבד, בלי רווחים.** הערכים רגישים לאותיות גדולות וקטנות, ולכן Facebook וגם facebook ייספרו כשני מקורות. 2. **מזהי חשבון באנגלית ובאופן קבוע.** לא "סניף חיפה" פעם אחת ואחר כך haifa פעם אחרת. 3. **רשימה מרכזית של מזהים.** טבלה אחת שמחזיקה את המזהה של כל חשבון, ושכולם עובדים ממנה. 4. **לא לבנות ידנית.** UTM שמקלידים ביד לכל פוסט יישבר תוך שבוע. הם צריכים להיווצר אוטומטית מתוך הגדרות החשבון. ## שכבה שנייה: קישור מקוצר לכל חשבון UTM לבד לא מספיק, משתי סיבות. הראשונה היא שהוא מודד רק את מה שכלי האנליטיקס רואה. גולשים שלא אישרו עוגיות, חוסמי פרסומות ודפדפנים עם הגנת פרטיות יכולים להעלים חלק מהביקורים. הנתון באנליטיקס הוא אינדיקציה, לא ספירה מלאה. השנייה היא שכתובת ארוכה עם ארבעה פרמטרים נראית רע בפוסט ומבריחה אנשים. קישור מקוצר ייעודי לכל חשבון פותר את שתיהן. כל לחיצה נספרת בשרת של שירות הקיצור לפני ההפניה, בלי תלות בעוגיות באתר, והקישור עצמו קצר ונקי. כשלכל חשבון יש קישור משלו, יש לכם ספירת לחיצות לכל עמוד גם אם האנליטיקס של הלקוח לא מוגדר כמו שצריך. ### מה לבדוק בשירות קישורים 1. האם הוא משמר את פרמטרי UTM ביעד הסופי 2. האם אפשר לייצר קישור לכל חשבון באופן אוטומטי ולא אחד אחד 3. האם הוא מסנן לחיצות של בוטים ותצוגות מקדימות של קישורים 4. מי הבעלים של הדומיין ושל הנתונים אם עוברים כלי ## שכבה שלישית: תגובה ראשונה עם הקישור בהרבה עמודים עסקיים נהוג לשים את הקישור בתגובה הראשונה ולא בגוף הפוסט, כך שהפוסט עצמו נקי והקריאה לפעולה מפנה לתגובה. זו החלטה של סגנון ושל ניסוי. אין מסמך רשמי של הרשתות שקובע שהיא משפרת חשיפה, וכדאי לבדוק מה עובד אצל הקהל שלכם. כמה דברים חשוב לדעת: 1. **באינסטגרם קישורים בכיתוב ובתגובות לא לחיצים.** לכן שם הקישור צריך לשבת בביו, בסטורי עם סטיקר קישור, או בכלי ייעודי. תגובה ראשונה עם קישור רלוונטית בעיקר לעמודי פייסבוק וליוטיוב. 2. **התגובה צריכה לצאת מיד אחרי הפוסט**, אחרת הגולשים הראשונים לא ימצאו את הקישור. 3. **גם בתגובה הראשונה, הקישור צריך להיות הקישור המקוצר של אותו חשבון** עם פרמטרי UTM שלו. אחרת כל הלידים מהתגובות יתערבבו. ## השלב שרוב הסוכנויות מפספסות: להעביר את המקור עד הליד לחיצות הן לא לידים. כדי לדעת כמה פניות הגיעו מכל חשבון, צריך שהמידע על המקור ייכנס לרשומת הליד עצמה. ### איך עושים את זה 1. **שדות נסתרים בטופס**: בדף הנחיתה מוסיפים שדות נסתרים בשם utm_source, utm_campaign, utm_content וכו', וממלאים אותם מתוך הכתובת. 2. **שמירה לאורך הביקור**: אם הגולש עובר בין כמה עמודים לפני שהוא ממלא טופס, הפרמטרים צריכים להישמר (למשל בעוגייה של צד ראשון, בכפוף למדיניות הפרטיות שלכם ולהסכמה הנדרשת). 3. **מיפוי במערכת CRM**: לוודא שהשדות מגיעים לשדות קבועים במערכת הלקוח ולא נבלעים בהערות. 4. **בדיקה ידנית**: למלא טופס מקישור של כל קבוצת חשבונות ולוודא שהליד נכנס עם המקור הנכון. ### ומה עם וואטסאפ וטלפון פניות שמגיעות בשיחה או בוואטסאפ לא עוברות טופס. אפשר לצמצם את הפער עם הודעה מוכנה מראש בקישור לוואטסאפ שכוללת קוד קצר של החשבון, או עם מספרי טלפון נפרדים לקמפיינים גדולים. זה לא מושלם, אבל זה עדיף על לנחש. ## איך נראה דוח שימושי ללקוח כשכל השכבות מחוברות, אפשר להציג ללקוח טבלה פשוטה: | חשבון | פוסטים | לחיצות (קישור מקוצר) | ביקורים (אנליטיקס) | לידים (CRM) | |---|---|---|---|---| | סניף חיפה | ... | ... | ... | ... | | סניף באר שבע | ... | ... | ... | ... | הפערים בין העמודות הם מידע בפני עצמו. הרבה לחיצות ומעט ביקורים מרמזים על בעיה בדף או בעוגיות. הרבה ביקורים ומעט לידים מרמזים על בעיה בהצעה או בטופס. ## צ'קליסט לפני השקת קמפיין מדיד 1. יש מוסכמת UTM כתובה וכל הצוות עובד לפיה 2. לכל חשבון יש מזהה קבוע באנגלית 3. הקישורים נוצרים אוטומטית לכל חשבון, לא ידנית 4. הקישור המקוצר משמר את פרמטרי UTM ביעד 5. התגובה הראשונה משתמשת בקישור של אותו חשבון 6. בדף הנחיתה יש שדות נסתרים שנכנסים למערכת CRM 7. נבדק ליד ניסיון אחד לפחות מכל קבוצת חשבונות 8. הוגדר מה עושים עם פניות בטלפון ובוואטסאפ ## לסיכום שיוך לידים ברמת החשבון הוא לא שאלה של כלי דוחות. הוא תוצאה של משמעת: מוסכמה אחת, קישורים שנוצרים אוטומטית, ומידע שעובר מהלחיצה ועד מערכת CRM. סוכנות שמחזיקה את זה יכולה להראות ללקוח בדיוק אילו עמודים מביאים עסקים, ולהפסיק להתווכח על תחושות. בְּשַׁגֵּר זה חלק מתהליך הפרסום עצמו: כל חשבון מקבל תגיות UTM משלו וקישור מקוצר של שַׁגֵּר באופן אוטומטי, הקישור יכול לצאת בתגובה הראשונה של הפוסט, והלחיצות נספרות לכל חשבון בנפרד כדי שתוכלו להשוות אותן ללידים שנכנסו. --- Source: https://shager.ai/blog/utm-per-account-lead-attribution # סוכן אחד, עשרים לקוחות: איך מפרידים בין לקוחות כשסוכן AI מנהל את ההפצה _2026-09-24 · איך סוכנות מפעילה סוכן AI אחד לכמה לקוחות בְּשַׁגֵּר בלי לערבב ביניהם: סביבת עבודה לכל לקוח, קבוצות חשבונות, אישור לקוח, הוראות לכל מותג ובקרה ביומן הפעולות._ סוכן אחד יכול לנהל הפצה לעשרים לקוחות, בתנאי שהגבול בין הלקוחות מוגדר במבנה ולא רק בזיכרון של השיחה. בְּשַׁגֵּר הגבול הזה הוא סביבת העבודה: כל לקוח הוא סביבת עבודה נפרדת, וכל ערוץ, פוסט וקישור שייכים לאחת בלבד. מה שנשאר לכם הוא לוודא שהסוכן תמיד יודע באיזו סביבת עבודה הוא נמצא, ושהוראות המותג של לקוח אחד לא דולפות לאחר. הטעות שאני רואה הכי הרבה היא לא טכנית. זו שיחה ארוכה אחת שבה הסוכן כתב בבוקר למסעדה ואחר הצהריים למשרד עורכי דין, וסגנון הפוסטים של המסעדה זלג לעורכי הדין. המאמר מסביר איך למנוע את זה. ## איך שַׁגֵּר מפריד בין לקוחות? היררכיה פשוטה: ארגון, ובתוכו סביבות עבודה. הארגון הוא הסוכנות. סביבת עבודה היא לקוח או מותג. בתוך כל סביבת עבודה יש חשבונות מחוברים, קבוצות חשבונות, פוסטים וקישורים מקוצרים. כמעט כל כלי של שַׁגֵּר מקבל `workspace_id` כפרמטר חובה, כך שאי אפשר ליצור פוסט "באוויר" בלי לציין לאיזה לקוח הוא שייך. | ישות | שייכת ל | כלי רלוונטי | |---|---|---| | סביבת עבודה | ארגון | `list_workspaces`, `create_workspace` | | חשבון מחובר | סביבת עבודה | `list_channels`, `create_connect_link` | | קבוצת חשבונות | סביבת עבודה | `list_groups`, `create_group` | | מדיה ופוסטים | סביבת עבודה | `upload_media_from_url`, `create_post` | | לחיצות | סביבת עבודה | `get_analytics` | מפתח API שייך לארגון, ולכן סוכן עם מפתח אחד רואה את כל סביבות העבודה של הסוכנות. זה מה שמאפשר לו לעבוד עם כולן, וזה גם מה שמחייב משמעת. ## הקמת לקוח חדש בידי הסוכן ```json create_workspace { "name": "משרד עו\"ד לוי ושות'", "timezone": "Asia/Jerusalem", "approval_required": true } ``` `approval_required` קובע אם פוסטים בסביבת העבודה הזו צריכים אישור לקוח לפני תזמון. לסוכנים ברירת המחדל היא `false`, ולכן ללקוח שרוצה לראות כל פוסט צריך להגדיר את זה במפורש. אני מגדיר `true` לכל לקוח חדש בחודש הראשון, גם אם הוא אומר שהוא סומך עלינו. אחרי שסביבת העבודה קיימת, הסוכן יוצר קישור חיבור עם `create_connect_link` ושולח אותו ללקוח. הלקוח פותח אותו, מתחבר לפייסבוק, לאינסטגרם או ליוטיוב ובוחר את החשבונות, בלי חשבון בְּשַׁגֵּר ובלי למסור סיסמה. ההסבר המלא ב[מאמר על קישורי חיבור ללקוח](/blog/client-connect-links). שימו לב שקישורי חיבור ובקשות אישור לא זמינים בסנדבוקס שעוד לא נתבע, ולפי [עמוד המחירים](/pricing) הם נכללים בחבילת Agency ומעלה. ## חמישה כללים שמונעים ערבוב בין לקוחות 1. **שיחה לכל לקוח.** זה הכלל הכי פשוט והכי אפקטיבי. כשהשיחה מתחילה, הסוכן קורא את קובץ ההנחיות של הלקוח ועובד רק בסביבת העבודה שלו. כשעוברים ללקוח אחר, פותחים שיחה חדשה. 2. **בדיקת סביבת עבודה לפני כל כתיבה.** ההוראות הקבועות של הסוכן מחייבות אותו לציין את שם סביבת העבודה בכל פעולה שיוצרת משהו, ולהשוות אותו לשם הלקוח בבריף. 3. **קובץ הנחיות לכל לקוח.** קול המותג, מילים אסורות, מתחרים שלא מזכירים, ימים שלא מפרסמים. הקובץ יושב בתיקייה של הלקוח, לא בהוראות הכלליות. 4. **אין העתקה בין לקוחות.** הסוכן לא משתמש בכיתוב, בתמונה או בקישור שנוצרו ללקוח אחד בעבודה של לקוח אחר, גם אם הנושא דומה. 5. **בדיקה אחרי פעולה.** אחרי `create_post`, הסוכן מריץ `get_post` ומוודא שרשימת החשבונות שייכת ללקוח הנכון. ## איך נראה מבנה התיקיות בסוכנות שעובדת עם Claude Code או עם כלי דומה, מבנה כזה עובד טוב: ```text clients/ levi-law/ brief.md # קול המותג, קהל, מה מותר ומה אסור workspace.txt # שם סביבת העבודה בשגר, בדיוק כפי שהוא calendar.md # ימים ושעות לפרסום, חגים, אירועים cafe-alma/ brief.md workspace.txt calendar.md ``` וההוראה בתחילת כל שיחה: ```text אנחנו עובדים היום על הלקוח בתיקייה clients/levi-law. 1. קרא את brief.md, את workspace.txt ואת calendar.md. 2. הרץ list_workspaces ומצא את סביבת העבודה ששמה זהה לתוכן של workspace.txt. אם אין התאמה מדויקת, עצור ושאל. 3. מכאן והלאה השתמש רק במזהה workspace_id הזה. אם בקשה שלי נראית כאילו היא שייכת ללקוח אחר, שאל לפני שאתה מבצע. ``` ## קבוצות חשבונות בתוך לקוח לקוח עם ארבעים סניפים לא מפרסם תמיד לכולם. קבוצות חשבונות פותרות את זה: `create_group` עם `name` ו`channel_ids`, ואחר כך `create_post` עם `group_ids` במקום רשימה ארוכה של ערוצים. כל ערוץ פעיל בקבוצה נכלל בפוסט. ```json create_group { "workspace_id": "ws_cafe_alma", "name": "סניפי צפון", "channel_ids": ["ch_fb_haifa", "ch_fb_karmiel", "ch_ig_haifa", "ch_fb_nahariya"] } ``` הקבוצות שימושיות גם לסוכן. במקום לזכור אילו עמודים שייכים לצפון, הוא קורא ל`list_groups` ומקבל את המבנה כפי שהסוכנות הגדירה אותו. מבחינת עקביות המותג בין עשרות חשבונות, יש עוד על הנושא ב[מאמר על קול מותג אחיד](/blog/brand-consistency-across-many-accounts). ## בקרה: מי עשה מה מפתח אחד לכל הסוכנים זה נוח, אבל כשמשהו משתבש צריך לדעת איזה תהליך עשה את זה. ההמלצה שלי היא מפתח נפרד לכל סוכן או לכל תהליך: אחד לסוכן התוכן, אחד לסוכן הדוחות עם `read` בלבד, ואחד לסקריפטים. בדף [ניהול הסוכנים](https://app.shager.ai/dashboard/agents) רואים יומן של כל קריאה, וכשלכל מפתח יש שם ברור, היומן קריא. הפירוט ב[מאמר על הרשאות ויומן פעולות](/blog/api-keys-scopes-and-audit). ## כמה לקוחות סוכן אחד יכול להחזיק? המגבלה הטכנית היא 120 בקשות לדקה למפתח, וזה הרבה יותר ממה שסוכן תוכן צריך. המגבלה האמיתית היא תשומת הלב של האדם שבודק. סוכן מייצר טיוטות מהר יותר ממה שמישהו בסוכנות יכול לקרוא. לכן צוואר הבקבוק עובר מכתיבה לבדיקה, וכדאי לתכנן את זה מראש: מי בודק, מתי, ובאיזה פורמט הסוכן מגיש. על החלוקה הזו בתוך הסוכנות כתבתי ב[מודל העבודה של סוכנות עם סוכנים](/blog/agency-operating-model-with-agents). התמחור של שַׁגֵּר לפי מספר החשבונות המחוברים, לא לפי מספר המשתמשים או הסוכנים. גישת API וגישת MCP כלולות בכל חבילה, כך שסוכן נוסף לא עולה כסף. הוא עולה זמן בדיקה. ## מאיפה מתחילים קחו שני לקוחות, לא עשרים. הקימו לכל אחד תיקייה עם brief.md, הריצו את הסוכן שבועיים בשיחות נפרדות, ובדקו את היומן בסוף כל שבוע. שימו לב במיוחד לשתי שאלות: האם כל פעולה נעשתה בסביבת העבודה הנכונה, והאם היו בקשות שהסוכן עצר בהן ושאל. אם לא היה ערבוב, והסוכן עצר בדיוק במקומות שהגדרתם, מוסיפים לקוחות בהדרגה, שניים או שלושה בכל פעם. ההנחיות להתחברות נמצאות ב[עמוד הסוכנים](/agents). ## שאלות נפוצות ### אפשר להגביל מפתח לסביבת עבודה אחת? מפתחות בְּשַׁגֵּר מוגדרים לפי הרשאות `read`, `write` ו`publish`, והם שייכים לארגון. ההפרדה בין לקוחות נשענת היום על `workspace_id` בכל קריאה ועל ההוראות של הסוכן. לכן כללי העבודה שלמעלה חשובים. ### מה קורה אם הסוכן יוצר פוסט בסביבת העבודה הלא נכונה? הפוסט נוצר בסביבת העבודה שצוינה, עם החשבונות שלה בלבד. אם זו טיוטה, אין נזק מול הרשתות. זו בדיוק הסיבה לעבוד עם טיוטות ונקודות עצירה, ולא לתזמן ישר. ### הלקוח יכול לראות את הפוסטים של לקוחות אחרים? לא. לקוח שמקבל קישור אישור רואה רק את הפוסט שנשלח אליו, בלי להתחבר לְשַׁגֵּר. לקוח שמחבר חשבונות דרך קישור חיבור לא מקבל גישה לְשַׁגֵּר בכלל. --- Source: https://shager.ai/blog/one-agent-many-clients # שמירה על קול מותג אחיד כשמפרסמים בעשרות חשבונות _2026-09-22 · איך סוכנות שמנהלת עשרות עמודים וחשבונות שומרת על קול מותג אחד בלי לשכפל טקסטים: מדריך סגנון, תבניות, שכבות התאמה ובקרת איכות._ כשמנהלים חשבון אחד, קול המותג חי בראש של מי שכותב. כשמנהלים שלושים סניפים, עשרים זכיינים או חמישים עמודים של מותגים שונים באותה קבוצה, הוא כבר לא יכול לחיות רק שם. כל אחד מהכותבים בצוות מביא את הסגנון שלו, כל לקוח מבקש "רק עוד תיקון קטן", ותוך כמה חודשים העמודים נשמעים כמו חמישה עסקים שונים. הפתרון הנפוץ, להעתיק את אותו פוסט לכל החשבונות, יוצר בעיה אחרת: תוכן זהה בעשרות עמודים נראה רע לקהל ופוגע בהפצה. המטרה היא לא טקסט אחיד, אלא **קול** אחיד. המאמר הזה עוסק בהבדל בין השניים ובאיך לבנות תהליך שמחזיק אותו לאורך זמן. ## קול מותג הוא לא תבנית טקסט קול מותג הוא אוסף של החלטות: איך פונים לקהל, באיזו רמת רשמיות, אילו מילים משתמשים ואילו לא, כמה הומור מותר, איך נשמעת קריאה לפעולה. שני פוסטים יכולים להיות שונים לגמרי במילים ועדיין להישמע כמו אותו מותג. ולהפך, שני פוסטים כמעט זהים יכולים להישמע זרים זה לזה אם אחד מהם נכתב ברגע של לחץ. לכן כדאי להפריד בין שלוש שכבות: 1. **הקול**: קבוע ברמת המותג. לא משתנה בין חשבונות. 2. **המסר**: קבוע ברמת הקמפיין. אותו מבצע, אותו יתרון מרכזי, אותה הצעה. 3. **הניסוח**: משתנה לפי חשבון, רשת וקהל. כאן נכנסים שם העיר, שם הסניף, פרט מקומי או זווית אחרת. כשהשכבות האלה ברורות לכל הצוות, אפשר לייצר וריאציות בלי לאבד את הזהות. ## מדריך סגנון שאנשים באמת משתמשים בו רוב מדריכי המותג נכתבים פעם אחת, נשמרים כקובץ PDF ונשכחים. מדריך שימושי לסוכנות שמפרסמת בהיקף צריך להיות קצר, מעשי ונגיש בזמן הכתיבה עצמה. ### מה חייב להופיע בו 1. **פנייה**: גוף שני או שלישי? יחיד, רבים, או ניסוח שמתאים לכולם? בעברית זו החלטה מהותית, ושווה להחליט עליה מראש. ניסוחים כמו "מי שמחפש/ת", "אפשר להירשם" או "הצטרפו" עוקפים את הבעיה ברוב המקרים. 2. **רמת רשמיות**: דוגמה אחת של משפט "נכון" ואחת של משפט "לא שלנו" שווה יותר מעמוד של תיאורים. 3. **מילים אסורות ומילים מועדפות**: למשל "לקוחות" ולא "צרכנים", "מחיר" ולא "תמחור אטרקטיבי". 4. **אורך ומבנה**: כמה שורות לפני הקריאה לפעולה, האם משתמשים ברשימות, האם יש אימוג'י ובאיזה היקף. 5. **קריאות לפעולה מאושרות**: רשימה סגורה של שלושה עד חמישה ניסוחים. זה המקום שבו מותגים הכי מתפזרים. 6. **מה אסור להבטיח**: מחירים, תוצאות, ניסוחים שהלקוח או הרגולציה בתחום שלו לא מאפשרים. ### איפה הוא צריך לחיות לא בתיקייה משותפת. הוא צריך להיות זמין במקום שבו כותבים את הפוסט: בהערה קבועה בכלי התזמון, בתבנית, או כהנחיה לעוזר הכתיבה. מדריך שצריך לחפש, לא ייקרא. ## תבניות עם משתנים, לא העתק והדבק כשאותו קמפיין יוצא לעשרות חשבונות, תבנית עם משתנים היא הכלי שמאזן בין אחידות לגיוון. במקום טקסט אחד, כותבים מבנה קבוע ומשאירים מקומות להתאמה: > פתיחה על הבעיה של הקהל → היתרון המרכזי של הקמפיין → פרט מקומי (עיר, סניף, שם המנהל/ת) → קריאה לפעולה מתוך הרשימה המאושרת כך כל פוסט שונה מספיק כדי לא להיראות כמו שכפול, אבל המבנה והטון זהים. כדאי גם להכין שתיים או שלוש פתיחות חלופיות לכל קמפיין ולפזר אותן בין החשבונות. ### מה לא כדאי לעשות 1. להחליף רק את שם העיר ולהשאיר את כל השאר זהה. זה עדיין שכפול. 2. לתת לכל כותב/ת "לשפר" את התבנית בחופשיות. השיפורים האלה מצטברים לסטייה. 3. לבנות תבנית אחת לכל הרשתות. מה שעובד בעמוד פייסבוק לא בהכרח מתאים לכיתוב של סרטון באינסטגרם או לתיאור ביוטיוב. ## קבוצות חשבונות לפי קהל, לא לפי לקוח סוכנויות נוטות לארגן חשבונות לפי לקוח. זה הגיוני לחיוב ולדיווח, אבל לא תמיד לכתיבה. לקוח עם עשרים סניפים יכול לכלול סניפים בערים שונות עם קהלים שונים מאוד, ולפעמים צריך גוון אחר לכל אחד. כדאי לבנות קבוצות חשבונות לפי מה שמשפיע על הניסוח: אזור, סוג קהל, שפה או רשת. כך אפשר לכתוב וריאציה אחת לקבוצה ולא אחת לכל חשבון, ולשמור על עקביות בתוך כל קבוצה. ## עוזר כתיבה כשומר סף, לא כמחליף כלי כתיבה מבוססי בינה מלאכותית יכולים לעזור מאוד בהיקף, בעיקר ביצירת וריאציות ובהתאמה לרשתות שונות. אבל בלי הנחיות ברורות הם נוטים לסגנון גנרי שנשמע אותו דבר אצל כל המותגים. כמה כללים שעובדים: 1. **הזינו את מדריך הסגנון כהנחיה קבועה**, כולל דוגמאות טובות ורעות. 2. **בקשו וריאציות של פוסט שכבר אושר**, לא פוסט חדש מאפס. כך המסר נשמר והניסוח משתנה. 3. **בדקו עברית**: התאמה במין ובמספר, פנייה עקבית, ומילים שנשמעות מתורגמות. זה המקום שבו טקסט אוטומטי בעברית נחשף הכי מהר. 4. **אל תפרסמו בלי עין אנושית**, לפחות בפוסט הראשון של כל קמפיין. ## בקרת איכות שלא תוקעת את העבודה בהיקף גדול אי אפשר לבדוק כל פוסט באותה רמת עומק. אפשר לבנות בקרה בשכבות: | שלב | מה בודקים | מי | |---|---|---| | תבנית הקמפיין | מסר, טון, קריאה לפעולה, הבטחות | אחראי/ת מותג או הלקוח | | וריאציות | התאמה לקבוצה, עברית תקינה, אין שכפול מלא | כותב/ת בכיר/ה | | דגימה לפני שליחה | 3 עד 5 פוסטים אקראיים מכל קבוצה | מי שמתזמן | | אחרי פרסום | תגובות חריגות, טעויות, קישורים שבורים | מנהל/ת קהילה או לקוח | המפתח הוא שהלקוח מאשר את התבנית ואת הכיוון, ולא כל אחת מחמישים הווריאציות. זה חוסך זמן ושומר על אחידות במקום שבו היא הכי חשובה. ## צ'קליסט לפני שמשגרים קמפיין לעשרות חשבונות 1. יש מדריך סגנון קצר וזמין בכלי שבו כותבים 2. המסר והקריאה לפעולה אושרו ברמת הקמפיין 3. יש לפחות שתי פתיחות שונות ושלושה ניסוחים לגוף הפוסט 4. החשבונות מחולקים לקבוצות לפי קהל או אזור 5. הפרטים המקומיים (עיר, סניף, טלפון) נבדקו מול מקור אמין 6. הכיתוב הותאם לכל רשת בנפרד 7. נדגמו פוסטים מכל קבוצה לפני התזמון 8. יש מישהו/י שאחראי/ת לעקוב אחרי תגובות ביום הפרסום ## לסיכום קול מותג אחיד בעשרות חשבונות לא נשען על כתיבה של אותו טקסט שוב ושוב. הוא נשען על החלטות ברורות שמתועדות במקום הנכון, על תבניות שמשאירות מקום לגיוון, ועל בקרה שממוקדת במה שבאמת חשוב. סוכנות שמשקיעה בזה פעם אחת חוסכת שעות של תיקונים בכל קמפיין. שַׁגֵּר נבנה בדיוק לעבודה הזו: קבוצות חשבונות שמאפשרות לכתוב וריאציה אחת לכל קהל, עוזר כתיבה בעברית שעובד לפי ההנחיות שלכם, וקישורי אישור ללקוח שבהם הוא רואה את הקמפיין לפני שהוא יוצא לכל החשבונות. --- Source: https://shager.ai/blog/brand-consistency-across-many-accounts # איך בונים skill של Claude לעבודה עם שַׁגֵּר: SKILL.md אחד שמלמד את הסוכן להפיץ נכון _2026-09-22 · מדריך לבניית Agent Skill לְשַׁגֵּר: מבנה התיקייה, השדות name וגם description בקובץ SKILL.md, איפה הוא יושב בכלי Claude Code ובאתר claude.ai, ומה לכתוב בו כדי שיעבוד נכון._ skill של Claude לְשַׁגֵּר הוא תיקייה עם קובץ `SKILL.md`, שבראשו frontmatter עם `name` וגם `description`, ובגוף שלו הנחיות: באיזה סדר להפעיל את הכלים של שַׁגֵּר, איך לנסח כיתוב שונה לכל חשבון, ומתי לעצור ולחכות לאדם. בכלי Claude Code שמים את התיקייה בנתיב `~/.claude/skills/` לשימוש אישי או בנתיב `.claude/skills/` בתוך הריפו לשימוש הצוות. באתר claude.ai מעלים אותה כקובץ ZIP. הסקיל לא מחליף את החיבור לְשַׁגֵּר. הוא יושב מעליו ומלמד את הסוכן להשתמש בו כמו שאתם הייתם משתמשים. למה זה משנה? כי חיבור MCP נותן לסוכן כלים, לא שיקול דעת. בלי skill, תצטרכו להסביר בכל שיחה מחדש, ולכל חבר צוות בנפרד, שכל עמוד מקבל ניסוח אחר, שהקישור הולך לתגובה הראשונה, ושאסור לתזמן בלי אישור. עם skill, ההסבר נכתב פעם אחת ונטען אוטומטית כשהבקשה מתאימה. ## איך בנוי skill? לפי [מדריך יצירת skills של Anthropic](https://claude.com/docs/skills/how-to), skill הוא תיקייה ששמה זהה לשם של הסקיל עצמו, והקובץ היחיד שחובה בה הוא `SKILL.md`. כל השאר אופציונלי: ```text shager-distribution/ ├── SKILL.md ├── references/ │ └── caption-rules-he.md └── assets/ └── post-brief-template.md ``` בתיקייה `references/` שמים מסמכים ארוכים שהסוכן קורא רק כשצריך, למשל כללי טון בעברית לכל לקוח. בתיקייה `assets/` שמים תבניות שהוא ממלא. את `SKILL.md` כדאי להשאיר מתחת לגבול של 500 שורות, וזו גם ההמלצה הרשמית. ### מה מותר בשדות name וגם description? [סקירת Agent Skills בתיעוד של Anthropic](https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview) מגדירה את הכללים: | שדה | כללים | |---|---| | `name` | עד 64 תווים, רק אותיות קטנות באנגלית, ספרות ומקפים. בלי המילים השמורות anthropic וגם claude. חייב להתאים לשם התיקייה | | `description` | לא ריק, עד 1,024 תווים. חייב להגיד גם מה הסקיל עושה וגם מתי להשתמש בו | הכלל על המילים השמורות הוא הסיבה שהסקיל שלנו נקרא `shager-distribution` ולא משהו עם claude בשם. שדה description הוא החלק החשוב ביותר: זה הדבר היחיד שהמודל Claude קורא לפני שהוא מחליט לטעון את הסקיל. אם הוא לא מזכיר את המילים שאנשים באמת כותבים, כמו "להפיץ", "לתזמן", "עמודים", "ריל", הסקיל פשוט לא ייטען. ## SKILL.md מלא לְשַׁגֵּר הנה גרסה שאפשר להתחיל ממנה. ההנחיות באנגלית כי זו השפה שבה רוב הצוותים כותבים הנחיות לסוכן, והתוכן עצמו ייכתב בעברית לפי הכללים בקובץ ההפניה: ```markdown --- name: shager-distribution description: Distribute posts, Reels and Shorts to many Facebook Pages, Instagram accounts and YouTube channels through Shager. Use when the user asks to publish, schedule, distribute or prepare drafts for several client accounts, or asks for clicks per account. --- # Distributing content with Shager Shager is connected as the MCP server "shager" (https://app.shager.ai/api/mcp). ## Order of work 1. whoami, then list_workspaces. Confirm the client workspace by name. 2. list_channels and list_groups. Prefer group_ids over long channel lists. 3. If no channels: create_connect_link and give the link to the human. 4. upload_media_from_url. For video always pass width, height, duration_ms. 5. create_post as a DRAFT: - per_channel with a different caption for every account - cta_url for the landing page, first_comment inviting the click - campaign for utm_campaign, label for an internal name 6. Show the human a short table: account, first line of caption, format. 7. Only after explicit approval: request_approval or schedule_post. ## Rules - Never schedule or publish without an explicit instruction in this chat. - schedule_at is ISO 8601 with offset, e.g. 2026-10-20T09:00:00+03:00. - Keep stagger_seconds at the default [30, 90] unless told otherwise. - On error code sandbox_unclaimed: stop and ask the human to claim. - On error code rejected: read the message, fix, retry once. - Hebrew captions follow references/caption-rules-he.md. ``` שימו לב למה שאין בקובץ: מפתח API. התיעוד של Anthropic אומר במפורש לא לשים מפתחות או סיסמאות בשום מקום בתוך הסקיל, כי כל מי שמקבל את הסקיל מקבל את כל הקבצים שלו. ההרשאה מגיעה מהחיבור לְשַׁגֵּר, והסקיל רק מסביר איך להשתמש בו. ### קובץ ההפניה לעברית `references/caption-rules-he.md` הוא המקום לדברים שמשתנים מלקוח ללקוח: פנייה בלשון רבים או ביחיד, האם מותר סלנג, מה עושים עם מגדר, אורך מקסימלי לפתיח, ואיך משלבים את שם העיר בכל סניף. ככל שהקובץ ספציפי יותר, הטיוטות טובות יותר. דוגמה אחת של פוסט טוב ודוגמה אחת של פוסט שנפסל, עם הסבר קצר למה, שוות יותר מעמוד שלם של עקרונות כלליים. על הנושא הזה בהרחבה כתבנו ב[מדריך על גיוון כיתובים לכל חשבון עם AI](/blog/caption-variation-per-account-with-ai). ## איפה הסקיל יושב בכל כלי | סביבה | מיקום | מי רואה אותו | |---|---|---| | Claude Code, אישי | `~/.claude/skills/shager-distribution/SKILL.md` | אתם, בכל פרויקט | | Claude Code, פרויקט | `.claude/skills/shager-distribution/SKILL.md` | כל מי שעובד בריפו | | claude.ai ואפליקציית Desktop | העלאה כקובץ ZIP והפעלה תחת Customize ואז Skills | המשתמש שהעלה | בכלי Claude Code, לפי [התיעוד על skills](https://code.claude.com/docs/en/skills), אפשר להפעיל skill ידנית עם `/shager-distribution`, או לתת למודל Claude לטעון אותו לבד כשהבקשה מתאימה לשדה description. באתר claude.ai צריך לארוז נכון. קובץ ZIP חייב להכיל את התיקייה עצמה ברמה העליונה, כלומר `shager-distribution/SKILL.md` בתוך הארכיון, ולא `SKILL.md` לבד. הפקודה הנכונה, מתוך התיקייה שמכילה את הסקיל: ```bash zip -r shager-distribution.zip shager-distribution/ unzip -l shager-distribution.zip ``` יש גם אפשרות להעלות skills דרך ממשק Skills API של Anthropic, אבל שם הם רצים בסביבה בלי גישה לרשת, ולכן לרוב זה פחות רלוונטי לעבודה מול שַׁגֵּר. הסקילים לא מסתנכרנים בין הסביבות. skill שהעליתם לאתר claude.ai לא יופיע בכלי Claude Code, ולהפך. ובנוסף, כדי שהסקיל יעבוד באתר claude.ai, צריך שגם שַׁגֵּר יהיה מחובר שם כמחבר, עם כל המגבלות שתיארנו במדריך [על Claude Desktop](/blog/connect-shager-to-claude-desktop). ### שדה שעובד רק בכלי Claude Code לכלי Claude Code יש שדות frontmatter נוספים מעבר למפרט הפתוח. השימושי ביותר כאן הוא `disable-model-invocation: true`, שמונע מהמודל Claude לטעון את הסקיל לבד ומשאיר אותו רק להפעלה ידנית. זה מתאים לסקיל שמתזמן פוסטים בפועל. אבל לפי התיעוד, באתר claude.ai ובממשק Skills API מותרים רק שדות המפרט, ושדה לא מוכר יגרום לשגיאה בהעלאה. אם אתם רוצים skill אחד לשתי הסביבות, השאירו רק `name` וגם `description`. ## איך בודקים שה skill עובד שלושה מבחנים פשוטים: 1. **האם הוא נטען?** כותבים בקשה רגילה, למשל "תכין לי טיוטת ריל לסניפים בצפון על מבצע הסתיו", ובודקים שהסוכן פועל לפי סדר העבודה. אם לא, משפרים את שדה description עם המילים שהשתמשתם בהן. 2. **האם הוא עוצר?** מבקשים "תפרסם את זה" בלי לציין זמן ובלי אישור מפורש, ובודקים שהסוכן שואל לפני שהוא מתזמן. 3. **האם הניסוח באמת שונה?** פותחים את הטיוטה בְּשַׁגֵּר ומשווים שלושה חשבונות. אם הם נבדלים רק בשם העיר, צריך לחדד את קובץ ההפניה. Anthropic מציעה גם skill בשם `skill-creator` שמריץ את הסקיל שלכם על בקשות בדיקה ומשווה תוצאות עם ובלי, וזה שימושי כשרוצים לדעת אם שינוי בשדה description באמת עזר. ## נקודת התחלה מוכנה אם לא רוצים להתחיל מאפס, לְשַׁגֵּר יש skill רשמי בכתובת `https://shager.ai/skills/shager/SKILL.md`. הוא קצר, מכסה את סדר הפעולות ואת כללי הבטיחות הבסיסיים, ואפשר להעתיק אותו ולהוסיף מעליו את הכללים של הסוכנות שלכם. את כל דרכי הגישה לְשַׁגֵּר, כולל קובץ הסקיל, תמצאו גם ב[עמוד הסוכנים](/agents). הצעד הבא אחרי skill שעובד הוא להפוך אותו לשגרה: skill שרץ כל שבוע, מכין את כל הטיוטות של השבוע ושולח לאישור. את זה בדיוק בנינו במדריך [על שגרת הפצה שבועית עם skill](/blog/skill-weekly-distribution-routine). ## שאלות נפוצות ### מה ההבדל בין skill לבין חיבור MCP? חיבור MCP נותן לסוכן גישה לכלים של שַׁגֵּר: ליצור פוסט, להעלות מדיה, למשוך אנליטיקס. הסקיל הוא ההנחיות לגבי איך ומתי להשתמש בכלים האלה. צריך את שניהם, והם משלימים זה את זה. ### אפשר לשתף skill עם כל הצוות? בכלי Claude Code כן, על ידי שמירתו בנתיב `.claude/skills/` בתוך ריפו משותף. באתר claude.ai skills מותאמים הם אישיים, וכל אחד מעלה אותם בעצמו, אלא אם יש לכם אפשרויות שיתוף בתוכנית Team או Enterprise. ### למה הסקיל שלי לא נטען אוטומטית? כמעט תמיד בגלל שדה description. Claude מחליט לפי הטקסט הזה בלבד, ולכן הוא חייב לכלול גם מה הסקיל עושה וגם את המילים שאנשים באמת משתמשים בהן כשהם מבקשים את המשימה. נסו לשכתב אותו ובדקו שוב. --- Source: https://shager.ai/blog/build-a-claude-skill-for-shager # קישורי חיבור ללקוחות: איך מחברים עשרות חשבונות בלי לבקש אף סיסמה _2026-09-22 · קישור חיבור מאפשר ללקוח לחבר את פייסבוק, אינסטגרם או יוטיוב שלו בעצמו, בלי חשבון בְּשַׁגֵּר ובלי למסור לאף אחד סיסמה. כך זה עובד, ואיך סוכן AI מנהל את כל התהליך._ קישור חיבור הוא קישור שהסוכנות שולחת ללקוח, והלקוח פותח אותו, מתחבר לפייסבוק, לאינסטגרם או ליוטיוב בעצמו ובוחר אילו חשבונות לחבר. הלקוח לא צריך לפתוח חשבון בְּשַׁגֵּר ולא מוסר לאף אחד סיסמה. אחרי שהוא סיים, החשבונות מופיעים בסביבת העבודה של הלקוח בְּשַׁגֵּר, והסוכנות או הסוכן שלה יכולים להתחיל לעבוד. בסוכנות שמנהלת עשרות לקוחות, קליטה של לקוח חדש היא לרוב הצעד הכי איטי בכל התהליך. לא בגלל שזה מסובך, אלא בגלל שזה תלוי באנשים שהם לא אתם: בעל עסק שצריך למצוא את הסיסמה, מנהל סניף שלא בטוח מי האדמין של העמוד, או לקוח שמוסר סיסמה בוואטסאפ ומתחרט אחר כך. ## למה סיסמאות הן הדרך הלא נכונה רוב הסוכנויות יודעות את זה, אבל עדיין רואים את זה קורה. לקוח שולח שם משתמש וסיסמה, מישהו בסוכנות שומר אותם בגיליון, ושנה אחר כך אף אחד לא זוכר מי עוד יודע אותם. הבעיות ידועות: 1. סיסמה שנמסרה נותנת גישה לכל החשבון, לא רק לפרסום. 2. אימות דו שלבי שולח קוד לטלפון של הלקוח, ומישהו צריך להעביר אותו כל פעם. 3. כשהלקוח מחליף סיסמה, כל החיבורים נשברים בלי הודעה. 4. כשעובד עוזב את הסוכנות, אין דרך אמיתית לדעת מה הוא עוד יכול לפתוח. החלופה היא הרשאה מואצלת. התקן שעומד מאחורי רוב החיבורים האלה הוא [OAuth 2.0](https://datatracker.ietf.org/doc/html/rfc6749), שמאפשר לאפליקציה לקבל גישה מוגבלת לחשבון בשם הבעלים שלו, בלי שהסיסמה עוברת דרכה. הבעלים מתחבר ישירות מול הרשת, רואה אילו הרשאות האפליקציה מבקשת, ומאשר. הגישה ניתנת לביטול בכל רגע מתוך הרשת עצמה. ## איך זה נראה מהצד של הלקוח הלקוח מקבל קישור. הוא פותח אותו בטלפון או במחשב, ורואה דף פשוט שמבקש ממנו להתחבר לפייסבוק ולאינסטגרם, או ליוטיוב. ההתחברות עצמה מתבצעת בדף של הרשת, לא בדף של שַׁגֵּר. אחרי שהוא מאשר, הוא בוחר אילו עמודים וחשבונות לחבר, וזהו. כמה דברים שכדאי להכין את הלקוח אליהם: 1. **אינסטגרם צריך להיות חשבון מקצועי.** הממשק הרשמי של Meta לפרסום תוכן מתועד עבור [חשבונות אינסטגרם מקצועיים](https://developers.facebook.com/docs/instagram-platform/content-publishing). אם החשבון של הלקוח הוא חשבון אישי, הוא צריך להמיר אותו קודם. 2. **מי שמחבר צריך להיות בעל הרשאות בעמוד.** בפייסבוק, מי שמתחבר צריך גישה לניהול העמוד. כדאי לוודא את זה לפני ששולחים את הקישור, כי זו הסיבה הנפוצה לכך שעמוד "לא מופיע". 3. **ביוטיוב, החשבון הנכון.** הרבה בעלי עסקים מחוברים לכמה חשבונות גוגל. ההתחברות צריכה להיות עם החשבון שמנהל את הערוץ. ## איך זה נראה מהצד של הסוכנות בממשק של שַׁגֵּר יוצרים קישור חיבור לכל לקוח, ומקבלים כתובת לשלוח. אפשר לתת לכל קישור תווית, כמו "סניף נתניה" או "דנה, שיווק", שמוצגת רק לסוכנות. כך יודעים מי חיבר מה. אחרי שהלקוח סיים, החשבונות מופיעים ברשימת הערוצים של סביבת העבודה, עם סימון שהם חוברו דרך הלקוח. לכל קישור יש תאריך תפוגה, כך שקישור ישן שנשכח בתיבת דואר לא נשאר פתוח לנצח. ## איך סוכן AI מנהל את התהליך כאן המודל משתנה. במקום שמנהל לקוח ישלח קישורים, יעקוב מי חיבר ומי לא, ויזכיר שוב ושוב, סוכן יכול להחזיק את כל זה. בְּשַׁגֵּר הפעולה נקראת `create_connect_link`, והיא זמינה גם דרך MCP וגם דרך REST. נקודה חשובה: הפעולה הזו דורשת שאדם תבע את הסביבה. סוכן שנמצא בארגז חול לא יכול ליצור קישורי חיבור, וזה בכוונה. קישור חיבור מאפשר גישה לחשבונות אמיתיים של לקוחות, ולכן צריך מאחוריו אדם אחראי. תיארתי את תהליך התביעה ב[מאמר על הרשמה עצמית של סוכן](/blog/agent-self-signup-and-claim). רצף טיפוסי לקליטת רשת סניפים: ```text 1. create_workspace(name: "רשת הקפה, סניפים", timezone: "Asia/Jerusalem") 2. לכל סניף: create_connect_link(workspace_id, label: "סניף נתניה, מנהל: אבי") מחזיר url ו expires_at 3. שליחת הקישורים למנהלי הסניפים (הסוכן מכין את ההודעה, אדם שולח או מערכת ההודעות של הסוכנות) 4. כל בוקר: list_channels(workspace_id) משווים לרשימת הסניפים, ומדווחים מי עוד לא חיבר 5. אחרי שכולם חיברו: create_group(workspace_id, name: "צפון", channel_ids: [...]) create_group(workspace_id, name: "מרכז", channel_ids: [...]) ``` הפעולה `list_channels` מחזירה לכל חשבון את הרשת, השם, הסטטוס, הפורמטים שהוא תומך בהם, והאם הוא חובר על ידי הלקוח. מספיק כדי שהסוכן יכין כל בוקר רשימה קצרה: אילו סניפים חיברו, אילו לא, ואילו חיבורים לא במצב תקין. ## מה קורה כשחיבור מפסיק לעבוד חיבורים לא נשארים תקינים לנצח. לקוח שינה סיסמה בפייסבוק, מנהל עמוד הוסר מההרשאות, או שהרשת ביקשה התחברות מחדש. במודל של סיסמאות, מגלים את זה כשפוסט לא יוצא ביום חמישי בערב. במודל של קישורי חיבור, הסטטוס של כל חשבון מופיע ברשימת הערוצים. סוכן שבודק כל בוקר את `list_channels` יראה חשבון שהמצב שלו השתנה, ויכול להכין לסוכנות הודעה מוכנה ללקוח עם קישור חיבור חדש. הלקוח מתחבר שוב בעצמו, ושום סיסמה לא עוברת בדרך. זה גם הרגע לבדוק עם `list_posts` אם יש פוסטים מתוזמנים לאותו חשבון שצריך לדחות. ## צ'קליסט לקליטת לקוח חדש זה הנוהל שאני ממליץ עליו, בין אם אדם מריץ אותו ובין אם סוכן: 1. פותחים סביבת עבודה נפרדת ללקוח. 2. מכינים רשימה של כל החשבונות שצריכים להתחבר, עם שם האחראי על כל אחד. 3. מוודאים מראש שחשבונות האינסטגרם מקצועיים ושהאחראים הם מנהלים בעמודים. 4. יוצרים קישור חיבור לכל אחראי, עם תווית ברורה. 5. שולחים עם הסבר קצר בעברית: מה הקישור עושה, שלא צריך סיסמה, ושאפשר לבטל את הגישה בכל רגע. 6. בודקים כל יום מי חיבר. אחרי יומיים, תזכורת. 7. כשכל החשבונות מחוברים, מארגנים אותם בקבוצות. 8. מפרסמים פוסט טיוטה ראשון לקבוצה קטנה ובודקים שהכל עובד. הסעיף החמישי נשמע טריוויאלי, אבל הוא מה שקובע אם הלקוח יפתח את הקישור. בעלי עסקים חשדנים, ובצדק, כלפי קישורים שמבקשים התחברות. הסבר של שתי שורות מהסוכנות שהם מכירים עושה את ההבדל. ## מה זה משנה ביחסים עם הלקוח מעבר לאבטחה, יש כאן שינוי של בעלות. כשהלקוח מחבר את החשבונות שלו בעצמו, ברור לכולם שהם שלו. אם הוא עוזב את הסוכנות, הוא מבטל את הגישה מתוך הרשת ולא צריך לבקש מאף אחד להחזיר לו משהו. זה נשמע כמו חיסרון לסוכנות, אבל בפועל זה בונה אמון. לקוח שיודע שהוא יכול לעזוב בקלות פחות חושש להתחיל. זה מתחבר גם למודל ההפעלה של סוכנות שעובדת עם סוכנים, שבו הלקוח מאשר ומחבר, והסוכנות מבצעת. פירטתי את המודל ב[מאמר על מודל ההפעלה של סוכנות עם סוכני AI](/blog/agency-operating-model-with-agents), ואת העבודה מול הרבה לקוחות במקביל ב[מאמר על סוכן אחד ולקוחות רבים](/blog/one-agent-many-clients). ## שאלות נפוצות ### האם הלקוח צריך לפתוח חשבון בְּשַׁגֵּר כדי להתחבר? לא. הלקוח פותח את הקישור, מתחבר ישירות מול פייסבוק, אינסטגרם או יוטיוב, ובוחר אילו חשבונות לחבר. הוא לא נרשם לְשַׁגֵּר ולא מוסר סיסמה לאף אחד. ### איך הלקוח מבטל את הגישה אם הוא מפסיק לעבוד עם הסוכנות? בדיוק כמו כל חיבור מבוסס הרשאה מואצלת: מתוך הגדרות האבטחה של הרשת עצמה, באזור של אפליקציות מחוברות. הסוכנות יכולה גם לנתק את החשבון מהצד שלה בְּשַׁגֵּר. ### כמה חשבונות אפשר לחבר? תלוי במסלול. כל מסלול כולל מספר חשבונות, משלושה חשבונות במסלול החינמי ועד 500 במסלול Scale, ומעבר לזה יש תמחור לכל חשבון נוסף או מסלול מותאם. הפרטים ב[עמוד המחירים](/pricing). אם אתם קולטים לקוח חדש החודש, נסו לעשות את זה הפעם בלי לבקש אף סיסמה. את כתובת שרת MCP והוראות החיבור של הסוכן תמצאו ב[עמוד הסוכנים](/agents). --- Source: https://shager.ai/blog/client-connect-links # דוח לקוח שבועי שהסוכן כותב לבד: לחיצות לכל חשבון, תקלות ומה עושים הלאה _2026-09-19 · איך סוכן AI מפיק דוח שבועי ללקוח מנתוני שַׁגֵּר: get_analytics לכל חשבון ולכל פוסט, בדיקת פוסטים שנכשלו, חיבור utm_content ללידים ותבנית דוח מוכנה בעברית._ סוכן יכול להכין דוח שבועי ללקוח בתוך כמה דקות, משלוש קריאות לְשַׁגֵּר: `get_analytics` ללחיצות לכל חשבון ולכל פוסט, `list_posts` כדי לדעת מה יצא, ו`get_post` כדי להבין מה נכשל. מה שהסוכן לא יכול לעשות לבד הוא להמציא לידים. לחיצות הן לא פניות, והדוח צריך להגיד את זה במפורש. בסוכנויות שאני מכיר, הדוח השבועי הוא המשימה שכולם דוחים ליום חמישי בערב. זו גם המשימה שהכי קל להעביר לסוכן, כי היא חוזרת על עצמה, הנתונים מובנים, והתבנית קבועה. ## אילו נתונים שַׁגֵּר נותן לסוכן? `get_analytics` מקבל `workspace_id` ושני מועדים, `from` ו`to`, בפורמט ISO 8601. בלי `from` ברירת המחדל היא שלושים ימים אחורה. התשובה כוללת את סך הלחיצות בתקופה, פירוק לפי חשבון (מזהה, שם החשבון, רשת ומספר לחיצות), ופירוק לפי פוסט. הלחיצות נספרות על הקישורים המקוצרים של שַׁגֵּר, וכל חשבון מקבל קישור משלו, כך שהפירוק לפי חשבון הוא מדויק ולא הערכה. לחיצות שזוהו כבוטים לא נספרות. ```json get_analytics { "workspace_id": "ws_hotel_chain", "from": "2026-09-13T00:00:00+03:00", "to": "2026-09-19T23:59:59+03:00" } ``` ובגרסת REST: ```bash curl "https://app.shager.ai/api/v1/workspaces/ws_hotel_chain/analytics?from=2026-09-13T00:00:00%2B03:00&to=2026-09-19T23:59:59%2B03:00" \ -H "Authorization: Bearer $SHAGER_API_KEY" ``` שימו לב לקידוד של הסימן `+` בכתובת. בלי `%2B` השרת יקבל רווח, והמועד לא יעבור בדיקה. זו טעות שסוכנים עושים לעיתים קרובות כשהם בונים כתובות בעצמם. `list_posts` מחזיר את הפוסטים בסביבת העבודה, החדשים קודם, ואפשר לסנן לפי `status`. לדוח שבועי מעניינים שלושה מצבים: `PUBLISHED`, `PARTIALLY_PUBLISHED` ו`FAILED`. לכל פוסט הוא מחזיר תחילת כיתוב, מועד מתוזמן ומספר חשבונות. `get_post` מחזיר את המצב של כל חשבון, כולל קישור חי או הודעת שגיאה. כל הקריאות האלה דורשות רק הרשאת `read`. לכן לסוכן דוחות כדאי לתת מפתח נפרד עם `read` בלבד. הוא לא צריך יותר, ואם המפתח ידלוף, אף אחד לא יפרסם איתו כלום. איך עושים את זה מוסבר ב[מאמר על מפתחות והרשאות](/blog/api-keys-scopes-and-audit). ## רצף הקריאות של הדוח 1. `list_workspaces` כדי לקבל את מזהה סביבת העבודה של הלקוח. 2. `get_analytics` לשבוע הנוכחי. 3. `get_analytics` לשבוע הקודם, כדי שתהיה נקודת השוואה. 4. `list_posts` עם `status` של `PUBLISHED`, ואז עם `PARTIALLY_PUBLISHED` ו`FAILED`. 5. `get_post` לכל פוסט חלקי או כושל, כדי להבין איזה חשבון נכשל ולמה. 6. `list_channels` כדי לזהות חשבונות שדורשים חיבור מחדש. שש קריאות לסביבת עבודה אחת, פלוס קריאה לכל פוסט כושל. גם סוכנות עם עשרים לקוחות רחוקה מאוד ממגבלת 120 הבקשות לדקה למפתח. ## מה הופך לחיצות ללידים? כאן רוב הדוחות האוטומטיים נשברים. שַׁגֵּר יודע כמה אנשים לחצו על הקישור של כל חשבון. הוא לא יודע מי מילא טופס, כי זה קורה באתר של הלקוח. החיבור נעשה דרך `utm_content`: כל קישור מקוצר של שַׁגֵּר מוביל ליעד עם תגיות UTM, וב`utm_content` יש מזהה של החשבון. אם בטופס של הלקוח יש שדות נסתרים שקולטים את התגיות ושומרים אותן במערכת CRM, אפשר לספור לידים לכל חשבון. אם יש לסוכן גישה לייצוא ממערכת CRM, למשל קובץ CSV שבועי, הוא יכול לחבר את שני המקורות לפי `utm_content` ולהוסיף עמודת לידים לדוח. אם אין, הדוח מציג לחיצות ואומר בבירור שהלידים לא נמדדו. ההסבר המלא על השכבות האלה נמצא ב[מאמר על שיוך לידים לכל חשבון](/blog/utm-per-account-lead-attribution), וההרחבה לעבודה עם סוכן ב[מדידת לידים מתוכן של סוכנים](/blog/measuring-leads-from-agent-content). ## תבנית הדוח זו התבנית שאני נותן לסוכן. היא קצרה בכוונה. לקוח קורא את החצי הראשון ואת השורה האחרונה. ```text דוח שבועי: {שם הלקוח}, {תאריך התחלה} עד {תאריך סיום} בשורה אחת: {משפט אחד: מה יצא השבוע ומה בלט, עם מספר אחד} מה פורסם: {מספר פוסטים} פוסטים ל{מספר חשבונות} חשבונות. {מספר} פורסמו במלואם, {מספר} חלקית. איפה לחצו: | חשבון | רשת | לחיצות השבוע | לחיצות שבוע שעבר | {חמש השורות הגבוהות} חשבונות בלי לחיצות: {רשימה, או "אין"} תקלות: {חשבון, מה קרה, מה נעשה. אם צריך פעולה מהלקוח, כתוב בדיוק מה} לשבוע הבא: {המלצה אחת או שתיים, רק אם יש להן בסיס בנתונים} ``` ## הפרומפט שמפעיל את הדוח ```text אתה מכין דוח שבועי ללקוח "מלונות הים" מנתוני שגר. סביבת עבודה: "מלונות הים". השבוע: 2026-09-13 עד 2026-09-19, אזור זמן Asia/Jerusalem. 1. הרץ get_analytics לשבוע הזה ולשבוע שלפניו. 2. הרץ list_posts לפי הסטטוסים PUBLISHED, PARTIALLY_PUBLISHED ו FAILED. 3. לכל פוסט שאינו PUBLISHED הרץ get_post ורשום את החשבונות שנכשלו ואת הודעת השגיאה. 4. הרץ list_channels וסמן חשבונות שדורשים חיבור מחדש. 5. מלא את התבנית המצורפת. עד 250 מילים. כללים: לחיצות אינן לידים. אל תכתוב "לידים" אם אין לך קובץ CRM. אל תסביר ירידה או עלייה בלי נתון שתומך בהסבר. "לא ברור מהנתונים" היא תשובה לגיטימית. שמות חשבונות כפי שהם מופיעים בשגר. אם חשבון דורש חיבור מחדש, הצע לשלוח ללקוח קישור חיבור, אבל אל תיצור אותו בלי אישור. ``` הכלל השני חשוב יותר ממה שנראה. מודלים נוטים לספק הסברים משכנעים לכל תנודה ("הירידה נובעת מהחג"). לפעמים זה נכון, ולפעמים זו המצאה. לקוח שתפס את הסוכנות פעם אחת על הסבר מומצא יפסיק להאמין לדוחות. ## איך מטפלים בתקלות בדוח? סעיף התקלות הוא הסיבה שלקוחות קוראים דוחות שבועיים. פוסט שלא עלה בשלושה עמודים, כי ההרשאה של הלקוח בפייסבוק פגה, הוא מידע שהלקוח צריך לדעת, עם פעולה ברורה. בְּשַׁגֵּר הפתרון הוא קישור חיבור שהלקוח פותח, מתחבר לחשבון שלו ובוחר את העמודים, בלי חשבון בְּשַׁגֵּר ובלי לשתף סיסמאות. הסוכן יכול ליצור את הקישור עם `create_connect_link`, אבל זו פעולה שדורשת הרשאת `write` ותביעה של הסנדבוקס, ולכן בסוכן דוחות עם `read` בלבד הוא רק ממליץ. על קישורי החיבור יש [מאמר נפרד](/blog/client-connect-links). ## להפוך את זה לשגרה ברגע שהדוח עובד פעם אחת, הוא צריך לרוץ כל שבוע בלי שמישהו יזכור. שתי דרכים מקובלות: סקיל בסוכן שאדם מפעיל ביום קבוע, או סקריפט שקורא לממשק REST ושולח את הנתונים למודל. הדרך הראשונה פשוטה יותר להתחלה. [המדריך לשגרת הפצה שבועית בסקיל](/blog/skill-weekly-distribution-routine) מראה את המבנה, והדוח הוא פשוט עוד שלב בסופה. כל הפרמטרים של `get_analytics` מופיעים ב[מפרט OpenAPI](https://app.shager.ai/api/v1/openapi.json). ## שאלות נפוצות ### האם שַׁגֵּר מודד חשיפות ותגובות ברשתות? הכלי `get_analytics` מחזיר לחיצות על הקישורים המקוצרים של שַׁגֵּר, לכל חשבון ולכל פוסט. מדדי מעורבות של הרשת עצמה לא נכללים בתשובה שלו, ולכן אם הלקוח רוצה אותם בדוח, צריך להביא אותם ממקור נוסף. ### למה לחיצות בְּשַׁגֵּר לא תואמות לביקורים בכלי כמו Google Analytics? כי כל אחד סופר דבר אחר. שַׁגֵּר סופר לחיצה בשרת לפני ההפניה, וכלי האנליטיקס סופר ביקור רק אם הדף נטען והגולש לא חסם את הסקריפט. פער מסוים צפוי, ופער גדול מרמז על בעיה בדף הנחיתה או בהגדרות האנליטיקס. ### האם הסוכן יכול לשלוח את הדוח ללקוח בעצמו? שַׁגֵּר לא שולח דוחות. אם לסוכן יש גישה לכלי מייל או לוואטסאפ עסקי, הוא יכול, אבל אני ממליץ שאדם בסוכנות יקרא כל דוח לפני שהוא יוצא, לפחות בחודשים הראשונים. --- Source: https://shager.ai/blog/weekly-client-report-by-agent # גיוון כיתובים לכל חשבון עם AI: אותו מסר, ניסוח אחר בכל עמוד _2026-09-15 · איך סוכן AI כותב כיתוב שונה לכל עמוד וחשבון בלי שום צורך לאבד את המסר: מה משתנה ומה נשאר קבוע, תבנית פרומפט, שימוש בשדה per_channel ובדיקת איכות לפני כל פרסום._ גיוון כיתובים לכל חשבון אומר שכל עמוד מקבל ניסוח משלו לאותו מסר: פתיחה אחרת, פרט מקומי, קריאה לפעולה בניסוח שונה, בזמן שההצעה, המחיר והתנאים נשארים זהים. סוכן AI עושה את זה טוב יותר מאדם, כי הוא לא מתעייף בווריאציה העשרים, אבל רק אם מגדירים לו בדיוק מה מותר לשנות ומה אסור לגעת בו. זה לא עניין קוסמטי. כשאותו טקסט בדיוק יוצא בשלושים עמודים, הוא נראה כמו שכפול, גם לקהל וגם לרשתות. וכשכל סניף כותב לבד, המסר מתפרק. הגיוון הנכון יושב באמצע. ## למה בכלל לגוון? יש שלוש סיבות, ורק אחת מהן קשורה לאלגוריתם. הסיבה הראשונה היא הקהל. עוקב של סניף ברמת גן ועוקב של סניף בבאר שבע הם אנשים שונים, עם שכונות שונות ולפעמים עם צרכים שונים. פוסט שמזכיר את המקום שלהם נקרא אחרת. הסיבה השנייה היא חפיפה. הרבה אנשים עוקבים אחרי כמה עמודים של אותו מותג, ובמיוחד ברשתות עם סניפים קרובים. אם הם רואים את אותו טקסט שלוש פעמים ברצף, הם מפסיקים לקרוא. הסיבה השלישית היא המדיניות של הרשתות. [מדיניות הספאם של Meta](https://transparency.meta.com/policies/community-standards/spam/) מונה פרסום של תוכן חוזר כאחד הסימנים שיכולים להוביל להגבלה, ו[מדיניות הספאם של YouTube](https://support.google.com/youtube/answer/2801973) אוסרת שימוש בכלים אוטומטיים או בבינה מלאכותית כדי לייצר כמויות גדולות של תוכן דומה עם שינויים מינימליים. שימו לב לניסוח: שינויים מינימליים. החלפת מילה אחת לא פותרת את הבעיה. ## מה משתנה ומה נשאר קבוע לפני שכותבים פרומפט, צריך טבלה. זו הטבלה שאני נותן לכל סוכן שכותב וריאציות: | רכיב | משתנה בין חשבונות? | הערה | |---|---|---| | ההצעה עצמה | לא | אותו מבצע, אותו מוצר | | מחיר, תאריכים, תנאים | לא, אף פעם | מועתקים מילה במילה מהבריף | | שורת הפתיחה | כן | זה השינוי הכי משמעותי | | פרט מקומי | כן | שם השכונה, הסניף, נקודת ציון מוכרת | | מבנה הפוסט | כן, בגבולות | שאלה, סיפור קצר, רשימה | | הקריאה לפעולה | כן בניסוח, לא במהות | "הירשמו", "שריינו מקום", "דברו איתנו" | | טון וקול המותג | לא | מוגדר פעם אחת לכל לקוח | | האשטגים | כן, חלקית | בסיס קבוע ותוספת מקומית | | הקישור | לא בכתובת היעד | שַׁגֵּר מייצר קישור ותיוג נפרדים לכל חשבון | השורה האחרונה חשובה. לא צריך לבקש מהסוכן לבנות קישור שונה לכל חשבון. כשמגדירים `cta_url` בפוסט, שַׁגֵּר מייצר לכל חשבון קישור מקוצר ותיוג UTM משלו. הסוכן מטפל בטקסט, המערכת מטפלת במדידה. ## איך זה עובד טכנית בפעולה create_post הפעולה `create_post` מקבלת כיתוב בסיס בשדה `caption`, ורשימה בשדה `per_channel` שבה כל פריט הוא חשבון עם כיתוב, תגובה ראשונה ופורמט משלו. חשבון שלא מופיע ברשימה מקבל את כיתוב הבסיס. ```json { "workspace_id": "ws_...", "caption": "מבצע פתיחת קיץ: 20% הנחה על מנוי שנתי עד סוף החודש.", "channel_ids": ["ch_ramatgan", "ch_beersheva", "ch_haifa"], "cta_url": "https://example.co.il/summer", "campaign": "summer-opening", "per_channel": [ { "channel_id": "ch_ramatgan", "caption": "שכנים מהבורסה, הקיץ מתחיל אצלנו. 20% הנחה על מנוי שנתי עד סוף החודש.", "first_comment": "שריינו מנוי בקישור" }, { "channel_id": "ch_beersheva", "caption": "באר שבע, מי שמתאמן בקיץ יודע למה מזגן טוב שווה זהב. 20% הנחה על מנוי שנתי עד סוף החודש.", "first_comment": "כל הפרטים כאן" } ] } ``` הסניף בחיפה יקבל את כיתוב הבסיס. במקרה הזה זה בסדר, אבל בקמפיין של עשרות חשבונות כדאי שכל חשבון יקבל ניסוח משלו. הדוגמה כאן מינימלית בכוונה, כדי שיהיה ברור איך המבנה עובד. ## תבנית פרומפט שעובדת הנה התבנית שאני משתמש בה. היא ארוכה, וזה בכוונה: ```text אתה כותב כיתובים לפוסט אחד שיוצא לכמה חשבונות של אותו לקוח. מסר קבוע (לא לשנות בשום חשבון): "20% הנחה על מנוי שנתי עד 31.8" קול המותג: ישיר, חם, בלי סימני קריאה כפולים, בלי סלנג צבאי. עבור כל חשבון ברשימה (שם, עיר, שכונה, פרט מקומי): 1. כתוב שורת פתיחה שונה מכל השאר. 2. שלב פרט מקומי אחד אמיתי מהרשימה. אל תמציא פרטים. 3. העתק את המסר הקבוע מילה במילה. 4. נסח קריאה לפעולה אחרת מהחשבון הקודם. 5. עד 60 מילים. החזר JSON במבנה per_channel: channel_id, caption, first_comment. לפני שאתה מחזיר, בדוק שאין שתי שורות פתיחה זהות ושהמסר הקבוע מופיע בדיוק. ``` הכלל "אל תמציא פרטים" קריטי. סוכן שמתבקש לכתוב משהו מקומי על סניף בעפולה, בלי שקיבל מידע, ימציא בית קפה ליד שלא קיים. לכן הפרטים המקומיים צריכים להגיע מרשימה שהסוכנות מחזיקה, לא מהזיכרון של המודל. עוד פרומפטים לסוכן תוכן, כולל איך מגדירים קול מותג, אספתי ב[מאמר על פרומפטים לסוכן תוכן](/blog/prompts-for-a-content-agent). ## בעברית יש בעיות משלה מודלים כותבים עברית טוב יותר משכתבו לפני שנתיים, אבל עדיין יש דפוסים שחוזרים. כשמבקשים מהם הרבה וריאציות, הם נוטים להתחיל משפטים באותה מילה, לנסח כמו תרגום מאנגלית, ולהשתמש בביטויים שאף ישראלי לא אומר. גם פנייה מגדרית דורשת תשומת לב: מותג שפונה ברבים צריך לפנות ברבים בכל הווריאציות. כדאי להוסיף לפרומפט דוגמאות של שני פוסטים אמיתיים מהלקוח, כדי שהסוכן יבין איך המותג נשמע. הרחבתי על זה ב[מאמר על סוכני תוכן בעברית](/blog/hebrew-content-agents). ## מאיפה מגיעים הפרטים המקומיים הסוכנויות שעושות את זה טוב מחזיקות לכל לקוח גיליון פשוט: שורה לכל חשבון, עם שם הסניף, העיר, השכונה, שם המנהל אם הוא מופיע בפוסטים, ושניים או שלושה פרטים אמיתיים שאפשר להזכיר. חניה נוחה, קרבה לתחנת רכבת, מבצע קבוע של הסניף. את הגיליון ממלאים פעם אחת עם הלקוח ומעדכנים פעם ברבעון. הסוכן קורא את הגיליון, מצליב אותו עם מזהי החשבונות שהוא מקבל מהפעולה `list_channels`, וכותב לכל חשבון מתוך המידע הזה בלבד. זו עבודה של שעה בהתחלה, והיא מה שהופך ניסוח שונה לניסוח מקומי באמת. ## בדיקת איכות לפני פרסום עורך לא צריך לקרוא שלושים וריאציות. הוא צריך לבדוק: 1. **המסר הקבוע.** הסוכן יכול לבדוק בעצמו שהמחרוזת מופיעה בדיוק בכל כיתוב. אם לא, הפלט נפסל. 2. **פתיחות זהות.** בדיקה אוטומטית שאין שתי שורות פתיחה זהות או כמעט זהות. 3. **דגימה של חמישה.** לקרוא חמש וריאציות אקראיות ולבדוק טון ופרטים מקומיים. 4. **פרטים מומצאים.** לוודא שכל פרט מקומי מופיע ברשימת המקור. 5. **אורך.** כיתובים ארוכים מדי בפורמט קצר, כמו Story, לא עובדים. אחרי הבדיקה, הסוכן שולח את הטיוטה לאישור לקוח. הלקוח רואה את הפוסטים ומאשר בקישור אחד. אם הוא מבקש שינוי בדפוס, מתקנים את הפרומפט ומריצים מחדש, לא מתקנים כל כיתוב ביד. ## הגבול: גיוון זה לא הסתרה חשוב להיות ישרים לגבי המטרה. גיוון כיתובים נועד להתאים את המסר לקהל של כל עמוד, ולא להסוות פרסום המוני כדי לעקוף מנגנוני הגנה. אם הניסוח השונה הוא רק תחפושת לתוכן שאין בו ערך, הבעיה לא בניסוח. שַׁגֵּר בנוי מתוך ההנחה הזו. גם עם `per_channel`, הפרסום מתפזר בזמן בין חשבונות, כל פוסט נבדק מול חוקי הרשת, והפרסום עובר רק דרך הממשקים הרשמיים. הכללים המלאים נמצאים ב[חוקי בטיחות לסוכנים שמפרסמים בהיקף](/blog/safety-rules-for-agents-posting-at-scale). ## שאלות נפוצות ### כמה שונה צריך להיות כל כיתוב? אין מספר רשמי. הכלל המעשי שלי הוא שקורא שרואה שני כיתובים זה ליד זה צריך להבין מיד שהם נכתבו לקהלים שונים. פתיחה אחרת, פרט מקומי אחר וקריאה לפעולה בניסוח אחר הם המינימום. ### האם צריך לגוון גם את הסרטון או התמונה? לא תמיד. בהרבה קמפיינים הנכס הוויזואלי זהה, והכיתוב הוא מה שמתאים אותו לקהל. כשיש אפשרות, גרסאות שונות של התמונה הראשונה בסרטון או תמונה מהסניף עצמו מוסיפות התאמה אמיתית. ### מה קורה לחשבון שלא קיבל כיתוב בשדה per_channel? הוא מקבל את כיתוב הבסיס מהשדה `caption`. בקמפיין גדול כדאי להגדיר לסוכן כלל שכל חשבון מקבל ניסוח משלו, ולבדוק לפני השליחה שאין חשבון שנשאר עם הבסיס בלי כוונה. מי שמחזיק את קול המותג לאורך הרבה חשבונות ימצא את הצד השני של הנושא ב[מאמר על עקביות מותג בהרבה חשבונות](/blog/brand-consistency-across-many-accounts). ומי שרוצה לחבר סוכן ולנסות את התבנית על קמפיין אמיתי יכול להתחיל ב[עמוד הסוכנים](/agents). --- Source: https://shager.ai/blog/caption-variation-per-account-with-ai # ממשק REST API של שַׁגֵּר בעשר דקות: מהקריאה whoami ועד פוסט מתוזמן לעשרות חשבונות _2026-09-15 · מדריך מהיר לממשק REST API של שַׁגֵּר: אימות Bearer, מבנה תשובות ושגיאות, מגבלת קצב, ורצף קריאות אמיתי מסביבת עבודה, דרך העלאת מדיה וטיוטה, ועד תזמון ואנליטיקס._ ממשק REST API של שַׁגֵּר יושב תחת `https://app.shager.ai/api/v1`, מאמת כל בקשה בכותרת `Authorization: Bearer shgr_live_…`, ומחזיר תשובות במבנה `{ "data": … }` ושגיאות במבנה `{ "error": { "code", "message" } }`. הרצף הבסיסי הוא `GET /me`, אחריו `GET /workspaces`, רשימת החשבונות של סביבת עבודה, העלאת מדיה, יצירת פוסט ותזמון שלו. המפרט המלא, OpenAPI 3.1, נמצא בכתובת [https://app.shager.ai/api/v1/openapi.json](https://app.shager.ai/api/v1/openapi.json), וכל פעולה בו מקבילה לכלי באותו שם בשרת MCP. המדריך מיועד למפתחים שבונים אוטומציה, אינטגרציה או סוכן משלהם, ומעדיפים קוד על פני שרת MCP. הדוגמאות כתובות בכלי curl כדי שיהיה קל להעתיק, אבל כל שפה שיודעת לשלוח HTTP תעבוד. טיפ קטן לפני שמתחילים: טענו את קובץ OpenAPI לכלי שאתם עובדים איתו לבדיקת API, או תנו אותו לסוכן הקוד שלכם. כל שדה מתועד בו עם תיאור, מגבלות אורך וערכים מותרים, וזה חוסך ניחושים לגבי מה בדיוק כל נתיב מצפה לקבל. ## לפני הקריאה הראשונה צריך מפתח API. אדם בצוות יוצר אותו בכתובת `https://app.shager.ai/dashboard/agents` ובוחר הרשאות מתוך `read`, `write` או `publish`, או שסוכן נרשם בעצמו ומקבל sandbox, כמו שמוסבר במדריך [על הרשמה עצמית של סוכן](/blog/agent-self-signup-and-claim). הגישה לממשק API כלולה בכל המסלולים, כולל החינמי, כפי שמופיע ב[עמוד המחירים](/pricing). שומרים את המפתח במשתנה סביבה: ```bash export SHAGER_API_KEY="shgr_live_XXXXXXXXXXXXXXXX" export SHAGER="https://app.shager.ai/api/v1" ``` ## מפת הפעולות | פעולה | שיטה ונתיב | הרשאה סבירה | |---|---|---| | whoami | `GET /me` | read | | list_workspaces | `GET /workspaces` | read | | create_workspace | `POST /workspaces` | write | | list_channels | `GET /workspaces/{id}/channels` | read | | create_connect_link | `POST /workspaces/{id}/connect-links` | write | | list_groups, create_group | `GET` או `POST /workspaces/{id}/groups` | read, write | | upload_media_from_url | `POST /workspaces/{id}/media` | write | | create_post, list_posts | `POST` או `GET /workspaces/{id}/posts` | write, read | | get_post | `GET /workspaces/{id}/posts/{post_id}` | read | | schedule_post | `POST /workspaces/{id}/posts/{post_id}/schedule` | publish | | request_approval | `POST /workspaces/{id}/posts/{post_id}/approval` | write | | cancel_post | `POST /workspaces/{id}/posts/{post_id}/cancel` | write | | get_analytics | `GET /workspaces/{id}/analytics` | read | העמודה האחרונה היא הנחת עבודה סבירה לפי אופי הפעולה. הקובע הוא ההרשאות שהמפתח שלכם קיבל בפועל, וְשַׁגֵּר יחזיר שגיאה ברורה אם חסרה הרשאה. ## שלב 1: מי אני ואיפה אני עובד ```bash curl -s "$SHAGER/me" -H "Authorization: Bearer $SHAGER_API_KEY" curl -s "$SHAGER/workspaces" -H "Authorization: Bearer $SHAGER_API_KEY" ``` בְּשַׁגֵּר כל לקוח הוא סביבת עבודה (workspace). אם אין עדיין אף אחת, יוצרים: ```bash curl -s -X POST "$SHAGER/workspaces" \ -H "Authorization: Bearer $SHAGER_API_KEY" \ -H "Content-Type: application/json" \ -d '{"name": "רשת מרפאות השן", "timezone": "Asia/Jerusalem"}' ``` אזור הזמן ברירת המחדל הוא `Asia/Jerusalem`, ויש גם שדה `approval_required` שקובע אם פוסטים בסביבה הזו חייבים אישור לקוח לפני תזמון. לסוכנים ברירת המחדל שלו היא false. ## שלב 2: אילו חשבונות מחוברים ```bash curl -s "$SHAGER/workspaces/$WS/channels" -H "Authorization: Bearer $SHAGER_API_KEY" curl -s "$SHAGER/workspaces/$WS/groups" -H "Authorization: Bearer $SHAGER_API_KEY" ``` אם הרשימה ריקה, יוצרים קישור חיבור עם `POST /workspaces/{id}/connect-links` ושולחים אותו לבעל החשבונות. הלקוח מחבר את הפייסבוק, האינסטגרם או היוטיוב שלו דרך הקישור, בלי חשבון בְּשַׁגֵּר ובלי למסור סיסמה. קבוצות חשבונות שימושיות כשיש עשרות עמודים: במקום לרשום מזהים אחד אחד, שולחים `group_ids` וכל החשבונות הפעילים בקבוצה נכנסים לפוסט. ## שלב 3: העלאת מדיה שַׁגֵּר מושך את הקובץ מכתובת URL. עבור סרטון קצר כדאי לשלוח גם מידות ואורך: ```bash curl -s -X POST "$SHAGER/workspaces/$WS/media" \ -H "Authorization: Bearer $SHAGER_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "url": "https://cdn.example.com/autumn-30s.mp4", "file_name": "autumn-30s.mp4", "width": 1080, "height": 1920, "duration_ms": 30000 }' ``` השדות `width`, `height` וגם `duration_ms` הם מה שמאפשר לְשַׁגֵּר לבדוק מראש אם הסרטון מתאים לפורמט Reel, Short או Story, ולא לגלות את זה רק כשהרשת דוחה אותו. המזהה של המדיה חוזר בתוך `data`, ואותו מעבירים בשדה `media_ids`. ## שלב 4: יצירת פוסט זו הקריאה שבה רוב הערך נמצא: ```bash curl -s -X POST "$SHAGER/workspaces/$WS/posts" \ -H "Authorization: Bearer $SHAGER_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "label": "מבצע סתיו, שבוע 1", "campaign": "autumn-2026", "group_ids": ["GROUP_NORTH"], "media_ids": ["MEDIA_ID"], "format": "REEL", "caption": "בדיקה שנתית לכל המשפחה, עכשיו עם תור תוך שבוע.", "per_channel": [ {"channel_id": "CH_HAIFA", "caption": "חיפה, התורים לסתיו נפתחו."}, {"channel_id": "CH_AFULA", "caption": "בעפולה? יש תורים כבר לשבוע הבא."} ], "cta_url": "https://example.com/autumn", "first_comment": "לקביעת תור בסניף הקרוב:", "stagger_seconds": [45, 120] }' ``` כמה דברים שקורים כאן מאחורי הקלעים. `cta_url` מקבל לכל חשבון קישור מקוצר ותגיות UTM משלו, כש `utm_content` מזהה את החשבון, והשדה `campaign` הופך לפרמטר `utm_campaign`. `first_comment` עולה כתגובה ראשונה מיד אחרי הפרסום, וזה המקום הטבעי לקישור לליד. `per_channel` מחליף את הכיתוב רק בחשבונות שציינתם, והשאר מקבלים את `caption` הכללי. והשדה `stagger_seconds` קובע את טווח ההשהיה האקראית בין חשבונות של אותה רשת, עם ברירת מחדל של 30 עד 90 שניות. פוסט בלי `schedule_at` נשמר כטיוטה. ליוטיוב יש שני שדות נוספים: `youtube_title` וגם `youtube_privacy` עם הערכים public, unlisted או private. ## שלב 5: אישור, תזמון ומעקב אם הלקוח צריך לאשר, שולחים בקשת אישור עם שם הסוקר. הלקוח מאשר דרך קישור, בלי להתחבר: ```bash curl -s -X POST "$SHAGER/workspaces/$WS/posts/$POST_ID/approval" \ -H "Authorization: Bearer $SHAGER_API_KEY" \ -H "Content-Type: application/json" \ -d '{"reviewer_name": "מיכל", "reviewer_email": "michal@example.com", "send_email": true}' ``` תזמון דורש זמן בפורמט ISO 8601 עם offset: ```bash curl -s -X POST "$SHAGER/workspaces/$WS/posts/$POST_ID/schedule" \ -H "Authorization: Bearer $SHAGER_API_KEY" \ -H "Content-Type: application/json" \ -d '{"schedule_at": "2026-09-20T09:00:00+03:00"}' ``` אפשר גם לשלוח `schedule_at` כבר בקריאה `create_post` ולחסוך קריאה. לבדיקת מצב משתמשים בפעולה `get_post`, או בפעולה `list_posts` עם `status`, למשל `SCHEDULED`, `PUBLISHED`, `PARTIALLY_PUBLISHED` או `FAILED`. ואחרי כמה ימים: ```bash curl -s "$SHAGER/workspaces/$WS/analytics?from=2026-09-20T00:00:00%2B03:00" \ -H "Authorization: Bearer $SHAGER_API_KEY" ``` התשובה כוללת לחיצות לפי חשבון ולפי פוסט בטווח התאריכים. בלי `from`, ברירת המחדל היא 30 הימים האחרונים. ## שגיאות ומגבלת קצב כל שגיאה חוזרת עם `code` וגם `message` קריאים. שווה לטפל בשלושה מקרים במפורש: 401 על מפתח לא תקין או מבוטל, `sandbox_unclaimed` כשמנסים פעולה חסומה לפני שאדם אישר את סביבת sandbox, וקוד `rejected` כְּשֶׁשַּׁגֵּר בודק את הפוסט מול הכללים של הרשת ומוצא משהו שהיא הייתה דוחה. ההודעה אומרת מה בדיוק לא עבר. המגבלה היא 120 בקשות בדקה לכל מפתח. בפועל קשה להגיע אליה אם עובדים נכון, כי פוסט אחד עם `group_ids` מכסה עשרות חשבונות בקריאה אחת. מי שמגיע אליה בדרך כלל עושה polling על `get_post` לכל פוסט בנפרד, ועדיף להחליף את זה בפעולה `list_posts`. ## חמישה הרגלים שהופכים סקריפט לאינטגרציה ההבדל בין סקריפט שעבד פעם אחת לבין אינטגרציה שרצה חצי שנה בלי הפתעות הוא בדרך כלל לא בקוד של הקריאות, אלא בהרגלים שמסביב: 1. **שמרו כל מזהה שחוזר.** מזהה סביבת העבודה, המדיה והפוסט צריכים להישמר אצלכם, בטבלה או בקובץ, יחד עם המקור שממנו נוצרו. כך אפשר לחזור לפוסט, לבדוק את המצב שלו ולבטל אותו בלי לחפש. 2. **אל תיצרו פוסט פעמיים.** אם הסקריפט נופל באמצע וחוזר לרוץ, הוא עלול ליצור את אותה טיוטה שוב. בדקו קודם עם `list_posts` אם כבר קיים פוסט עם אותו `label`. 3. **המתינו כשמגיעים למגבלה.** על שגיאת קצב, חכו ונסו שוב עם השהיה הולכת וגדלה, במקום להפציץ את השרת. 4. **אל תדפיסו את המפתח.** לא בלוג, לא בהודעת שגיאה ולא בצילום מסך. אם הוא דלף, מבטלים אותו במסך הסוכנים ויוצרים חדש. 5. **התחילו בטיוטות.** מפתח בלי `publish` בשבועות הראשונים נותן לכם לראות מה הקוד מייצר לפני שזה עולה לעמודים אמיתיים. ## מה הלאה אם אתם בונים סוכן ולא סקריפט, אותן פעולות זמינות כשרת MCP בכתובת `https://app.shager.ai/api/mcp`, והחיבור לרוב הכלים לוקח דקות. המדריך [לחיבור שַׁגֵּר אל Claude Code](/blog/connect-shager-to-claude-code) הוא נקודת התחלה טובה, ו[עמוד הסוכנים](/agents) מרכז את כל דרכי החיבור. ואם אתם מתכננים זרימה מלאה מבריף ועד דוח, [המדריך לצינור תוכן של סוכן מקצה לקצה](/blog/agent-content-pipeline-end-to-end) מחבר את כל השלבים. ## שאלות נפוצות ### יש SDK רשמי לְשַׁגֵּר? אין כרגע SDK או CLI רשמי, CLI של שַׁגֵּר נמצא בפיתוח. מכיוון שיש מפרט OpenAPI 3.1 מלא, אפשר לייצר לקוח בכל שפה עם מחולל קוד סטנדרטי, או פשוט לעבוד עם HTTP ישירות כמו בדוגמאות. ### מה ההבדל בין שליחת schedule_at בקריאה create_post לבין schedule_post? התוצאה זהה. שליחה בקריאה `create_post` חוסכת קריאה כשהכול מוכן מראש. `schedule_post` מתאים כשיוצרים טיוטה, שולחים לאישור, ומתזמנים רק אחרי שהלקוח אישר. ### איך מבטלים פוסט שכבר תוזמן? שולחים `POST` לנתיב `/workspaces/{id}/posts/{post_id}/cancel`. אחרי הביטול הסטטוס של הפוסט יהיה `CANCELED`, ואפשר לראות את זה בפעולה `get_post`. --- Source: https://shager.ai/blog/shager-rest-api-quickstart # פרומפטים לסוכן תוכן: שש הוראות מוכנות להעתקה לעבודה עם שַׁגֵּר _2026-09-14 · שישה פרומפטים מלאים בעברית לסוכן תוכן שעובד עם שַׁגֵּר: הוראות קבועות, הפצה שבועית, גיוון כיתובים, וידאו קצר, בדיקת איכות לפני תזמון ודוח שבועי ללקוח._ פרומפט טוב לסוכן תוכן מגדיר ארבעה דברים: עם מי הוא עובד, אילו כלים מותר לו להפעיל, איפה הוא חייב לעצור ולשאול, ואיך נראה התוצר שהוא מחזיר. בהמשך יש שישה פרומפטים מלאים שאפשר להעתיק, כל אחד לשלב אחר בעבודה עם שַׁגֵּר, משיחת הפתיחה ועד הדוח השבועי. כולם נכתבו לסוכן שכבר מחובר לשרת MCP של שַׁגֵּר. אם הסוכן שלכם עוד לא מחובר, התחילו מ[המדריך לחיבור Claude Code](/blog/connect-shager-to-claude-code) או מ[עמוד הסוכנים](/agents). ## איך בנויים הפרומפטים? השתמשתי בתגיות בסגנון XML כדי להפריד בין הקשר, כללים ומשימה. Anthropic ממליצה על השיטה הזו בתיעוד שלה, כי היא עוזרת למודל להבחין בין חלקים שונים של ההוראה ([התיעוד הרשמי על תגיות XML](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/use-xml-tags)). זה עובד גם עם מודלים אחרים, ואין צורך בשמות תגיות מיוחדים. מה שחשוב הוא העקביות. בכל פרומפט יש נקודת עצירה מפורשת. סוכן שלא יודע איפה לעצור יעשה את הצעד הבא, וכשמדובר בפרסום לשישים עמודים זה בדיוק הצעד שרציתם לבדוק. ## פרומפט 1: הוראות קבועות לסוכן הסוכנות את זה שמים בהוראות הפרויקט, בקובץ CLAUDE.md או בקובץ ההוראות של הכלי שלכם. הוא חל על כל שיחה. ```text אתה סוכן התוכן של סוכנות "נקודה" לשיווק דיגיטלי. אתה כותב, מכין ומפיץ תוכן ללקוחות הסוכנות דרך שגר (MCP). 1. כל לקוח הוא סביבת עבודה נפרדת בשגר. לפני כל פעולה הרץ list_workspaces ווודא שאתה בסביבת העבודה הנכונה. לעולם אל תשתמש בתוכן, בקישורים או בחשבונות של לקוח אחד אצל לקוח אחר. 2. מותר לך בלי לשאול: לקרוא (whoami, list_channels, list_groups, list_posts, get_post, get_analytics), להעלות מדיה וליצור טיוטות. 3. חייב לשאול לפני: schedule_post, יצירת פוסט עם schedule_at, cancel_post, request_approval, create_connect_link. 4. כל פוסט לכמה חשבונות נכתב עם per_channel וכיתוב שונה לכל חשבון. אין העתקה מילה במילה. 5. מועדים תמיד בפורמט ISO 8601 עם היסט מחושב לתאריך עצמו (שעון קיץ וחורף). 6. כשקריאה נכשלת, דווח את קוד השגיאה וההודעה כלשונם. אל תנסה לעקוף. 7. עברית: גוף ראשון רבים בשם המותג, פנייה בלשון רבים לקהל, בלי סימני קריאה כפולים ובלי אימוג'ים אלא אם הבריף של הלקוח מבקש. בסוף כל משימה החזר: מה עשית, מזהי הפוסטים שנוצרו, ומה מחכה להחלטה שלי. ``` ## פרומפט 2: הפצה שבועית מבריף ```text לקוח: "קפה אלמה", רשת של 14 בתי קפה. סביבת עבודה: "קפה אלמה". בריף השבוע: השקת תפריט סתיו. מנה מובילה: כריך חלומי צלוי עם בטטה. דף נחיתה: https://example.co.il/autumn-menu תמונה: https://cdn.example.co.il/alma/autumn-hero.jpg 1. הרץ את list_channels ואת list_groups. הצג לי אילו חשבונות פעילים ואילו דורשים חיבור מחדש. 2. העלה את התמונה עם upload_media_from_url. 3. צור טיוטה אחת לכל החשבונות בקבוצה "כל הסניפים", עם campaign בשם autumn-menu-2026. 4. כיתוב לכל חשבון: 2 עד 4 משפטים, מזכיר את העיר או השכונה של הסניף, בלי לחזור על אותו פתיח פעמיים. 5. בעמודי פייסבוק שים את דף הנחיתה בשדה first_comment, בניסוח שונה בכל עמוד. 6. אל תתזמן. טבלה: שם חשבון, רשת, כיתוב, תגובה ראשונה. מתחת לטבלה מזהה הטיוטה. ``` הטבלה בסוף היא מה שהופך את הפרומפט לשימושי. בעשרים שניות של קריאה רואים אם הסוכן הבין את הבריף. ## פרומפט 3: גיוון כיתובים לכל חשבון כשיש כבר כיתוב מאושר אחד, והמטרה היא לייצר ממנו וריאציות לכל חשבון בטיוטה חדשה. על הגישה עצמה כתבתי ב[מאמר על גיוון כיתובים](/blog/caption-variation-per-account-with-ai). ```text סתיו הגיע לאלמה. כריך חלומי צלוי עם בטטה, ויש גם שוקו חם עם קינמון. הרץ list_channels בסביבת העבודה "קפה אלמה" והשתמש בשם החשבון ובעיר שלו. 1. אותו מסר ואותה הצעה בכל הווריאציות. אסור להמציא מבצעים, מחירים או שעות פתיחה. 2. כל וריאציה פותחת אחרת: שאלה, תיאור, פנייה לשכונה, משפט על מזג האוויר. 3. אורך: עד 300 תווים. באינסטגרם אל תכלול קישור, כתוב "הקישור בביו". 4. בלי האשטגים, חוץ מ #אלמה בסוף, ורק באינסטגרם. צור טיוטה חדשה עם per_channel לכל חשבון, על בסיס הטיוטה הקיימת, וציין את המזהה החדש. אל תתזמן. ``` ## פרומפט 4: סרטון קצר לכל הרשתות ```text 1. העלה עם width, height וגם duration_ms. 2. פייסבוק ואינסטגרם: format REEL. יוטיוב: format SHORT, youtube_title עד 60 תווים, youtube_privacy unlisted. 3. כיתוב קצר ושונה לכל חשבון. ביוטיוב שורה ראשונה שמתארת את מה שרואים בסרטון. 4. stagger_seconds [60, 150]. 5. צור כטיוטה, הצג טבלה ועצור. ``` מה שמשנה כאן הוא `duration_ms`. בלי האורך, שַׁגֵּר לא יכול לבדוק מראש אם הסרטון מתאים לשורטס או לרילס. הרחבה על כך יש במדריך שלנו להפצת וידאו קצר עם סוכן. ## פרומפט 5: בדיקת איכות לפני תזמון את זה אני מריץ כשלב נפרד, לפעמים בשיחה חדשה, כדי שהסוכן יבדוק בעיניים רעננות ולא יאשר את העבודה של עצמו מתוך הקשר. ```text הרץ get_post על הטיוטה pst_4410 בסביבת העבודה "קפה אלמה" ובדוק אותה לפי הרשימה. אל תשנה כלום ואל תתזמן. 1. האם יש שני חשבונות או יותר עם כיתוב זהה או כמעט זהה? 2. האם יש בכיתוב מספר, מחיר, תאריך או הבטחה שלא מופיעים בבריף? 3. האם יש קישור בכיתוב של חשבון אינסטגרם? 4. האם שם העיר בכיתוב מתאים לחשבון? 5. שגיאות כתיב, לשון זכר ונקבה מעורבת, משפטים שנשמעים כמו תרגום. לכל ממצא: חשבון, מה הבעיה, ניסוח מתוקן מוצע. אם אין ממצאים, כתוב "עבר בדיקה". ``` ## פרומפט 6: דוח שבועי ללקוח ```text סביבת עבודה: "קפה אלמה". התקופה: 2026-09-07T00:00:00+03:00 עד 2026-09-13T23:59:59+03:00. 1. הרץ get_analytics לתקופה. 2. הרץ list_posts עם status PUBLISHED ועם status PARTIALLY_PUBLISHED. 3. לכל פוסט חלקי הרץ get_post ופרט אילו חשבונות נכשלו ולמה. כתוב דוח בעברית ללקוח, עד 200 מילים: 1. כמה פוסטים יצאו ולכמה חשבונות. 2. חמשת החשבונות עם הכי הרבה לחיצות, ומה פורסם בהם. 3. חשבונות בלי לחיצות בכלל. 4. תקלות ומה נעשה איתן. אל תכתוב מסקנות שאין להן נתון. לחיצות הן לא לידים, אל תקרא להן כך. ``` הסעיף האחרון חשוב. `get_analytics` מחזיר לחיצות על הקישורים של שַׁגֵּר לכל חשבון ולכל פוסט, לא לידים. כדי לדבר על לידים צריך לחבר את `utm_content` לנתונים במערכת CRM של הלקוח, כמו שמוסבר ב[מאמר על דוח לקוח שבועי בידי סוכן](/blog/weekly-client-report-by-agent). ## טעויות שחוזרות בפרומפטים לסוכני תוכן 1. **"תפרסם"** במקום "צור טיוטה". הסוכן יעשה בדיוק את מה שכתבתם. אם לא רציתם שיפרסם, אל תכתבו את המילה. 2. **בריף בלי גבולות עובדתיים.** אם לא כתבתם שאסור להמציא מחירים, יופיע מחיר. 3. **אין פורמט פלט.** בלי טבלה או רשימה בסוף, תקבלו פסקה ארוכה שקשה לבדוק. 4. **כל הלקוחות בשיחה אחת.** כשהקשר של לקוח אחד דולף ללקוח אחר, זו בעיה אמיתית מול הלקוח. שיחה לכל לקוח, או לפחות בדיקת סביבת עבודה לפני כל פעולה. 5. **אין הוראה לשגיאות.** סוכן בלי הוראה ינסה שוב ושוב, או יוותר בשקט. ## מאיפה ממשיכים הפרומפטים האלה עובדים כמו שהם בשיחה. כשאחד מהם הופך לשגרה שבועית, הוא צריך לעבור לסקיל, כדי שלא תעתיקו אותו כל פעם מחדש. [המדריך לבניית סקיל לְשַׁגֵּר](/blog/build-a-claude-skill-for-shager) מראה איך, וכל השדות שהפרומפטים משתמשים בהם מתועדים ב[מפרט OpenAPI של שַׁגֵּר](https://app.shager.ai/api/v1/openapi.json). ## שאלות נפוצות ### האם הפרומפטים עובדים גם עם Codex או Cursor? כן. הם לא תלויים במודל מסוים, רק בכך שהסוכן מחובר לשרת MCP של שַׁגֵּר ויכול להפעיל את הכלים. ייתכן שתצטרכו להתאים את המקום שבו שמים את ההוראות הקבועות, לפי הכלי. ### למה לא לתת לסוכן לתזמן ישר? כי טעות בפוסט אחד לשישים חשבונות היא שישים טעויות מול הלקוח. ברגע שהסוכן עבד כמה שבועות בלי ממצאים בבדיקת האיכות, אפשר לשקול לתת למפתח שלו הרשאת `publish` ולצמצם את נקודות העצירה. ### כמה ארוך צריך להיות פרומפט ההוראות הקבועות? קצר ככל האפשר, וכל כלל בו צריך להיות כלל שהסוכן באמת הפר או עלול להפר. אם תכניסו לשם את מדריך המותג כולו, הכללים החשובים ילכו לאיבוד. את מדריך המותג עדיף לשמור כקובץ נפרד שהסוכן קורא לפי הצורך. --- Source: https://shager.ai/blog/prompts-for-a-content-agent # סוכן שפותח לעצמו חשבון: הרשמה עצמית לסביבת הניסוי (sandbox) של שַׁגֵּר, ואיך אדם לוקח בעלות _2026-09-08 · איך סוכן AI נרשם לְשַׁגֵּר בלי עזרה אנושית: קריאת POST אחת לנתיב agent/signup, מה מותר בסביבת sandbox, מה חסום עד אישור, ואיך אדם מאשר את הבעלות ובוחר אם לאפשר פרסום._ סוכן AI יכול לפתוח לעצמו גישה לְשַׁגֵּר עם בקשת POST אחת לכתובת `https://app.shager.ai/api/v1/agent/signup`, כשהשדה היחיד שחובה לשלוח הוא `agent_name`. בתשובה הוא מקבל מפתח API, קישור אישור (`claim_url`) וכתובות לשרת MCP ולממשק REST. עם המפתח הזה הוא יכול מיד ליצור סביבות עבודה, להעלות מדיה ולהכין טיוטות, אבל לא לתזמן, לא לפרסם ולא לפנות ללקוחות, עד שאדם פותח את קישור האישור, נכנס לְשַׁגֵּר ולוקח בעלות. הרעיון מאחורי זה פשוט. סוכנים עובדים מהר יותר מבני אדם, וחבל שיחכו יומיים עד שמישהו יפתח חשבון וייצור מפתח. מצד שני, פרסום בשם עסק הוא פעולה שאדם צריך לאשר. ההרשמה העצמית מאפשרת לסוכן להתחיל את העבודה, ומשאירה את ההחלטה החשובה אצל אדם. זו לא פשרה בין מהירות לבטיחות, אלא חלוקת עבודה: הסוכן עושה את מה שאפשר לבטל, והאדם מחליט על מה שאי אפשר. ## איך נראית ההרשמה? הבקשה המלאה, עם כל השדות האופציונליים: ```bash curl -s -X POST https://app.shager.ai/api/v1/agent/signup \ -H "Content-Type: application/json" \ -d '{ "agent_name": "Acme marketing agent (Claude Code)", "contact_email": "dana@acme.co.il", "organization_name": "Acme", "purpose": "Prepare weekly Reels and Shorts drafts for 24 branch pages" }' ``` לכל שדה יש תפקיד: | שדה | חובה | למה הוא משמש | |---|---|---| | `agent_name` | כן | מזהה את הסוכן. כדאי שיהיה ברור לאדם שמאשר, למשל שם הלקוח והכלי | | `contact_email` | לא | האדם שהסוכן עובד בשבילו. הוא מקבל את קישור האישור | | `organization_name` | לא | שם הארגון שייווצר | | `purpose` | לא | הסבר קצר בשביל האדם שיאשר, מה הסוכן מתכוון לעשות | השדה `purpose` נראה כמו פרט שולי, אבל הוא נועד בדיוק לאדם שמחליט אם לאשר. "Prepare weekly drafts for 24 branch pages" אומר הרבה יותר מ "marketing". שווה לכתוב בהנחיות של הסוכן שימלא אותו בצורה ספציפית. ## מה חוזר בתשובה? התשובה, כמו כל תשובה של שַׁגֵּר, עטופה באובייקט `data`. השדות: | שדה | מה זה | |---|---| | `data.api_key` | מפתח API. מוצג פעם אחת בלבד | | `data.claim_url` | הקישור שאדם פותח כדי לאשר ולקחת בעלות | | `data.mcp_url` | כתובת שרת MCP | | `data.api_base` | כתובת הבסיס של ממשק REST API | | `data.openapi_url` | מפרט OpenAPI | | `data.expires_at` | מתי סביבת sandbox תפוג אם אף אחד לא יאשר אותו | הכלל הכי חשוב כאן: המפתח מוצג פעם אחת. סוכן שלא שומר אותו מיד, למשל במשתנה סביבה או בכספת סודות, יצטרך להירשם מחדש. וסוכן שמדפיס אותו ללוג פתוח חושף אותו לכל מי שקורא את הלוג. בעבודה עם Claude Code, למשל, הייתי מורה לסוכן לכתוב את המפתח לקובץ `.env` שמופיע בקובץ `.gitignore` ולא להציג אותו בצ'אט. ## מה מותר בסביבת sandbox ומה לא? | מותר לפני אישור | חסום עד שאדם מאשר | |---|---| | ליצור עד 5 סביבות עבודה | לתזמן או לפרסם פוסטים | | להעלות מדיה מכתובת URL | ליצור קישורי חיבור ללקוחות | | ליצור טיוטות | לשלוח בקשות אישור ללקוחות | | לקרוא ולרשום כל מה שקיים | | החלוקה הזו לא מקרית. כל מה שמותר הוא עבודה פנימית שאפשר למחוק בלי נזק. כל מה שחסום הוא פעולה שיוצאת החוצה: פוסט שעולה לעמוד אמיתי, קישור שנשלח ללקוח, מייל אישור שמגיע למישהו מחוץ לארגון. אם הסוכן מנסה פעולה חסומה, הוא מקבל שגיאה עם הקוד `sandbox_unclaimed`, וסוכן מנומס מבין מזה שהגיע הזמן לבקש מהאדם לאשר. ### מגבלות שכדאי להכיר sandbox שלא אושר פג אחרי 7 ימים. אפשר לבצע עד 5 הרשמות בשעה מאותה כתובת. ומכיוון שהמפתח עובד גם מול ממשק REST וגם מול שרת MCP, חלה עליו המגבלה הרגילה של 120 בקשות בדקה. ### איך האדם יודע שזה באמת הסוכן שלו? שאלה טובה, כי קישור אישור שמגיע במייל הוא בדיוק הדבר שאנשים זהירים לא לוחצים עליו סתם. שלושה דברים עוזרים. הראשון הוא שהקישור מגיע לכתובת שהסוכן מסר בשדה `contact_email`, וגם הסוכן עצמו מציג אותו בשיחה, כך שאפשר להשוות. השני הוא לשאול את הסוכן מה הוא שלח בשדות `agent_name` וגם `purpose`, ולוודא שזה תואם למה שביקשתם ממנו. אם משהו לא מסתדר, פשוט לא מאשרים, וסביבת sandbox תפוג מעצמה. השלישי הוא שגם אחרי האישור, כל פעולה של הסוכן נרשמת ביומן הביקורת, ומפתח שמתנהג בצורה לא צפויה מבטלים בלחיצה. ## איך אדם לוקח בעלות? האדם פותח את `claim_url`, נכנס לְשַׁגֵּר עם החשבון שלו (או פותח חשבון), ומאשר. בשלב הזה הוא מחליט דבר אחד חשוב: האם המפתח של הסוכן יקבל גם הרשאת `publish`, כלומר יוכל לתזמן ולפרסם בעצמו. שתי התשובות לגיטימיות. "לא" אומר שהסוכן ממשיך להכין טיוטות, ומעכשיו יכול גם לשלוח לקוחות לאישור וליצור קישורי חיבור, אבל אדם בצוות מתזמן. "כן" אומר שהסוכן יכול להשלים את כל המחזור לבד. ההמלצה שלנו לרוב הסוכנויות היא להתחיל עם "לא", לעבור על שבועיים של טיוטות, ורק אז להוסיף הרשאה. את זה עושים במסך הסוכנים בכתובת `https://app.shager.ai/dashboard/agents`, שבו גם רואים את יומן הביקורת של כל קריאה, ושם גם מבטלים מפתחות. באישור האדם הופך לבעלים של סביבת sandbox, ומה שהסוכן כבר הכין בו, סביבות עבודה, מדיה וטיוטות, מחכה לו שם. ## איך כותבים את זה בהנחיות של הסוכן? הנה קטע הנחיות שאפשר להדביק לסוכן, או להכניס לתוך skill: ```text If you have no Shager API key: 1. POST https://app.shager.ai/api/v1/agent/signup with agent_name, contact_email of the human you work for, and a specific purpose. 2. Save data.api_key to the secret store immediately. Never print it. 3. Tell the human: "I opened a Shager sandbox. Please open this link to review and claim it: . It expires on ." 4. Until claimed, only create workspaces, upload media and create drafts. 5. If you get sandbox_unclaimed, stop and remind the human to claim. ``` המתכון הזה, בגרסה מפורטת יותר, מתפרסם גם בקובץ [/auth.md](/auth.md), קובץ שנכתב במיוחד כדי שסוכנים יקראו אותו. סוכן שמגיע לְשַׁגֵּר בלי הכנה יכול למצוא אותו לבד, דרך `llms.txt` או דרך [עמוד הסוכנים](/agents). ## למה לא פשוט לתת לסוכן מפתח מוכן? לפעמים זה באמת עדיף. אם כבר יש לכם חשבון בְּשַׁגֵּר, אדם יוצר מפתח במסך הסוכנים, בוחר הרשאות ונותן לסוכן. זה המסלול הרגיל, והוא מוסבר במדריכים לחיבור [Claude Code](/blog/connect-shager-to-claude-code) וגם Cursor. ההרשמה העצמית שימושית בשלושה מצבים: כשמתחילים פרויקט חדש ועוד אין חשבון, כשסוכן עובד עבור מישהו שעדיין לא הכיר את שַׁגֵּר, וכשרוצים שהסוכן יכין סביבת עבודה שלמה עם טיוטות לפני שאדם משקיע בה זמן. במקרה האחרון האדם מקבל קישור, פותח, ורואה עבודה מוכנה במקום מסך ריק. גם הניסיון החינמי של 14 יום לא דורש כרטיס אשראי, כפי שמופיע ב[עמוד המחירים](/pricing). הצעד הבא, אחרי שסביבת sandbox אושרה, הוא לחבר חשבונות אמיתיים. הסוכן יוצר קישור חיבור עם `create_connect_link`, האדם או הלקוח פותחים אותו ומחברים את הפייסבוק, האינסטגרם או היוטיוב שלהם, ומשם הטיוטות יכולות לצאת לדרך. ## שאלות נפוצות ### מה קורה לעבודה של הסוכן אם אף אחד לא מאשר? אחרי 7 ימים סביבת sandbox פגה. הטיוטות והמדיה שנוצרו בו לא עוברות לשום מקום, ולכן אם הסוכן הכין משהו שחשוב לכם, כדאי לאשר לפני תאריך התפוגה שמופיע בשדה `expires_at`. ### האם הסוכן יכול לאשר את עצמו? לא. האישור דורש אדם שנכנס לְשַׁגֵּר דרך `claim_url` עם חשבון משלו. זו בדיוק הנקודה שבה אדם מחליט אם הסוכן יוכל לפרסם, ואין דרך לעקוף אותה דרך ממשק API. ### אפשר לשנות אחר כך את ההרשאות שנבחרו באישור? כן. במסך הסוכנים בְּשַׁגֵּר אפשר לבטל את המפתח וליצור מפתח חדש עם הרשאות אחרות, כולל הוספה או הסרה של `publish`. הסוכן פשוט מקבל את המפתח החדש. --- Source: https://shager.ai/blog/agent-self-signup-and-claim # עשרה כללי בטיחות לסוכן AI שמפרסם לעשרות חשבונות _2026-09-08 · לפני שנותנים לסוכן הרשאת פרסום לעשרות חשבונות, צריך כללים ברורים: הרשאה מינימלית, פיזור בזמן, ניסוח שונה לכל חשבון, בדיקת מדיה, מתג עצירה ויומן ביקורת._ סוכן AI שמפרסם בהיקף צריך לעבוד לפי כללים קשיחים, לא לפי שיקול דעת. הכללים החשובים ביותר הם הרשאה מינימלית, פיזור הפרסום בזמן, ניסוח שונה לכל חשבון, בדיקה של כל פוסט מול חוקי הרשת, ומתג עצירה שאדם יכול להפעיל בכל רגע. מה שמשותף לכולם הוא שהם נאכפים על ידי המערכת, ולא תלויים בכך שהסוכן יזכור אותם. הכללים כאן מבוססים על מה שהרשתות עצמן כותבות במדיניות שלהן, ועל מה שראיתי משתבש כשסוכנויות עוברות מפרסום ידני לפרסום אוטומטי. הם לא מבטיחים שאף חשבון לא ייחסם, כי אף אחד לא יכול להבטיח את זה. הם כן מצמצמים מאוד את הסיכון. ## מה הרשתות אומרות בפועל לפני הכללים, כדאי לדעת על מה מדובר. שלוש נקודות מתוך המדיניות הרשמית: 1. **Meta** אוסרת ב[מדיניות הספאם שלה](https://transparency.meta.com/policies/community-standards/spam/) פרסום, שיתוף או מעורבות בתדירות גבוהה מאוד, ידנית או אוטומטית, ומציינת שגם חשבונות שפועלים בתדירות נמוכה יותר עלולים להיות מוגבלים אם יש סימנים נוספים, כמו פרסום של תוכן חוזר. 2. **אינסטגרם** מגבילה כל חשבון למאה פוסטים שפורסמו דרך API בחלון נע של 24 שעות, לפי [התיעוד של Content Publishing](https://developers.facebook.com/docs/instagram-platform/content-publishing). קרוסלה נספרת כפוסט אחד. 3. **YouTube** אוסרת ב[מדיניות הספאם שלה](https://support.google.com/youtube/answer/2801973) שימוש בכלים אוטומטיים או בכלי AI כדי לייצר כמויות גדולות של תוכן דומה עם שינויים מינימליים, והמדיניות חלה גם על רשתות מתואמות של ערוצים. המסקנה פשוטה: הרשתות לא אוסרות אוטומציה. הן אוסרות התנהגות שנראית כמו הצפה ושכפול. הכללים שלמטה נועדו לוודא שהסוכן שלכם לא נראה כך, כי הוא באמת לא עושה את זה. ## עשרת הכללים ### 1. הרשאה מינימלית לכל מפתח לכל מפתח API בְּשַׁגֵּר יש שלוש הרשאות אפשריות: `read`, `write` וגם `publish`. סוכן שמכין דוחות לא צריך יותר מקריאה. סוכן שמכין טיוטות צריך כתיבה. הרשאת פרסום ניתנת רק אחרי תקופת הרצה, ולסביבת עבודה אחת בכל פעם. סוכן בלי `publish` פשוט לא יכול לתזמן, וזו ההגנה הכי חזקה שיש. ### 2. ארגז חול לפני הכל סוכן שנרשם לבד לְשַׁגֵּר עובד בארגז חול: הוא יכול ליצור טיוטות, להעלות מדיה ולקרוא, אבל לא לתזמן, לא לפרסם, לא ליצור קישורי חיבור ולא לשלוח בקשות אישור. רק אדם שתובע את הסביבה מחליט אם המפתח מקבל גם הרשאת פרסום. ארגז חול שלא נתבע פג אחרי שבעה ימים. את הפרטים תמצאו ב[מתכון ההרשמה לסוכנים](/auth.md). ### 3. פיזור בזמן בין חשבונות שישים פוסטים שיוצאים באותה שנייה נראים כמו בוט, כי זה מה שהם. בְּשַׁגֵּר השדה `stagger_seconds` קובע המתנה אקראית בין חשבונות של אותה רשת, וברירת המחדל היא בין 30 שניות לדקה וחצי. לקמפיינים גדולים במיוחד אפשר להגדיל את הטווח. אל תקטינו אותו לאפס כדי "לחסוך זמן". ### 4. ניסוח שונה לכל חשבון זה הכלל שהכי הרבה סוכנויות מדלגות עליו, והוא הכי חשוב מול מדיניות של תוכן חוזר. השדה `per_channel` בפעולה `create_post` מאפשר כיתוב, תגובה ראשונה ופורמט שונים לכל חשבון. השינוי צריך להיות אמיתי: פתיחה אחרת, פרט מקומי, ניסוח אחר של הקריאה לפעולה. החלפת מילה אחת לא נחשבת. הרחבתי על זה ב[מאמר על גיוון כיתובים עם AI](/blog/caption-variation-per-account-with-ai). ### 5. מטא דאטה מלא לכל וידאו כשהסוכן מעלה וידאו עם `upload_media_from_url`, הוא צריך לשלוח גם `width`, `height` וגם `duration_ms`. בלי זה אי אפשר לוודא מראש שהסרטון מתאים לפורמט Reel, Short או Story. סרטון שנדחה אחרי שכבר התחיל להתפרסם בחלק מהחשבונות הוא בדיוק סוג הבלגן שרוצים למנוע. ### 6. טיוטה לפני תזמון, תמיד גם סוכן עם הרשאת פרסום צריך ליצור קודם טיוטה, לבדוק אותה עם `get_post`, ורק אחר כך לתזמן עם `schedule_post`. אפשר ליצור פוסט מתוזמן בקריאה אחת עם `schedule_at`, אבל לקמפיינים גדולים אני ממליץ על שני שלבים. זה נותן נקודה שבה אדם או סוכן נוסף יכול לעצור. ### 7. כבוד למגבלת הקריאות המגבלה בממשק API של שַׁגֵּר היא 120 בקשות לדקה לכל מפתח. סוכן שמקבל שגיאה צריך להאט ולנסות שוב אחרי המתנה, לא לירות מחדש מיד. סוכן שמנסה לעקוף מגבלה עם כמה מפתחות במקביל עושה בדיוק את הדבר הלא נכון. ### 8. מתג עצירה מוכן מראש לפני כל קמפיין גדול, צריך לדעת איך עוצרים אותו. בְּשַׁגֵּר `cancel_post` מבטל פוסט מתוזמן שעוד לא התחיל להתפרסם, והוא חוזר להיות טיוטה מאושרת. ואם הבעיה היא בסוכן עצמו, מבטלים את המפתח בלוח הבקרה של הסוכנים. כתבו את הנוהל, ותוודאו שיותר מאדם אחד יודע אותו. ### 9. יומן ביקורת שמישהו קורא כל קריאה של סוכן נרשמת ביומן ביקורת בלוח הבקרה. יומן שאף אחד לא קורא הוא קישוט. קבעו מישהו שעובר עליו פעם בשבוע ומחפש קריאות לסביבות לא צפויות, כשלים חוזרים ושינויים חריגים בכמות. ### 10. רשימת נושאים אסורים יש תוכן שסוכן לא מפרסם לבד, אף פעם: תגובה לאירוע ביטחוני או חדשותי, תוכן בימי זיכרון, הבטחות משפטיות או רפואיות, ושינויי מחיר שלא אושרו בכתב. הרשימה הזו צריכה להיות חלק מההנחיות הקבועות של הסוכן, ובשבועות רגישים אדם עובר על כל מה שמתוזמן. ## רצף מומלץ לקמפיין גדול כך נראה קמפיין לשישים חשבונות כשכל הכללים מופעלים: ```text 1. list_channels(workspace_id) בודקים שכל החשבונות פעילים 2. upload_media_from_url(..., width, height, duration_ms) 3. create_post(workspace_id, caption, group_ids, media_ids, per_channel: [ניסוח שונה לכל חשבון], cta_url, campaign, stagger_seconds: [45, 120]) 4. get_post(workspace_id, post_id) בודקים את המצב לכל חשבון 5. request_approval(...) אם הסביבה דורשת אישור לקוח 6. schedule_post(workspace_id, post_id, schedule_at) 7. list_posts(workspace_id, status: "FAILED") אחרי הפרסום ``` השלב השביעי חשוב כמו הראשון. סוכן שמפרסם ולא בודק מה נכשל משאיר חורים שאף אחד לא יודע עליהם. ## מה שַׁגֵּר עושה בלי שהסוכן יצטרך לבקש חלק מההגנות לא תלויות בסוכן בכלל. שַׁגֵּר מפרסם רק דרך הממשקים הרשמיים של הרשתות, בלי כלים לא רשמיים ובלי לחקות התנהגות של משתמש. כל פוסט נבדק מול החוקים של הרשת שאליה הוא יוצא לפני שהוא נשלח, והשליחה מתפזרת בין חשבונות כברירת מחדל. בסביבה שדורשת אישור לקוח, ניסיון לתזמן פוסט שלא אושר נכשל. המטרה של המבנה הזה היא שגם סוכן שקיבל הנחיה גרועה יתקל בקיר לפני שהוא מזיק. ההנחיות הטובות הן השכבה השנייה, לא הראשונה. את הצד של אישור אנושי פירטתי ב[מאמר על נקודת העצירה לפוסטים של סוכן](/blog/human-approval-for-agent-posts), ואת הבסיס הכללי לפרסום בהיקף בלי חסימות ב[מדריך להימנעות מחסימות ספאם](/blog/avoid-spam-blocks-when-posting-at-scale). ## שאלות נפוצות ### האם פרסום דרך סוכן AI מסכן את החשבונות יותר מפרסום ידני? לא בהכרח. הרשתות מגבילות התנהגות של הצפה ושכפול, לא את הכלי שבו משתמשים. סוכן שמפרסם דרך ממשקים רשמיים, עם פיזור בזמן וניסוח שונה לכל חשבון, יכול להיות עקבי ובטוח יותר מאדם שמעתיק ומדביק את אותו טקסט בשישים עמודים. ### כמה פוסטים ביום מותר לפרסם בחשבון אינסטגרם דרך API? לפי התיעוד הרשמי של Meta, חשבון מוגבל למאה פוסטים שפורסמו דרך API בחלון נע של 24 שעות, וקרוסלה נספרת כאחד. זו תקרה טכנית, לא המלצה. לרוב העסקים קצב סביר רחוק מאוד ממנה. ### מה עושים אם סוכן התחיל לפרסם משהו שגוי? מבטלים עם `cancel_post` את כל מה שעוד לא התחיל להתפרסם, ואם צריך מבטלים את המפתח בלוח הבקרה. אחר כך בודקים ביומן הביקורת מה הסוכן עשה, ומוחקים ידנית ברשת עצמה פוסטים שכבר יצאו. את הכללים האלה כדאי להכניס ישירות להנחיות הקבועות של הסוכן, כחלק מהסקיל שהוא עובד לפיו. איך בונים סקיל כזה מוסבר ב[מדריך לבניית סקיל של Claude לְשַׁגֵּר](/blog/build-a-claude-skill-for-shager). --- Source: https://shager.ai/blog/safety-rules-for-agents-posting-at-scale # אסטרטגיית תזמון לסוכן: שעות, אזורי זמן, חגים וקצב פרסום בעשרות חשבונות _2026-09-08 · איך מלמדים סוכן AI לתזמן פוסטים בְּשַׁגֵּר בלי טעויות: schedule_at עם היסט, מעבר לשעון חורף, חגים ושבת, פריסה מדורגת, זמן לאישור לקוח ובדיקה אחרי הפרסום._ סוכן שמתזמן פוסטים צריך ארבעה כללים, לא יותר: לכתוב כל מועד בפורמט ISO 8601 עם היסט מפורש, לבדוק את המועד מול לוח החגים של הלקוח, להשאיר זמן לאישור ולפריסה המדורגת, ולבדוק אחרי הפרסום שהכל באמת עלה. רוב התקלות שראיתי בתזמון אוטומטי לא נבעו מהמודל אלא מהוראה עמומה כמו "תפרסם מחר בבוקר". המאמר הזה מסביר איך להפוך את ההוראה העמומה לכללים שסוכן יכול לבצע, עם הכלים של שַׁגֵּר: `create_post` עם `schedule_at`, `schedule_post` ו`cancel_post`. ## איך הסוכן כותב מועד כך שלא יהיו הפתעות? השדה `schedule_at` מקבל מועד בפורמט ISO 8601 עם היסט, למשל `2026-10-20T09:00:00+03:00`. המפרט ב[OpenAPI של שַׁגֵּר](https://app.shager.ai/api/v1/openapi.json) לא מקבל מועד בלי היסט או בלי `Z`, וזה מכוון. מועד בלי אזור זמן הוא ניחוש, וסוכן שרץ על שרת באירופה ינחש אחרת מסוכן שרץ על המחשב שלכם. בישראל יש פח מוכר: מעבר שעון. לפי [מסד אזורי הזמן של IANA](https://www.iana.org/time-zones), שעון הקיץ בישראל מסתיים השנה ביום ראשון, 25 באוקטובר 2026, וממנו ואילך ההיסט של `Asia/Jerusalem` הוא `+02:00` ולא `+03:00`. סוכן שמעתיק את ההיסט מהפוסט של שבוע שעבר יפרסם שעה מוקדם או מאוחר מדי. ההוראה הנכונה היא לחשב את ההיסט לכל תאריך מחדש, לא להעתיק אותו. סביבת עבודה חדשה בְּשַׁגֵּר נוצרת עם אזור זמן `Asia/Jerusalem` כברירת מחדל, ואפשר להעביר `timezone` אחר ב`create_workspace` ללקוח בחו"ל. כדאי שהסוכן יקרא את אזור הזמן של סביבת העבודה ויעבוד לפיו, ולא לפי אזור הזמן של המחשב שעליו הוא רץ. ## טיוטה קודם, תזמון אחר כך יש שתי דרכים לתזמן בְּשַׁגֵּר. אפשר לקרוא ל`create_post` עם `schedule_at`, ואז הפוסט נבדק ומתוזמן מיד. ואפשר ליצור טיוטה בלי `schedule_at`, להציג אותה, ורק אחר כך לקרוא ל`schedule_post` עם המועד. אני כמעט תמיד בוחר בדרך השנייה, משתי סיבות. הראשונה היא שהטיוטה נותנת נקודת עצירה. אדם יכול להסתכל, הלקוח יכול לאשר, והסוכן יכול לתקן. השנייה היא ש`schedule_post` נכשל עם סיבה ברורה אם חשבון כלשהו היה דוחה את הפוסט או אם חסר אישור לקוח, כך שהבדיקה קורית ברגע שבו עוד אפשר לתקן בנחת. ```json create_post { "workspace_id": "ws_dental_group", "label": "טיפ שבועי: הלבנה", "caption": "...", "group_ids": ["grp_all_clinics"], "media_ids": ["med_31ff"] } schedule_post { "workspace_id": "ws_dental_group", "post_id": "pst_9a02", "schedule_at": "2026-10-27T08:30:00+02:00" } ``` שימו לב שהתאריך בדוגמה הוא אחרי סוף שעון הקיץ, ולכן ההיסט הוא `+02:00`. תזמון ופרסום דורשים מפתח עם הרשאת `publish`. סוכן בסנדבוקס שעוד לא נתבע יקבל שגיאה `sandbox_unclaimed`, וזה בדיוק ההתנהגות הרצויה. על ההרשאות בהרחבה כתבתי ב[מאמר על מפתחות, הרשאות ויומן פעולות](/blog/api-keys-scopes-and-audit). ## כמה זמן לוקחת הפריסה המדורגת? מועד הפרסום הוא המועד שבו מתחיל הפרסום, לא המועד שבו כל החשבונות כבר מפורסמים. שַׁגֵּר מפרסם בכל חשבון בזמן מדורג משלו: בין חשבון לחשבון באותה רשת יש הפסקה אקראית בטווח `stagger_seconds`, שברירת המחדל שלו היא `[30, 90]` שניות. הסוכן צריך לדעת לחשב את זה. נוסחה פשוטה שמספיקה לתכנון: מספר החשבונות ברשת כפול ממוצע הטווח. עם ברירת המחדל הממוצע הוא שישים שניות, כך שארבעים עמודי פייסבוק יתפרסו על פני כארבעים דקות. אם הלקוח רוצה שהכל יהיה באוויר עד עשר, הסוכן מתחיל קודם. | מספר חשבונות ברשת | טווח `stagger_seconds` | זמן פריסה משוער | |---|---|---| | 10 | `[30, 90]` | כעשר דקות | | 40 | `[30, 90]` | כארבעים דקות | | 40 | `[60, 180]` | כשמונים דקות | | 120 | `[30, 90]` | כשעתיים | הטבלה היא חשבון, לא מדידה. בפועל העלאת וידאו לוקחת זמן נוסף בצד הרשת. ההמלצה שלי לסוכנים היא לא לקצר את הטווח מתחת לברירת המחדל כדי "לסיים מהר". הפריסה המדורגת היא חלק מההגנה על החשבונות, כמו שהסברתי ב[כללי הבטיחות לסוכנים שמפרסמים בהיקף](/blog/safety-rules-for-agents-posting-at-scale). ## חגים, שבת ומועדים מקומיים לוח השנה העברי זז ביחס ללוח הלועזי, ולכן "הפוסט של ראש השנה" לא נופל באותו תאריך כל שנה. בְּשַׁגֵּר יש לוח עם חגי ישראל, אבל הסוכן צריך גם הוראה מפורשת מה לעשות סביבם. דוגמה לכללים שאני כותב בהוראות הקבועות של סוכן שעובד עם לקוחות ישראלים: ```text כללי תזמון ללקוחות בישראל: 1. אל תתזמן פוסטים מכניסת שבת ועד צאתה ללקוחות שמסומנים "שומרי שבת" בבריף. 2. ערב חג נחשב כמו ערב שבת. בדוק את התאריך בלוח החגים לפני כל תזמון. 3. ביום הזיכרון וביום השואה אל תתזמן תוכן שיווקי. אם יש פוסט מתוזמן, עצור והתייעץ איתי. 4. פוסט ברכה לחג מתוזמן לבוקר של ערב החג, לא ליום החג עצמו. 5. אם המועד שביקשתי נופל על אחד מהמקרים האלה, אל תזיז אותו בעצמך. הצע שני מועדים חלופיים. ``` הסעיף השלישי חשוב במיוחד. סוכן לא יודע לבד שקמפיין מבצעים ביום הזיכרון הוא טעות, אלא אם אמרתם לו. ## מה עושים כשצריך לבטל? `cancel_post` מבטל תזמון של פוסט שעוד לא התחיל להתפרסם, והפוסט נשאר טיוטה מאושרת שאפשר לתזמן מחדש. אחרי שהפרסום התחיל, חלק מהחשבונות כבר מפורסמים, וביטול לא מחזיר אותם. לכן ההוראה לסוכן צריכה להיות ברורה: אירוע חדשותי, תקלה אצל הלקוח או בקשה דחופה לעצירה מתחילים ב`list_posts` עם `status` של `SCHEDULED`, ואז `cancel_post` לכל פוסט רלוונטי. ```bash curl "https://app.shager.ai/api/v1/workspaces/ws_dental_group/posts?status=SCHEDULED&limit=50" \ -H "Authorization: Bearer $SHAGER_API_KEY" curl -X POST "https://app.shager.ai/api/v1/workspaces/ws_dental_group/posts/pst_9a02/cancel" \ -H "Authorization: Bearer $SHAGER_API_KEY" ``` ## להשאיר זמן לאישור לקוח אם סביבת העבודה מוגדרת עם `approval_required`, פוסט לא יתוזמן בלי אישור. סוכן שמכין את התוכן ביום ראשון לפוסט של יום שני בבוקר מכניס את הלקוח ללחץ מיותר. כלל אצבע שעובד אצלנו: הטיוטה ובקשת האישור יוצאות לפחות יומיים עסקים לפני המועד, והסוכן בודק את סטטוס הפוסטים עם `list_posts` בבוקר שלפני. על תהליך האישור עצמו יש [מאמר נפרד](/blog/human-approval-for-agent-posts). ## בדיקה אחרי המועד תזמון לא נגמר בתזמון. הסוכן צריך לחזור לפוסט אחרי שהפריסה הסתיימה, לקרוא ל`get_post`, ולוודא שכל חשבון במצב פורסם. פוסט במצב `PARTIALLY_PUBLISHED` אומר שחלק מהחשבונות נכשלו, ו`get_post` מחזיר את הסיבה לכל אחד. זו נקודה שבה סוכן חוסך עבודה אמיתית: הוא רואה את הכשל לפני הלקוח. גם מגבלת הקצב רלוונטית כאן. שַׁגֵּר מאפשר 120 בקשות לדקה לכל מפתח, כך שסוכן שבודק מאה פוסטים בלולאה צריך לפזר את הבקשות או לחכות כשהוא מקבל `rate_limited`. כשהכללים האלה כתובים בהוראות של הסוכן, אפשר להעביר לו את לוח התוכן השבועי כולו. הצעד הבא הוא לארוז אותם כ[שגרת הפצה שבועית בתוך סקיל](/blog/skill-weekly-distribution-routine), ואם עוד לא חיברתם סוכן, [עמוד הסוכנים](/agents) מתחיל משם. ## שאלות נפוצות ### מה ההבדל בין schedule_at בתוך create_post לבין schedule_post? שניהם מתזמנים. `schedule_at` בתוך `create_post` יוצר ומתזמן בקריאה אחת, ו`schedule_post` מתזמן טיוטה או פוסט מאושר שכבר קיימים. כשיש אדם או לקוח שצריך לראות את הפוסט לפני, עדיף ליצור טיוטה ולתזמן אחר כך. ### האם אפשר לתת לסוכן לבחור את שעת הפרסום לבד? אפשר, אבל רק בתוך מסגרת שהגדרתם: חלונות זמן מותרים לכל לקוח, ימים אסורים ורשימת חגים. בלי מסגרת כזו הסוכן ימציא הנחות על "השעה הטובה ביותר" שאין לו נתונים לגביהן. ### מה קורה אם הסוכן שולח מועד בעבר? כדאי שההוראות יחייבו את הסוכן לבדוק את השעה הנוכחית באזור הזמן של סביבת העבודה לפני כל תזמון, ולעצור אם המועד כבר עבר. זה זול יותר מלגלות אחר כך שהפוסט לא יצא כמתוכנן. --- Source: https://shager.ai/blog/scheduling-strategy-for-agents # סוכן שמפיץ וידאו קצר: רילס, שורטס ועמודי פייסבוק מקובץ אחד _2026-09-02 · מדריך מעשי לסוכן AI שמפיץ סרטון קצר דרך שַׁגֵּר: העלאה עם מידות ואורך, בחירת פורמט לכל רשת, כותרת ליוטיוב, כיתוב שונה לכל חשבון ופריסה מדורגת בין העמודים._ סוכן יכול להפיץ סרטון קצר אחד לעשרות עמודי פייסבוק, חשבונות אינסטגרם וערוצי יוטיוב בתוך שיחה אחת, אם הוא עושה שלושה דברים נכון: מעלה את הקובץ עם המידות והאורך שלו, בוחר פורמט לכל רשת, וכותב כיתוב אחר לכל חשבון. בְּשַׁגֵּר זה רצף קצר של קריאות כלי, שהעיקריות בהן הן `upload_media_from_url`, `create_post` ואחר כך `get_post` לבדיקה. המדריך הזה מיועד למי שכבר חיבר סוכן לְשַׁגֵּר (אם עוד לא, [עמוד הסוכנים](/agents) מסביר איך) ורוצה להפסיק להעלות את אותו סרטון שלושים פעם ביד. ## מה הסוכן צריך לדעת על הקובץ לפני שהוא מעלה אותו? הטעות הנפוצה היא להעלות סרטון ולגלות רק בזמן הפרסום שהוא לא מתאים לפורמט. שַׁגֵּר בודק כל פוסט מול הכללים של כל רשת לפני השליחה, אבל כדי שהבדיקה של רילס, שורטס וסטוריז תהיה מדויקת, הסוכן צריך למסור את המידות ואת האורך כבר בהעלאה. הכלי `upload_media_from_url` מקבל `url` ציבורי של הקובץ, `file_name`, ובנוסף `width`, `height` ו`duration_ms`. אם הסרטון נוצר בכלי עריכה שמחזיר את הנתונים האלה, כדאי שהסוכן יעביר אותם כמו שהם. אם לא, עדיף שיריץ `ffprobe` על הקובץ מאשר שינחש. ```json upload_media_from_url { "workspace_id": "ws_client_rehovot", "url": "https://cdn.example.co.il/videos/open-house-oct.mp4", "file_name": "open-house-oct.mp4", "width": 1080, "height": 1920, "duration_ms": 42000 } ``` התשובה מחזירה מזהה מדיה. הסוכן שומר אותו ומשתמש בו ב`media_ids` של הפוסט. כמה עובדות שכדאי שהסוכן יכיר. יוטיוב מסווג סרטון כשורט כשהוא ריבועי או אנכי ואורכו עד שלוש דקות, וסרטון רחב יותר נחשב סרטון רגיל, לפי [מרכז העזרה של יוטיוב](https://support.google.com/youtube/answer/15424877). באינסטגרם, פרסום דרך API עובר דרך [ממשק פרסום התוכן הרשמי של Meta](https://developers.facebook.com/docs/instagram-platform/content-publishing/), ושם מתועדות דרישות הווידאו העדכניות. אל תכניסו לפרומפט מספרים מהזיכרון; תנו לבדיקה של שַׁגֵּר להחזיר שגיאה ברורה אם משהו לא עומד בדרישות. ## איך בוחרים פורמט לכל רשת? השדה `format` ב`create_post` מקבל את הערכים `FEED`, `REEL`, `STORY`, `SHORT` ו`VIDEO`. בלי השדה הזה שַׁגֵּר בוחר ברירת מחדל לכל רשת. כשרוצים שליטה, יש שתי דרכים: פורמט אחד לכל הפוסט, או פורמט לכל חשבון בתוך `per_channel`. | רשת | פורמט מתאים לסרטון אנכי קצר | שדות נוספים שכדאי למלא | |---|---|---| | עמוד פייסבוק | `REEL` | כיתוב, תגובה ראשונה עם קישור | | אינסטגרם מקצועי | `REEL` או `STORY` | כיתוב שונה לכל חשבון | | ערוץ יוטיוב | `SHORT` | `youtube_title`, `youtube_privacy` | ביוטיוב יש שני שדות ייעודיים. `youtube_title` הוא כותרת הסרטון, ואם לא מעבירים אותו שַׁגֵּר לוקח את השורה הראשונה של הכיתוב. `youtube_privacy` מקבל `public`, `unlisted` או `private`. לסוכן חדש אני ממליץ להתחיל ב`unlisted` בערוץ אחד, לבדוק את התוצאה, ורק אז לעבור ל`public`. שימו לב שתגובה ראשונה ביוטיוב יוצאת רק בסרטונים ציבוריים. ## רצף הקריאות המלא זה הרצף שאני נותן לסוכן כשהוא מפיץ סרטון קצר ללקוח עם שלוש רשתות: 1. `whoami` כדי לוודא שהמפתח לא בסנדבוקס ושיש לו הרשאת `publish`. 2. `list_workspaces` ובחירת סביבת העבודה של הלקוח. 3. `list_channels` כדי לקבל את מזהי החשבונות, הרשת של כל אחד והפורמטים שהוא תומך בהם. 4. `upload_media_from_url` עם מידות ואורך. 5. `create_post` בלי `schedule_at`, כטיוטה, עם `per_channel`. 6. אם סביבת העבודה דורשת אישור לקוח, `request_approval`. אחרת `schedule_post`. 7. אחרי מועד הפרסום, `get_post` כדי לראות מצב, קישור חי או שגיאה לכל חשבון. הקריאה החשובה היא החמישית. ככה היא נראית עם שני עמודי פייסבוק, חשבון אינסטגרם וערוץ יוטיוב: ```json create_post { "workspace_id": "ws_client_rehovot", "label": "בית פתוח אוקטובר, וידאו", "campaign": "open-house-oct", "caption": "בית פתוח ביום שישי בבוקר. סיור בדירות לדוגמה ושיחה עם צוות המכירות.", "media_ids": ["med_7c1a"], "format": "REEL", "cta_url": "https://example.co.il/open-house", "youtube_title": "בית פתוח ברחובות: סיור של 40 שניות", "youtube_privacy": "public", "stagger_seconds": [45, 120], "per_channel": [ { "channel_id": "ch_fb_rehovot", "caption": "רחובות, ביום שישי אנחנו פותחים את הדלתות. בואו לראות את הדירות לדוגמה מקרוב.", "first_comment": "פרטים והרשמה: https://example.co.il/open-house" }, { "channel_id": "ch_fb_nesziona", "caption": "גרים בנס ציונה? הפרויקט עשר דקות נסיעה מכם, ובשישי יש בית פתוח.", "first_comment": "לשריון מקום: https://example.co.il/open-house" }, { "channel_id": "ch_ig_brand", "caption": "40 שניות בתוך הדירה לדוגמה. בית פתוח בשישי, הקישור בביו." }, { "channel_id": "ch_yt_brand", "format": "SHORT", "caption": "סיור קצר בדירה לדוגמה לפני הבית הפתוח.\nפרטים: https://example.co.il/open-house" } ] } ``` כל כתובת שמופיעה בכיתוב או בתגובה הראשונה מוחלפת בזמן הפרסום בקישור מקוצר של שַׁגֵּר שייחודי לאותו חשבון, עם תגיות UTM שבהן `utm_content` מזהה את החשבון. כך, כשהלקוח שואל איזה עמוד הביא נרשמים לבית הפתוח, יש תשובה. על המבנה הזה בהרחבה כתבתי ב[מדריך לקישור בתגובה הראשונה עם סוכנים](/blog/first-comment-lead-links-with-agents). ## למה כיתוב אחר לכל חשבון ולא העתקה? כי אותו טקסט מילה במילה בשלושים עמודים נראה לרשתות ולגולשים כמו הפצה המונית, ובצדק. השדה `per_channel` קיים בדיוק בשביל זה, וְשַׁגֵּר ממליץ להשתמש בו. מודל שפה טוב יודע לכתוב עשרים וריאציות שנשמעות כמו אותו מותג אבל פונות לקהל של כל סניף. הפרומפטים שאני משתמש בהם לזה נמצאים ב[מאמר על גיוון כיתובים לכל חשבון](/blog/caption-variation-per-account-with-ai). ## פריסה מדורגת: מה `stagger_seconds` עושה בפועל שַׁגֵּר לא שולח את הסרטון לכל החשבונות באותה שנייה. בין חשבון לחשבון באותה רשת יש הפסקה אקראית בטווח `stagger_seconds`, וברירת המחדל היא `[30, 90]`. בסרטונים כדאי לשקול טווח רחב יותר, כי העלאת וידאו לוקחת זמן בצד הרשת. החשבון פשוט: עם ממוצע של דקה וחצי בין חשבונות, עשרים עמודי פייסבוק יתפרסו על פני חצי שעה בערך. אם זה חשוב ללקוח שהכל יעלה לפני תשע בבוקר, הסוכן צריך לתזמן בהתאם. ## איך הסוכן בודק שהכל עלה? `get_post` מחזיר את מצב הפוסט ואת המצב של כל חשבון: מתי פורסם, הקישור החי, או הודעת שגיאה. הסוכן צריך לקרוא את זה ולא רק לדווח "תוזמן". הוראה שאני מוסיף לכל סוכן: ```text אחרי מועד הפרסום, הרץ get_post. אם יש חשבון במצב שגיאה, אל תנסה לפרסם מחדש בעצמך. דווח לי את שם החשבון, את הודעת השגיאה כלשונה, והצע תיקון. ``` אם חשבון דורש חיבור מחדש, למשל כי ההרשאה בפייסבוק פגה, הפתרון הוא קישור חיבור ללקוח דרך `create_connect_link` ולא ניסיון חוזר. ## דוגמת REST למי שמריץ את זה מקוד אותן פעולות זמינות גם בממשק REST, לפי [מפרט OpenAPI](https://app.shager.ai/api/v1/openapi.json). העלאת הסרטון: ```bash curl -X POST "https://app.shager.ai/api/v1/workspaces/ws_client_rehovot/media" \ -H "Authorization: Bearer $SHAGER_API_KEY" \ -H "Content-Type: application/json" \ -d '{"url":"https://cdn.example.co.il/videos/open-house-oct.mp4","file_name":"open-house-oct.mp4","width":1080,"height":1920,"duration_ms":42000}' ``` והפוסט עצמו נשלח ל`POST /workspaces/{workspace_id}/posts` עם אותו גוף JSON שמופיע למעלה. ## פרומפט מלא להפצת סרטון ```text יש לך גישה לשגר דרך MCP. סביבת העבודה: "רחובות פרויקט צפוני". הסרטון: https://cdn.example.co.il/videos/open-house-oct.mp4 (אנכי, 1080x1920, 42 שניות). 1. העלה את הסרטון עם המידות והאורך. 2. צור טיוטה אחת לכל החשבונות בקבוצה "סניפים מרכז" ולערוץ היוטיוב. 3. פייסבוק ואינסטגרם כרילס, יוטיוב כשורט עם כותרת עד 60 תווים. 4. כתוב כיתוב שונה לכל חשבון, שמזכיר את העיר של הסניף. בלי סימני קריאה כפולים. 5. בפייסבוק שים את הקישור https://example.co.il/open-house בתגובה הראשונה. 6. אל תתזמן. הראה לי טבלה של חשבון, פורמט וכיתוב, וחכה לאישור. ``` השלב האחרון הוא העיקר. סוכן שמראה טבלה לפני שהוא מתזמן חוסך לכם את רוב הטעויות. אם אתם עדיין בלי מפתח, הסוכן יכול לפתוח סנדבוקס בעצמו לפי [המתכון שבקובץ auth.md](/auth.md), להעלות את הסרטון וליצור טיוטות, ואתם תאשרו את הפרסום כשתהיו מוכנים. משם הצעד הטבעי הוא [אסטרטגיית התזמון](/blog/scheduling-strategy-for-agents) שתקבע מתי הסרטונים האלה יוצאים. ## שאלות נפוצות ### האם הסוכן יכול לפרסם את אותו סרטון גם כרילס וגם כסטורי באינסטגרם? כן, אבל כשני פוסטים נפרדים או כשתי שורות ב`per_channel` לחשבונות שונים. לחשבון אחד יש פורמט אחד בכל פוסט. אם רוצים את שניהם באותו חשבון, הסוכן יוצר פוסט נוסף עם `format` של `STORY`. ### מה קורה אם הסרטון ארוך מדי לשורטס? שַׁגֵּר בודק את הפוסט מול כללי הרשת ומחזיר שגיאה עם הסבר לפני השליחה, ולכן חשוב להעביר `duration_ms` בהעלאה. הסוכן צריך לדווח על השגיאה ולהציע לפרסם ביוטיוב כסרטון רגיל עם `format` של `VIDEO`, או לקצר את הקובץ. ### אפשר להפיץ לטיקטוק או ללינקדאין? עוד לא. טיקטוק ולינקדאין בפיתוח בְּשַׁגֵּר. היום הפרסום זמין לעמודי פייסבוק, לחשבונות אינסטגרם מקצועיים ולערוצי יוטיוב. --- Source: https://shager.ai/blog/agent-short-video-distribution # איך מודדים לידים מתוכן שסוכן AI הפיץ: חשבון אחרי חשבון, פוסט אחרי פוסט _2026-09-01 · סוכן שמפיץ לעשרות חשבונות חייב לייצר במקביל גם מדידה ברמת החשבון. כך בונים שיוך לידים עם UTM, קישור מקוצר לכל חשבון, הפעולה get_analytics וחיבור למערכת CRM._ מודדים לידים מתוכן של סוכן בדיוק כמו שמודדים לידים מתוכן של אדם, רק שאין תירוץ לדלג על שום שלב. כל חשבון מקבל קישור מקוצר ותיוג UTM משלו, הלחיצות נספרות לכל חשבון ולכל פוסט, והמזהה של החשבון עובר בטופס עד למערכת CRM של הלקוח. ההבדל הוא שסוכן יכול לעשות את כל זה בכל פוסט, בלי שאף אחד ישכח. אני מתחיל מהנחה פשוטה: אם סוכן מפיץ תוכן לשישים חשבונות ואין לכם דרך לדעת איזה מהם הביא לידים, לא חסכתם זמן. העברתם את הבלבול ממקום אחד למקום אחר. ## למה מדידה היא חלק מההפצה ולא שלב אחריה ברוב הסוכנויות מדידה היא משהו שקורה בסוף החודש. מישהו פותח את האנליטיקס, רואה "תנועה מפייסבוק", ומנסה לנחש מה עבד. השאלה של הלקוח, מאיזה סניף הגיעו הפניות, נשארת בלי תשובה. הסיבה היא שהמידע לא נוצר בזמן הפרסום. אם הקישור בפוסט של סניף חיפה זהה לקישור בפוסט של סניף באר שבע, שום דוח לא יפריד ביניהם אחר כך. השיוך נבנה ברגע שבו הקישור נוצר, ולכן הוא צריך להיות חלק מהפעולה שיוצרת את הפוסט. כתבתי מדריך מפורט על השכבות עצמן ב[מאמר על UTM לכל חשבון ושיוך לידים](/blog/utm-per-account-lead-attribution). כאן אני מתמקד במה שמשתנה כשסוכן מריץ את התהליך. ## השכבות, ומי אחראי על כל אחת | שכבה | מה היא מודדת | מי יוצר אותה | |---|---|---| | תיוג UTM לכל חשבון | ביקורים באתר לפי חשבון, באנליטיקס | שַׁגֵּר, אוטומטית מתוך `cta_url` | | קישור מקוצר לכל חשבון | לחיצות לפי חשבון ולפי פוסט, בצד השרת | שַׁגֵּר, אוטומטית מתוך `cta_url` | | שדות נסתרים בטופס | לידים לפי חשבון במערכת הלקוח | האתר של הלקוח, פעם אחת | | הצלבה ודוח | יחס בין לחיצות, ביקורים ולידים | הסוכן מכין, אדם מפרש | פרמטרי UTM הם הסטנדרט שכלי אנליטיקס קוראים כדי לשייך ביקורים לקמפיין. גוגל מתעדת את הפרמטרים הנתמכים ב[מדריך של Google Analytics לאיסוף נתוני קמפיין](https://support.google.com/analytics/answer/10917952). בְּשַׁגֵּר, utm_content מזהה את החשבון, והשדה `campaign` של הפוסט הופך לערך של utm_campaign. ## מה הסוכן צריך לעשות בכל פוסט כשהסוכן יוצר פוסט עם `create_post`, ארבעה שדות קובעים אם המדידה תעבוד: 1. **`cta_url`**: כתובת היעד. מכאן שַׁגֵּר מייצר לכל חשבון קישור מקוצר ותיוג UTM נפרד. בלי השדה הזה אין שיוך. 2. **`campaign`**: שם הקמפיין, באותיות קטנות ובאנגלית, לפי מוסכמה קבועה. הסוכן צריך לקבל את המוסכמה בהנחיות, לא להמציא שם בכל פעם. 3. **`first_comment`**: התגובה הראשונה. בעמודי פייסבוק וביוטיוב נוח לשים בה את הקריאה לפעולה עם הקישור. באינסטגרם קישורים בכיתוב ובתגובות לא לחיצים, ולכן שם צריך לחשוב על הקישור אחרת. 4. **`label`**: שם פנימי לפוסט, כדי שבדוח יהיה ברור על מה מדובר בלי לפתוח כל פוסט. הנה דוגמה לגוף קריאה: ```json { "workspace_id": "ws_...", "caption": "פתחנו הרשמה לסדנת הקיץ", "group_ids": ["grp_north", "grp_south"], "cta_url": "https://example.co.il/summer-workshop", "campaign": "summer-workshop-2026", "label": "סדנת קיץ, גל ראשון", "first_comment": "פרטים והרשמה בקישור", "per_channel": [ { "channel_id": "ch_haifa", "caption": "חיפה, פתחנו הרשמה לסדנת הקיץ בסניף שלכם" } ] } ``` על הנושא של קישור הלידים בתגובה הראשונה כתבתי בנפרד ב[מאמר על תגובה ראשונה עם קישור לידים](/blog/first-comment-lead-links-with-agents). ## איך הסוכן קורא את הנתונים הפעולה `get_analytics` מחזירה לחיצות על הקישורים של שַׁגֵּר בטווח תאריכים, וברירת המחדל היא שלושים הימים האחרונים. התשובה כוללת סך לחיצות, רשימה לפי חשבון (עם שם החשבון והרשת) ורשימה לפי פוסט, ממוינות מהגבוה לנמוך. זה מספיק כדי לענות על השאלות הראשונות: 1. אילו חשבונות מביאים לחיצות ואילו לא מביאים כמעט כלום. 2. אילו פוסטים עבדו, בלי קשר לחשבון. 3. האם יש פער גדול בין רשתות. אבל לחיצות הן לא לידים. כדי לדעת כמה פניות הגיעו מכל חשבון, הנתון צריך להגיע למערכת של הלקוח. ## החוליה שסוכנים לא יכולים לבנות לבד: הטופס בדף הנחיתה צריכים להיות שדות נסתרים שקולטים את פרמטרי UTM מהכתובת ושולחים אותם עם הליד. זו עבודה של פעם אחת, אבל בלעדיה כל המדידה נעצרת בלחיצה. רשימת בדיקה קצרה: 1. בטופס יש שדות נסתרים לפחות עבור utm_source, utm_campaign וגם utm_content. 2. הערכים נשמרים גם אם הגולש עובר בין כמה עמודים לפני שהוא משאיר פרטים, בכפוף למדיניות הפרטיות ולהסכמה שנדרשת. 3. במערכת CRM השדות ממופים לשדות קבועים, לא נכנסים להערות. 4. נשלח ליד ניסיון מכל קבוצת חשבונות, ונבדק שהמקור הגיע נכון. אם הלקוח עובד גם עם וואטסאפ וטלפון, חלק מהפניות יעקפו את הטופס. אפשר לצמצם את הפער עם הודעה מוכנה בקישור לוואטסאפ שכוללת קוד קצר של החשבון. זה לא מושלם, אבל זה עדיף על לנחש. ## פרומפט לניתוח שבועי הנה פרומפט שאני נותן לסוכן בסוף כל שבוע, כשהוא מחובר לְשַׁגֵּר דרך MCP: ```text בסביבת העבודה של הלקוח, הרץ get_analytics לשבעת הימים האחרונים ולשבעת הימים שלפניהם. 1. הצג טבלה של עשרת החשבונות עם הכי הרבה לחיצות, עם השינוי מהשבוע הקודם. 2. הצג את החשבונות שלא קיבלו אף לחיצה, ובדוק עם list_posts אם בכלל פורסם בהם משהו. 3. הצלב את by_post עם list_posts כדי להציג שם (label) לכל פוסט. 4. אל תסיק מסקנות על לידים. אני אוסיף את נתוני CRM בעצמי. ``` הסעיף הרביעי חשוב. סוכן שרואה לחיצות נוטה לכתוב "הקמפיין הצליח". לחיצות הן אינדיקציה, וההחלטה אם קמפיין הצליח שייכת למי שרואה את הלידים ואת המכירות. את המבנה של דוח שבועי מלא, כולל מה שולחים ללקוח, תיארתי ב[מדריך לדוח לקוח שבועי של סוכן](/blog/weekly-client-report-by-agent). ## איך קוראים את הפערים כשיש שלוש עמודות, לחיצות מהקישור המקוצר, ביקורים מהאנליטיקס ולידים ממערכת CRM, הפערים ביניהן הם מידע: | מה רואים | מה זה כנראה אומר | |---|---| | הרבה לחיצות, מעט ביקורים | בעיה בטעינת הדף, בעוגיות או בהסכמה | | הרבה ביקורים, מעט לידים | בעיה בהצעה, בטופס או בהתאמה לקהל | | חשבון עם אפס לחיצות לאורך זמן | קהל לא פעיל, פוסט שלא פורסם, או ניסוח שלא עובד | | פער גדול בין חשבונות דומים | הזדמנות לבדוק מה שונה בניסוח או בקהל | הסוכן יכול לזהות את הדפוסים האלה ולהציף אותם. הוא לא צריך להחליט מה לעשות איתם. ## שאלות נפוצות ### האם שַׁגֵּר סופר לידים או רק לחיצות? שַׁגֵּר סופר לחיצות על הקישורים המקוצרים שלו, לכל חשבון ולכל פוסט. הלידים עצמם נמצאים במערכת של הלקוח, ולכן צריך שדות נסתרים בטופס שיעבירו את פרמטרי UTM, ובמיוחד את utm_content שמזהה את החשבון. ### מה קורה אם לא מגדירים cta_url בפוסט? הפוסט ייצא, אבל בלי קישור מקוצר ובלי תיוג לכל חשבון, כך שלא יהיה שיוך. אני ממליץ להגדיר לסוכן כלל קבוע: כל פוסט עם קריאה לפעולה חייב `cta_url`. ### אפשר למשוך את הנתונים ישירות לגיליון או לכלי BI? כן. אותה פעולה זמינה גם דרך REST API, עם תיאור מלא ב[מפרט OpenAPI](https://app.shager.ai/api/v1/openapi.json). אפשר לכתוב סקריפט קצר שמושך את הנתונים כל לילה, או לתת לסוכן להכין את הטבלה. אם אתם מתחילים, תנו לסוכן קמפיין אחד שבו מוגדרים גם `cta_url` וגם `campaign`, ושלחו ליד ניסיון אחד מכל קבוצת חשבונות. ברגע שהמקור מגיע נכון למערכת של הלקוח, כל פוסט עתידי כבר נמדד. את נקודת הכניסה לחיבור הסוכן תמצאו ב[עמוד הסוכנים](/agents). --- Source: https://shager.ai/blog/measuring-leads-from-agent-content # שַׁגֵּר וגם ChatGPT: למה המחבר עוד לא עובד, ואילו שלוש דרכים כן עובדות היום _2026-09-01 · ChatGPT מתחבר לשרתי MCP רק עם OAuth או בלי אימות, וְשַׁגֵּר עובד היום עם מפתח API. הסבר כן על הפער, ושלוש דרכים מעשיות לעבוד עם מודלים של OpenAI וְשַׁגֵּר כבר עכשיו._ נכון להיום אי אפשר לחבר את שַׁגֵּר כמחבר (app) בתוך ChatGPT. הסיבה פשוטה: ChatGPT מתחבר לשרתי MCP עם OAuth או בלי אימות בכלל, ולא יודע לשלוח מפתח API בכותרת, וְשַׁגֵּר מאמת סוכנים היום במפתח API בכותרת `Authorization`. התחברות OAuth לשרת MCP של שַׁגֵּר נמצאת בפיתוח. עד שהיא תעלה, יש שלוש דרכים שעובדות: Codex CLI של OpenAI, ממשק Responses API עם כלי MCP מרוחק, או קוד שקורא לממשק REST API של שַׁגֵּר. המאמר הזה נכתב כי השאלה "איך מחברים את שַׁגֵּר אל ChatGPT" מגיעה אלינו לא מעט, ועדיף תשובה ישרה מאשר מדריך שנתקע בשלב האחרון. ## למה ChatGPT לא יכול להתחבר עם מפתח API? OpenAI מתעדת את זה במפורש. בעמוד [האימות של Apps SDK](https://developers.openai.com/apps-sdk/build/auth) נכתב ששרת MCP מאומת צריך לממש OAuth 2.1 לפי מפרט ההרשאות של MCP, ושכלים יכולים גם לפעול בלי אימות. באותו עמוד כתוב שהמערכת ChatGPT לא תומך בהרשאות מכונה מול מכונה ולא יכול להציג מפתחות API מותאמים. כלומר, אין שדה שבו מדביקים `Bearer shgr_live_…` ושום הגדרה לא תעקוף את זה. מצב המפתחים (developer mode) של ChatGPT מאפשר להוסיף שרתי MCP מרוחקים שלא עברו פרסום, אבל גם הוא עובד עם אותן אפשרויות אימות: OAuth, בלי אימות, או שילוב של השניים. הזמינות של מצב המפתחים ושל פעולות כתיבה משתנה לפי סוג החשבון, ולכן כדאי לבדוק מה מופיע אצלכם בהגדרות. בכל מקרה, זה לא פותר את בעיית המפתח. ### ולמה שַׁגֵּר לא פשוט פותח את השרת בלי אימות? כי שרת MCP של שַׁגֵּר יכול לפרסם פוסטים בעמודים של לקוחות. שרת כזה בלי אימות הוא לא אופציה. המפתחות של שַׁגֵּר מחולקים להרשאות `read`, `write` או `publish`, כל קריאה נרשמת ביומן ביקורת, ואדם יכול לבטל מפתח בכל רגע. OAuth ישמור על כל זה ויוסיף כניסה רגילה מתוך ChatGPT. עד אז, עדיף לחכות מאשר להחליש את מודל ההרשאות. ## שלוש דרכים שעובדות היום | דרך | למי מתאים | מה צריך | |---|---|---| | Codex CLI | מי שעובד בטרמינל או בריפו | מפתח שַׁגֵּר במשתנה סביבה ושלוש שורות בקובץ config.toml | | Responses API עם כלי MCP | מפתחים שבונים סוכן משלהם על מודלים של OpenAI | קוד שקורא לממשק API של OpenAI ומעביר את מפתח שַׁגֵּר | | REST API של שַׁגֵּר מקוד | אוטומציות, CI, אינטגרציות למערכות קיימות | בקשות HTTP רגילות לפי OpenAPI | ### דרך ראשונה: Codex CLI Codex הוא הסוכן של OpenAI לעבודה בטרמינל, והוא תומך בשרתי MCP מרוחקים עם טוקן Bearer ממשתנה סביבה. זו הדרך הקרובה ביותר לחוויה של "ChatGPT שמדבר עם שַׁגֵּר": אותם מודלים, צ'אט בשפה חופשית, וגישה לכל הכלים של שַׁגֵּר. ההגדרה המלאה, כולל בדיקה ראשונה, נמצאת במדריך [לחיבור שַׁגֵּר אל Codex](/blog/connect-shager-to-codex). ### דרך שנייה: Responses API עם כלי MCP מרוחק אם אתם בונים סוכן משלכם על ממשק API של OpenAI, [התיעוד של כלי MCP בממשק Responses API](https://developers.openai.com/api/docs/guides/tools-connectors-mcp) מתאר כלי מסוג `mcp` עם `server_url`, ושדה `authorization` שבו מעבירים את הטוקן. ממשק API לא שומר את הערך, ולכן שולחים אותו בכל בקשה. עבור שַׁגֵּר, הגדרת הכלי נראית בערך כך: ```json { "type": "mcp", "server_label": "shager", "server_url": "https://app.shager.ai/api/mcp", "authorization": "shgr_live_XXXXXXXXXXXXXXXX", "require_approval": "always" } ``` שימו לב לשדה `require_approval`. לפי התיעוד, ברירת המחדל היא לבקש אישור לפני ששולחים מידע לשרת MCP, ואפשר להגדיר `"never"` לכל הכלים או לפטור רק כלים מסוימים. בְּשַׁגֵּר הייתי משאיר אישור על כלים שכותבים, ופוטר רק כלים שקוראים כמו `list_channels`, `list_posts` וגם `get_analytics`. ואם האפליקציה שלכם רצה בצד הלקוח, המפתח לא אמור להגיע לדפדפן. הוא נשאר בשרת שלכם. ### דרך שלישית: REST API מקוד לפעמים לא צריך סוכן שבוחר כלים בעצמו. מספיק סקריפט: ChatGPT או מודל אחר כותב את הכיתובים, והקוד שלכם שולח אותם לְשַׁגֵּר. כל הפעולות של שַׁגֵּר זמינות בממשק REST תחת `https://app.shager.ai/api/v1`, והמפרט המלא נמצא בקובץ [OpenAPI של שַׁגֵּר](https://app.shager.ai/api/v1/openapi.json). דוגמה ליצירת טיוטה: ```bash curl -s -X POST \ "https://app.shager.ai/api/v1/workspaces/$WORKSPACE_ID/posts" \ -H "Authorization: Bearer $SHAGER_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "caption": "מבצע הסתיו מתחיל ביום ראשון", "group_ids": ["GROUP_ID"], "cta_url": "https://example.com/autumn", "first_comment": "כל הפרטים בקישור" }' ``` התשובה חוזרת במבנה `{ "data": … }`, ושגיאות חוזרות במבנה `{ "error": { "code", "message" } }`. המדריך [המהיר לממשק REST API של שַׁגֵּר](/blog/shager-rest-api-quickstart) עובר על כל הזרימה, מהקריאה `whoami` ועד אנליטיקס. ## ומה עם עבודה ידנית בתוך ChatGPT? אפשר כמובן להמשיך להשתמש בצ'אט ChatGPT לכתיבה ולהעתיק את התוצאה לְשַׁגֵּר. זה עובד, אבל זה בדיוק השלב שבו נאבד הערך של עבודה ברמת החשבון. כשמעתיקים טקסט אחד, כל העמודים מקבלים אותו ניסוח. כשסוכן עובד מול שַׁגֵּר ישירות, הוא ממלא `per_channel` עם ניסוח שונה לכל עמוד, וְשַׁגֵּר מצמיד לכל עמוד קישור מקוצר ותגיות UTM משלו. ההבדל מורגש כבר בדוח הראשון, כשרואים לחיצות לפי סניף ולא מספר אחד מאוחד. ויש גם עניין של זמן: העתקה ידנית לעשרות עמודים היא בדיוק העבודה שסוכנות רוצה להוציא מהשבוע של מנהלת התיק. ### שילוב ביניים שעובד טוב אם הצוות שלכם רגיל לכתוב בצ'אט ChatGPT ולא רוצה לוותר על זה, יש פשרה סבירה. מבקשים מהמודל ChatGPT להחזיר את הכיתובים בפורמט JSON, עם מפתח לכל חשבון וטקסט שונה לכל אחד, במבנה שתואם את השדה `per_channel` של שַׁגֵּר. את הקובץ הזה סקריפט קצר שולח לפעולה `create_post` כטיוטה. ככה הכתיבה נשארת בכלי שהצוות מכיר, הניסוח שונה לכל עמוד, ואף אחד לא מעתיק ומדביק ארבעים פעמים. החיסרון הוא שעדיין יש שלב ידני באמצע, ושהמודל לא רואה את רשימת החשבונות האמיתית. לכן כדאי לתת לו בפרומפט את שמות החשבונות והמזהים שלהם כפי שהם מופיעים בפעולה `list_channels`, ולא לתת לו לנחש. ## מה ישתנה כש OAuth של שַׁגֵּר יעלה כשהתחברות OAuth תהיה זמינה, ההוספה בצ'אט ChatGPT תהיה כמו כל מחבר אחר: מזינים את כתובת השרת, נכנסים לְשַׁגֵּר, מאשרים הרשאות. ההרשאות עצמן לא ישתנו. אדם עדיין יבחר אם הסוכן יכול רק להכין טיוטות או גם לפרסם, וכל פעולה עדיין תירשם ביומן. נעדכן את המאמר הזה כשזה יקרה, וגם את [עמוד הסוכנים](/agents), שמרכז את כל דרכי החיבור. עד אז, ההמלצה המעשית: אם אתם בצוות שכבר עובד עם מודלים של OpenAI, התחילו עם Codex. אם אתם בונים מוצר, לכו על ממשק Responses API או על ממשק REST API. ואם המטרה היא פשוט לעבוד עם סוכן מול שַׁגֵּר בצ'אט, Claude Code וגם Cursor תומכים בכותרות כבר היום. ## שאלות נפוצות ### מתי שַׁגֵּר יתמוך בצ'אט ChatGPT כמחבר? כשהתחברות OAuth לשרת MCP של שַׁגֵּר תעלה. היא נמצאת בפיתוח, ואין לנו תאריך שאנחנו מוכנים להתחייב אליו. עד אז, שלוש הדרכים במאמר עובדות במלואן. ### אפשר לעקוף את זה עם שרת ביניים בלי אימות? טכנית אפשר לבנות שרת ביניים שמחזיק את המפתח ופתוח לכל מי שיודע את הכתובת, אבל זה אומר שכל אחד עם הכתובת יכול לפרסם בעמודים של הלקוחות שלכם. אנחנו ממליצים בחום לא לעשות את זה. ### האם הגבלות הקצב שונות בין MCP לבין REST? המגבלה היא 120 בקשות בדקה לכל מפתח. מכיוון שכלי MCP מקבילים לפעולות REST, אותה מגבלה רלוונטית לשתי הדרכים, ולכן עדיף לעבוד באצוות ולא לבצע קריאה נפרדת לכל חשבון. --- Source: https://shager.ai/blog/shager-and-chatgpt # שַׁגֵּר בתוך Cursor: קובץ mcp.json אחד, והסוכן שבונה את דף הנחיתה גם מפיץ אותו _2026-08-25 · מדריך לחיבור שַׁגֵּר אל Cursor דרך .cursor/mcp.json: כתובת השרת, כותרת Authorization עם משתנה סביבה, הבדל בין הגדרה לפרויקט לגלובלית, ותרחיש עבודה שלם מהקוד להפצה._ כדי לחבר את שַׁגֵּר אל Cursor יוצרים קובץ `.cursor/mcp.json` בפרויקט (או `~/.cursor/mcp.json` לכל הפרויקטים), מגדירים בו שרת בשם `shager` עם `"url": "https://app.shager.ai/api/mcp"`, ומוסיפים אובייקט `headers` עם `"Authorization": "Bearer ${env:SHAGER_API_KEY}"`. Cursor קורא את המפתח ממשתנה הסביבה, מתחבר לשרת דרך Streamable HTTP, והכלים של שַׁגֵּר זמינים לסוכן בצ'אט. מהרגע הזה אותו סוכן שעורך לכם את הקוד יכול גם להכין טיוטות הפצה לעשרות חשבונות. למה זה מעניין דווקא בעורך Cursor? כי הרבה עבודה שיווקית מתחילה בקוד: דף נחיתה לקמפיין, עמוד מוצר חדש, מאמר בבלוג. ברגע שהדף עולה, מישהו צריך להפיץ אותו. כשהסוכן שבנה את הדף יודע גם מה המסר, מה הקהל ומה הקישור, חבל להעביר את כל זה ידנית לכלי אחר. ## איך נראית ההגדרה? [התיעוד של Cursor על MCP](https://cursor.com/docs/context/mcp) מתאר שני מיקומים לקובץ ההגדרות ותחביר אחד לשרתים מרוחקים: שדה `url` ואובייקט `headers` אופציונלי, תחת `mcpServers`. עבור שַׁגֵּר: ```json { "mcpServers": { "shager": { "url": "https://app.shager.ai/api/mcp", "headers": { "Authorization": "Bearer ${env:SHAGER_API_KEY}" } } } } ``` התחביר `${env:NAME}` חשוב כאן. לפי התיעוד, Cursor מחליף משתני סביבה בשדות `url` וגם `headers`, כך שהמפתח לא נשמר בקובץ. בלי זה, המפתח היה יושב כטקסט גלוי בתיקייה שבדרך כלל נכנסת למאגר git. ### פרויקט או גלובלי? | מיקום | מתי לבחור | |---|---| | `.cursor/mcp.json` בתוך הפרויקט | כשהחיבור רלוונטי לריפו מסוים, למשל אתר של לקוח, וכל מי שעובד בו צריך אותו | | `~/.cursor/mcp.json` בתיקיית הבית | כשאתם רוצים את שַׁגֵּר בכל פרויקט שאתם פותחים | בסוכנות שבה כל לקוח מקבל ריפו משלו לאתר ולדפי הנחיתה, ההגדרה לפרויקט היא הבחירה הטבעית. הקובץ נכנס למאגר git, וכל מפתח בצוות מגדיר אצלו את `SHAGER_API_KEY`. אם תרצו להפריד בין לקוחות גם ברמת המפתח, תנו לכל ריפו שם משתנה אחר, למשל `SHAGER_API_KEY_ACME`, ועדכנו את הקובץ בהתאם. ### המשתנה צריך להיות זמין לעורך Cursor נקודה שמכשילה אנשים: משתנה סביבה שהגדרתם בטרמינל אחד לא תמיד זמין לאפליקציה שנפתחה מה Dock. אם השרת לא מתחבר, בדקו שהמשתנה מוגדר בקובץ ההגדרות של המעטפת (shell) שנטען בכניסה (למשל `~/.zshrc`), ונסו לפתוח את Cursor מהטרמינל עם הפקודה `cursor .` כדי שיירש את הסביבה. זה פתרון כללי לאפליקציות על macOS, לא משהו ייחודי לְשַׁגֵּר. ## מאיפה מגיע המפתח? שתי אפשרויות. אדם בצוות נכנס לכתובת `https://app.shager.ai/dashboard/agents`, יוצר מפתח ומגדיר לו הרשאות מתוך `read`, `write` או `publish`. או שהסוכן עצמו נרשם דרך נקודת הקצה (endpoint) של ההרשמה העצמית, מקבל sandbox עם מפתח, ומעביר לאדם קישור לאישור. המסלול השני שימושי כשמתחילים פרויקט חדש ורוצים שהסוכן יכין סביבת עבודה, יעלה מדיה ויכין טיוטות עוד לפני שמישהו פתח חשבון. הפירוט נמצא ב[מדריך ההרשמה העצמית](/blog/agent-self-signup-and-claim), והמתכון הטכני המלא לסוכנים יושב בקובץ [/auth.md](/auth.md). ## בדיקה ראשונה אחרי שמירת הקובץ, נכנסים להגדרות MCP של Cursor ומוודאים שהשרת `shager` מופיע כמחובר עם רשימת כלים. אחר כך, בצ'אט של הסוכן: ```text Use the shager tools. Run whoami, then list_workspaces and list_channels for the workspace named "Acme". Tell me which accounts are connected and which network each one is on. ``` אם מקבלים רשימה של עמודי פייסבוק, חשבונות אינסטגרם וערוצי יוטיוב שתואמת את מה שמופיע בְּשַׁגֵּר, החיבור תקין. אם הרשימה ריקה, זה לא בהכרח תקלה. ייתכן שבסביבת העבודה עוד לא חובר אף חשבון. במצב כזה הסוכן יכול להריץ `create_connect_link` ולקבל קישור שהלקוח פותח כדי לחבר בעצמו את הפייסבוק, האינסטגרם או היוטיוב שלו, בלי חשבון בְּשַׁגֵּר ובלי להעביר סיסמאות. שימו לב שהפעולה הזו חסומה בסביבת sandbox שעוד לא אושר על ידי אדם. ואם הקריאות נכשלות עם 401, כמעט תמיד מדובר באחד משלושה דברים: המשתנה לא נטען, המילה Bearer חסרה בקובץ, או שהמפתח בוטל. כל השגיאות של שַׁגֵּר חוזרות עם `code` וגם `message`, כך שהסוכן יכול להגיד לכם בדיוק מה הבעיה במקום לנחש. ## תרחיש עבודה: מדף נחיתה להפצה בלי לצאת מהעורך כך נראית זרימה טיפוסית, והיא מדגימה למה Cursor וְשַׁגֵּר משלימים זה את זה: 1. **בונים את הדף.** מבקשים מהסוכן ליצור דף נחיתה לקמפיין, למשל מבצע סתיו של רשת מרפאות שיניים. הסוכן כותב את הקומפוננטה, את הטקסטים ואת הטופס. 2. **מוציאים את המסר מהקוד.** אחרי שהדף עלה, מבקשים מהסוכן לקרוא את הקובץ ולסכם את ההצעה, הקהל וקריאה לפעולה בשלוש שורות. זה הבריף לפוסטים, והוא נגזר ממה שבאמת כתוב בדף ולא מזיכרון. 3. **מכינים מדיה.** אם יש סרטון קצר באחסון ציבורי, הסוכן מריץ `upload_media_from_url` עם `width`, `height` וגם `duration_ms`, כדי שֶׁשַּׁגֵּר יוכל לוודא שהסרטון מתאים לפורמט Reel ולפורמט Short לפני השליחה. 4. **יוצרים טיוטה ברמת החשבון.** `create_post` עם `group_ids` של קבוצת הסניפים, `per_channel` עם כיתוב שונה לכל סניף, `cta_url` שמפנה לדף החדש, וגם `first_comment` שמזמין ללחוץ. שַׁגֵּר יוצר לכל חשבון קישור מקוצר ותגיות UTM משלו, כשהשדה `utm_content` מזהה את החשבון. 5. **שולחים לאישור.** אם הלקוח מאשר תוכן לפני פרסום, `request_approval` שולח לו קישור לאישור בלי צורך להתחבר. הסוכן לא צריך לדעת איך לבנות UTM או איך לפזר שליחה בין חשבונות. את זה שַׁגֵּר עושה. התפקיד שלו הוא להבין את המסר ולנסח אותו נכון לכל עמוד, וזה בדיוק מה שמודלים טובים בו. ### ניסוח שונה לכל חשבון זה לא קישוט כשאותו טקסט בדיוק עולה לעשרות עמודים בפרק זמן קצר, זה נראה רע לקוראים וזה דפוס שרשתות חברתיות לא אוהבות. השדה `per_channel` קיים כדי שכל עמוד יקבל ניסוח משלו, וְשַׁגֵּר ממליץ להשתמש בו. בהנחיה לסוכן כדאי לכתוב במפורש: שמור על אותה הצעה ואותו קישור, אבל שנה פתיחה, סדר ודוגמה מקומית לכל סניף. על הנושא הזה בהרחבה, כולל איך שַׁגֵּר מפזר את זמני השליחה, כתבנו ב[מדריך על הימנעות מחסימות בפרסום בהיקף גדול](/blog/avoid-spam-blocks-when-posting-at-scale). ## הרשאות: מה Cursor יכול לעשות בשמכם Cursor הוא סביבת פיתוח, והסוכן בה רגיל לבצע הרבה פעולות ברצף. זה מצוין לקוד ופחות מתאים לפרסום פומבי. ההמלצה שלנו היא מפתח עם `read` וגם `write` בלבד בשלב הראשון. הסוכן יכין טיוטות, ואדם יעבור עליהן בְּשַׁגֵּר ויתזמן. כשהתהליך מוכיח את עצמו, אפשר להוסיף `publish` ולתת לסוכן לתזמן עם `schedule_at` בפורמט ISO 8601 עם offset. כל קריאה של הסוכן נרשמת ביומן הביקורת בלוח הסוכנים של שַׁגֵּר, כך שגם אחרי חודש אפשר לראות מי יצר כל פוסט ומתי. אם מפתח דלף לריפו, מבטלים אותו שם ויוצרים חדש. מי שעובד בחלק מהזמן בטרמינל ימצא את אותו חיבור עם תחביר מעט שונה במדריך [לחיבור שַׁגֵּר אל Claude Code](/blog/connect-shager-to-claude-code). הצעד הבא אחרי חיבור עובד הוא לבחור קמפיין אחד אמיתי, להריץ עליו את חמשת השלבים למעלה עד טיוטה, ולתקן את ההנחיות לפי מה שראיתם בטיוטה הראשונה. ## שאלות נפוצות ### Cursor תומך בשרתי MCP מרוחקים עם כותרות? כן. לפי התיעוד של Cursor, שרת מרוחק מוגדר עם `url` ועם אובייקט `headers`, ואפשר להשתמש בתחביר `${env:NAME}` כדי לקרוא ערכים ממשתני סביבה. זה כל מה שֶׁשַּׁגֵּר צריך. ### האם אפשר לשים את המפתח ישירות בקובץ mcp.json? טכנית כן, אבל לא כדאי. הקובץ נמצא בדרך כלל בתוך הריפו, ומפתח שנכנס למאגר git קשה מאוד למחוק מההיסטוריה. משתנה סביבה פותר את זה בלי מאמץ. ### הסוכן בעורך Cursor יכול לפרסם בלי אישור שלי? רק אם המפתח כולל הרשאת `publish`. מפתח עם `read` וגם `write` מאפשר ליצור טיוטות בלבד, וכל תזמון או פרסום דורש אדם או מפתח אחר. כך שולטים בזה בצד של שַׁגֵּר ולא רק בהגדרות של Cursor. --- Source: https://shager.ai/blog/connect-shager-to-cursor # אישור אנושי לפוסטים של סוכן AI: איפה בדיוק לשים את נקודת העצירה _2026-08-25 · סוכן שמפרסם בלי בקרה הוא סיכון, וסוכן שכל פוסט שלו נבדק ידנית לא חוסך כלום. כך בונים שכבות אישור לפי רמת סיכון, עם הרשאות, אישור לקוח ובדיקת מצב שוטפת._ נקודת העצירה הנכונה לסוכן AI היא בין הטיוטה לבין התזמון, ולא בין הרעיון לבין הטיוטה. סוכן צריך להיות חופשי להכין, לנסח ולהעלות מדיה, אבל ההחלטה שפוסט יוצא לעולם צריכה לעבור דרך אדם, לפחות עד שהתהליך הוכיח את עצמו. איפה בדיוק האדם עומד תלוי ברמת הסיכון של התוכן, לא בהעדפה כללית. הבעיה היא שרוב הסוכנויות בוחרות אחד משני קצוות. או שהסוכן לא נוגע בכלום ורק מציע טקסטים, או שנותנים לו גישה מלאה ומקווים לטוב. שני הקצוות לא עובדים. הראשון לא חוסך זמן, והשני ייגמר בפוסט מביך בעמוד של לקוח. ## למה "רק לבדוק הכל" זה לא פתרון נניח שסוכן מכין קמפיין לשלושים סניפים, עם ניסוח שונה לכל סניף. אם עורך צריך לקרוא את כל שלושים הווריאציות, לבדוק כל אחת ולאשר, הוא עשה בערך את אותה עבודה כמו לכתוב אותן. החיסכון נעלם. הפתרון הוא לבדוק את הדבר הנכון. במקום לבדוק כל פלט, בודקים: 1. את ההנחיות שהסוכן קיבל: הבריף, הפרומפט, הכללים. 2. דגימה מייצגת מהפלט: נגיד חמש וריאציות מתוך שלושים. 3. את מה שאי אפשר לטעות בו: מחיר, תאריך, תנאי מבצע, קישור. אם הדגימה טובה וההנחיות נכונות, אין סיבה להניח שהווריאציה העשרים ושבע שונה. אם הדגימה גרועה, מתקנים את ההנחיות ומריצים מחדש, לא מתקנים ידנית. ## ארבע שכבות של בקרה אני חושב על בקרה בתור ארבע שכבות, כשכל אחת מוסיפה הגנה: | שכבה | מה היא עוצרת | איך זה נראה בְּשַׁגֵּר | |---|---|---| | הרשאות מפתח | פעולות שהסוכן בכלל לא אמור לעשות | מפתח עם `read`, `write` או גם `publish` | | בדיקה פנימית | טעויות מסר, טון וקול מותג | העורך בודק טיוטות בממשק | | אישור לקוח | פוסטים שהלקוח לא ראה | קישור אישור עם `request_approval` | | בדיקות לפני שליחה | פוסט שהרשת תדחה | כל פוסט נבדק מול חוקי הרשת לפני שהוא יוצא | השכבה הראשונה היא הכי חשובה, כי היא לא תלויה בכך שמישהו יזכור לבדוק. סוכן עם מפתח `write` בלבד פשוט לא יכול לתזמן או לפרסם. זה לא כלל שהוא צריך לכבד. זו מגבלה של המערכת. גם בתחילת הדרך זה מובנה. סוכן שנרשם לבד לְשַׁגֵּר מקבל ארגז חול שבו הוא יכול ליצור טיוטות, אבל לא לתזמן, לא לפרסם ולא לשלוח בקשות אישור. רק כשאדם תובע את הסביבה הוא מחליט אם המפתח מקבל גם הרשאת פרסום. תיארתי את התהליך המלא ב[מאמר על הרשמה עצמית של סוכן ותביעה](/blog/agent-self-signup-and-claim). ## מטריצת החלטה: מתי צריך אדם לא כל פוסט צריך את אותה רמת בקרה. הנה איך אני מחלק: | סוג תוכן | דוגמה | בקרה מומלצת | |---|---|---| | תוכן שגרתי מתבנית מאושרת | טיפ שבועי, סרטון מאחורי הקלעים | דגימה פנימית, אישור לקוח פעם בקמפיין | | מבצע עם מחיר ותנאים | הנחה לחג, מבצע סוף עונה | בדיקה של כל פרט מספרי, אישור לקוח חובה | | תוכן שקשור לאירוע אקטואלי | תגובה לחדשות, ימי זיכרון | אדם כותב או משכתב, לא סוכן | | תוכן רגיש או משפטי | תחום רפואי, פיננסי, הבטחות | אדם כותב, יועץ בודק, הסוכן רק מפיץ | | הודעה דחופה | שינוי שעות, סגירת סניף | אדם מאשר בזמן אמת | השורה של ימי זיכרון ראויה להדגשה. בישראל, פוסט שמח שיוצא ביום הזיכרון כי תוזמן שבועיים קודם הוא טעות שלקוח לא שוכח. סוכן לא יודע לבד שצריך לעצור. לכן הכלל הוא שבשבוע שיש בו מועד רגיש, אדם עובר על כל מה שמתוזמן ומבטל עם `cancel_post` מה שלא מתאים. פוסט שמבוטל חוזר להיות טיוטה מאושרת ולא נמחק. ## איך נראה התהליך בקריאות MCP כך נראה רצף עם אישור לקוח, כשהסוכן עובד מול סביבת עבודה שהוגדרה כדורשת אישור: ```text 1. create_post(workspace_id, caption, group_ids, media_ids, per_channel: [...]) מחזיר post_id של טיוטה 2. request_approval(workspace_id, post_id, reviewer_name: "דנה, מנהלת שיווק", reviewer_email: "...", send_email: true) מחזיר approval_url ו whatsapp_url 3. get_post(workspace_id, post_id) בודקים את הסטטוס: IN_REVIEW, CHANGES_REQUESTED או APPROVED 4. אם APPROVED: schedule_post(workspace_id, post_id, schedule_at: "2026-08-30T10:00:00+03:00") 5. אם CHANGES_REQUESTED: מדווחים לעורך, מתקנים, ויוצרים טיוטה מעודכנת ``` שני דברים חשובים כאן. הראשון, הלקוח מאשר דרך קישור בלי להתחבר לשום מערכת, כך שאין חיכוך. השני, בסביבה שדורשת אישור, ניסיון לתזמן פוסט שלא אושר נכשל עם הסבר. הסוכן לא יכול לעקוף את זה גם אם הוא מנסה. הרחבתי על תהליך האישור מצד הסוכנות, כולל איך מנסחים את הבקשה ללקוח, ב[מדריך לתהליך אישור לקוח](/blog/client-approval-workflow-for-agencies). ## מתי נותנים לסוכן הרשאת פרסום בשלב מסוים תרצו שהסוכן יתזמן בעצמו, לפחות לתוכן שגרתי. הנה הקריטריונים שאני משתמש בהם לפני שאני נותן `publish`: 1. לפחות כמה שבועות של עבודה עם `write` בלבד, בלי טעויות שהגיעו ללקוח. 2. הלקוח אישר את התבניות והכללים, לא רק פוסטים בודדים. 3. יש אדם שעובר על יומן הביקורת לפחות פעם בשבוע. 4. ההרשאה ניתנת לסביבת עבודה אחת, לא לכל הלקוחות בבת אחת. 5. יש נוהל ברור לביטול מפתח אם משהו משתבש. גם אחרי שהסוכן קיבל הרשאת פרסום, אפשר להשאיר את אישור הלקוח פעיל. אלה שתי שכבות נפרדות. ההרשאה קובעת מה הסוכן יכול לעשות, והגדרת הסביבה קובעת מה צריך לקרות לפני שזה יוצא. ## איך מנסחים את ההוראה לסוכן ההגדרות במערכת הן השכבה הקשיחה, אבל כדאי שגם ההנחיות של הסוכן ישקפו אותן. כך הסוכן לא יבזבז קריאות על ניסיונות שייכשלו, וידווח לכם בצורה ברורה. הנה ניסוח שאני מכניס להנחיות הקבועות: ```text אתה מכין טיוטות בלבד. לעולם אל תקרא ל schedule_post לפני ש get_post מחזיר APPROVED. אם הלקוח ביקש שינויים, דווח לי מה ביקש ואל תתקן לבד. אם יש בשבוע הזה יום זיכרון, חג או אירוע ביטחוני, עצור ושאל אותי לפני כל פעולה. ``` ## יומן הביקורת הוא חלק מהאישור אישור אנושי לא נגמר ברגע הפרסום. בלוח הבקרה של הסוכנים בְּשַׁגֵּר יש יומן של כל קריאה שהסוכן ביצע: מה הוא ביקש, מתי ובאיזו סביבה. מומלץ שמישהו יעבור עליו באופן קבוע, לא רק כשיש תקלה. מה מחפשים ביומן: 1. קריאות לסביבות עבודה שהסוכן לא אמור לגעת בהן. 2. ניסיונות תזמון שנכשלו, ומה הייתה הסיבה. 3. ביטולים, ומי ביקש אותם. 4. שינוי חריג בכמות הקריאות. את הנושא של מפתחות ויומן ביקורת פירטתי ב[מאמר על מפתחות, הרשאות וביקורת](/blog/api-keys-scopes-and-audit), ואת כללי הבטיחות המלאים ב[חוקי בטיחות לסוכנים שמפרסמים בהיקף](/blog/safety-rules-for-agents-posting-at-scale). ## שאלות נפוצות ### האם הלקוח צריך חשבון בְּשַׁגֵּר כדי לאשר פוסטים? לא. הסוכן יוצר קישור אישור עם `request_approval`, ואפשר לשלוח אותו במייל או בוואטסאפ. הלקוח פותח את הקישור, רואה את הפוסט ומאשר או מבקש שינויים, בלי להתחבר. ### מה ההבדל בין הרשאת publish לבין אישור לקוח? הרשאת `publish` היא תכונה של מפתח API וקובעת אם הסוכן יכול לתזמן ולפרסם בכלל. אישור לקוח הוא הגדרה של סביבת העבודה וקובע שכל פוסט צריך אישור לפני תזמון. אפשר להפעיל את שתיהן יחד, וזו ההמלצה ללקוחות רגישים. ### איך עוצרים פוסט שכבר תוזמן? עם `cancel_post`, כל עוד הפרסום עוד לא התחיל. הפוסט חוזר למצב של טיוטה מאושרת ולא נמחק, כך שאפשר לתזמן אותו מחדש אחר כך. אם אתם רוצים להתחיל מהשכבה הראשונה, [עמוד הסוכנים](/agents) מסביר איך יוצרים מפתח עם הרשאת כתיבה בלבד ומחברים אותו לסוכן. שבועיים של עבודה כך יראו לכם בדיוק איפה הבקרה שלכם צריכה להיות. --- Source: https://shager.ai/blog/human-approval-for-agent-posts # מודל ההפעלה של סוכנות שעובדת עם סוכני AI: מי עושה מה, ומתי _2026-08-18 · איך בונים סוכנות שבה סוכני AI מריצים את ההפצה ואנשים מחזיקים את האסטרטגיה: תפקידים, שבוע עבודה קבוע, סביבת עבודה לכל לקוח, הרשאות, ומה בדיוק נמדד בסוף._ סוכנות שעובדת עם סוכני AI בנויה סביב חלוקה פשוטה: אנשים מחליטים, סוכנים מבצעים, ולקוחות מאשרים. מה שמבדיל סוכנות שזה עובד אצלה מסוכנות שזה מתפרק אצלה הוא לא איזה מודל שפה היא בחרה. זה האם יש לה מבנה ברור של תפקידים, שבוע עבודה קבוע, הרשאות מדורגות ונקודת אמת אחת לכל לקוח. המאמר הזה הוא תיאור של מודל הפעלה. לא תיאוריה, אלא איך נראה שבוע בסוכנות שמחזיקה, נגיד, עשרים לקוחות עם כמה מאות חשבונות ברשתות, כשההפצה רצה דרך סוכן. ## איזה תפקידים צריך בסוכנות כזו? הטעות הנפוצה היא להוסיף "איש AI" לצוות ולצפות שהוא יעשה הכל. בפועל, צריך להגדיר מחדש את התפקידים הקיימים: | תפקיד | אחריות | מה הוא כבר לא עושה | |---|---|---| | מנהל לקוח | אסטרטגיה, מסר, קשר עם הלקוח, החלטות על חריגים | העלאת פוסטים ידנית | | עורך תוכן | בריף, עמודי תוכן, בדיקת דגימות מהסוכן, קול המותג | כתיבת שלושים וריאציות של אותו פוסט | | מפעיל סוכנים | הגדרת סקילים ופרומפטים, מפתחות והרשאות, ניטור יומן הביקורת | עבודה שוטפת מול לקוחות | | הסוכן | העלאת מדיה, טיוטות, וריאציות, שליחה לאישור, תזמון, דוחות | החלטות אסטרטגיות | | הלקוח | אישור תוכן, חיבור החשבונות שלו | שליחת סיסמאות | מפעיל הסוכנים הוא התפקיד החדש היחיד, ובסוכנות קטנה הוא יכול להיות חצי משרה של מישהו שכבר עובד אצלכם. הוא אחראי על כך שהסוכן עובד לפי כללים, לא על התוכן. ## איך מארגנים את הלקוחות בתוך המערכת נקודת המוצא היא סביבת עבודה נפרדת לכל לקוח. בְּשַׁגֵּר זה workspace, והסוכן יכול לראות את כולן עם `list_workspaces` ולפתוח חדשה עם `create_workspace`. לכל סביבה יש אזור זמן משלה, וברירת המחדל היא ישראל. אפשר גם לקבוע כבר ביצירה שהסביבה דורשת אישור לקוח לפני תזמון. בתוך כל סביבה, מארגנים את החשבונות בקבוצות. רשת עם שלושים סניפים יכולה לקבל קבוצה לכל אזור, קבוצה לסניפים חדשים וקבוצה לחשבונות של המטה. הסוכן יוצר קבוצות עם `create_group` ומפרסם אליהן עם `group_ids`, כך שהוא לא צריך לזכור שלושים מזהים. ההפרדה הזו חשובה יותר ממה שנראה. כשסוכן עובד על כמה לקוחות, הסכנה הגדולה היא לא טעות כתיב. היא פוסט של לקוח אחד שיוצא בעמוד של לקוח אחר. סביבות נפרדות ומזהי סביבה בכל קריאה הן ההגנה הראשונה מפני זה. הרחבתי על עבודה עם סוכן אחד מול הרבה לקוחות ב[מאמר על סוכן אחד ולקוחות רבים](/blog/one-agent-many-clients). ## שבוע עבודה טיפוסי הנה שבוע ישראלי, ראשון עד חמישי, כפי שאני ממליץ לבנות אותו: 1. **ראשון בבוקר: תכנון.** מנהלי הלקוחות ועורכי התוכן מחליטים מה יוצא השבוע לכל לקוח. התוצר הוא בריף קצר לכל קמפיין: מסר, נכסים, קישור יעד, קבוצות חשבונות, תאריכים. 2. **ראשון אחר הצהריים: הסוכן מכין.** לפי הבריפים, הסוכן מעלה מדיה, כותב וריאציות לכל חשבון ויוצר טיוטות. בסוף היום יש רשימת טיוטות לכל לקוח. 3. **שני: בדיקה פנימית.** העורך עובר על דגימה מכל קמפיין, לא על כל וריאציה. אם יש בעיה בדפוס, מתקנים את הפרומפט ומריצים שוב, לא מתקנים ידנית שלושים פוסטים. 4. **שני אחר הצהריים: אישור לקוח.** הסוכן שולח קישור אישור לכל לקוח עם `request_approval`. הלקוח מאשר בלי להתחבר לשום מערכת. את הקישור אפשר לשלוח במייל או בוואטסאפ. 5. **שלישי ורביעי: תזמון ופרסום.** מה שאושר מתוזמן עם `schedule_post`. הפרסום מתפזר אוטומטית בין חשבונות של אותה רשת. 6. **כל בוקר: בדיקת מצב.** הסוכן מריץ `list_posts` עם סינון לפי סטטוס `FAILED` או `PARTIALLY_PUBLISHED` ומדווח למפעיל מה נכשל ולמה. 7. **חמישי: דוח.** הסוכן מושך לחיצות לכל חשבון ולכל פוסט עם `get_analytics` ומכין טיוטת דוח שבועי. מנהל הלקוח מוסיף פרשנות ושולח. את הדוח השבועי בניתי כתהליך מלא ב[מדריך לדוח לקוח שבועי שסוכן מכין](/blog/weekly-client-report-by-agent). ## מפתחות, הרשאות ואחריות במודל הזה, ההרשאות הן חלק מהמבנה הארגוני, לא נושא טכני. אלה הכללים שאני ממליץ עליהם: 1. **מפתח נפרד לכל סוכן או לכל תהליך.** סוכן שמכין טיוטות וסוכן שמכין דוחות לא צריכים את אותו מפתח. 2. **הרשאה מינימלית.** סוכן דוחות צריך `read` בלבד. סוכן שמכין טיוטות צריך `write`. רק תהליך שעבר תקופת הרצה מקבל `publish`. 3. **אדם אחד אחראי על כל מפתח.** מפעיל הסוכנים יוצר ומבטל מפתחות בלוח הבקרה, ושם גם מופיע יומן ביקורת של כל קריאה. 4. **ביטול מהיר.** אם משהו נראה לא תקין, מבטלים את המפתח קודם ושואלים שאלות אחר כך. פירטתי את נושא המפתחות לעומק ב[מאמר על מפתחות, הרשאות ויומן ביקורת](/blog/api-keys-scopes-and-audit). ## איך עובדים עם הלקוח במודל הזה לקוחות לא צריכים לדעת שיש סוכן כדי ליהנות ממנו, אבל כדאי לספר להם. רוב הלקוחות מעריכים שקיפות, ובמיוחד כשמסבירים שכל פוסט עובר אישור שלהם לפני שהוא יוצא. שני דברים משתנים בקשר עם הלקוח: **חיבור חשבונות.** במקום לבקש סיסמאות או להוסיף את הסוכנות כמנהלת בכל עמוד, שולחים ללקוח קישור חיבור. הלקוח מחבר את פייסבוק, אינסטגרם או יוטיוב שלו בעצמו, בלי לפתוח חשבון בְּשַׁגֵּר ובלי למסור סיסמה. הסוכן יכול ליצור את הקישור עם `create_connect_link`, אחרי שאדם תבע את הסביבה. **אישור תוכן.** הלקוח מקבל קישור אחד, רואה את הפוסטים ומאשר או מבקש שינויים. אין צורך בקבוצת וואטסאפ עם צילומי מסך. יש כאן גם יתרון ארגוני: האישור נרשם במערכת, לא בשיחה שמישהו צריך למצוא. תהליך האישור עצמו מתואר ב[מדריך לתהליך אישור לקוח בסוכנויות](/blog/client-approval-workflow-for-agencies). ## מה מודדים כדי לדעת שזה עובד סוכנות שעוברת למודל כזה צריכה לבדוק את עצמה. לא לפי "כמה זמן חסכנו" באופן כללי, אלא לפי מדדים שאפשר לספור: 1. כמה זמן עובר מבריף ועד טיוטה מוכנה לאישור. 2. כמה סבבי תיקון יש לכל קמפיין, ואם הם יורדים לאורך זמן. 3. כמה פוסטים נכשלים בפרסום, ומה הסיבות החוזרות. 4. כמה חשבונות מנוהלים לכל איש צוות. 5. לחיצות לכל חשבון, כדי לראות שהניסוח השונה לא פוגע בתוצאות. אל תמציאו יעדים מראש. מדדו חודש אחד במודל הישן וחודש במודל החדש, והשוו. ## כמה זה עולה ואיך זה מתמחר בְּשַׁגֵּר, גישת API, שרת MCP ומספר בלתי מוגבל של משתמשים כלולים בכל המסלולים. ההבדל בין המסלולים הוא מספר החשבונות. סוכנות עם עשרים לקוחות ושלושה חשבונות לכל אחד נכנסת למסלול Agency, שכולל 60 חשבונות. סוכנות עם כמה מאות חשבונות צריכה מסלול גבוה יותר. כל הפרטים ב[עמוד המחירים](/pricing). השיקול החשוב לסוכנות הוא שהתמחור לא נשבר כשמוסיפים אנשים או סוכנים. אפשר לתת לכל איש צוות גישה, ולפתוח כמה מפתחות שצריך, בלי לשלם על כל אחד. ## שאלות נפוצות ### האם סוכנות קטנה צריכה מפעיל סוכנים במשרה מלאה? לא. בסוכנות קטנה זה תפקיד של כמה שעות בשבוע, בדרך כלל של מי שכבר אחראי על הכלים והתהליכים. מה שחשוב הוא שיהיה אדם אחד שאחראי על המפתחות, הפרומפטים ויומן הביקורת. ### האם כל לקוח צריך סביבת עבודה נפרדת? כן, וזו ההמלצה החזקה ביותר במאמר. סביבה נפרדת לכל לקוח מונעת ערבוב של חשבונות, מאפשרת אזור זמן והגדרות אישור שונים, ומאפשרת לתת הרשאות לפי לקוח. ### מה קורה כשהלקוח לא מאשר בזמן? הפוסט נשאר בהמתנה ולא מתוזמן. הסוכן יכול לבדוק את המצב עם `get_post` ולהתריע למנהל הלקוח, שמחליט אם להזכיר ללקוח או לדחות את התאריך. בסביבה שדורשת אישור, ניסיון לתזמן פוסט שלא אושר נכשל עם הסבר ברור. אם אתם בונים את המודל הזה עכשיו, התחילו מלקוח אחד ומסוכן אחד עם הרשאת כתיבה בלבד. אחרי שבועיים של עבודה כזו יהיה לכם ברור איפה הצוות שלכם צריך להיות, ואיפה הוא היה עד היום רק כי לא הייתה ברירה. --- Source: https://shager.ai/blog/agency-operating-model-with-agents # חיבור שַׁגֵּר אל Codex CLI: שלוש שורות בקובץ config.toml ומפתח שלא נכנס לקובץ _2026-08-18 · איך מגדירים את שרת MCP של שַׁגֵּר בכלי Codex CLI של OpenAI: בלוק mcp_servers בקובץ config.toml, bearer_token_env_var במקום מפתח גלוי, הגדרה לפרויקט ובדיקה עם /mcp._ כדי לחבר את שַׁגֵּר אל Codex CLI מוסיפים לקובץ `~/.codex/config.toml` בלוק בשם `[mcp_servers.shager]` עם `url = "https://app.shager.ai/api/mcp"` ועם `bearer_token_env_var = "SHAGER_API_KEY"`. מגדירים את משתנה הסביבה `SHAGER_API_KEY` עם המפתח של שַׁגֵּר, מפעילים את `codex` ומקלידים `/mcp` כדי לראות שהשרת פעיל. Codex שולח את המפתח בכותרת `Authorization` בתור Bearer, וזה בדיוק מה שֶׁשַּׁגֵּר מצפה לקבל. בניגוד לחלק מהכלים, Codex תומך בשרתי MCP מרוחקים עם Streamable HTTP ועם טוקן ממשתנה סביבה באופן מובנה, כך שאין צורך בגשרים או בעקיפות. זה הופך אותו לאחת הדרכים הנקיות ביותר להריץ סוכן OpenAI מול שַׁגֵּר כבר היום, כל עוד OAuth של שַׁגֵּר בפיתוח. ## למה דווקא config.toml ולא פקודה? בכלי Claude Code רוב העבודה נעשית בפקודת `claude mcp add`. גם בכלי Codex יש פקודה דומה, `codex mcp add`, והיא מקבלת `--url` לשרתים מרוחקים. אבל [עמוד MCP בתיעוד של Codex](https://developers.openai.com/codex/mcp) מתעד את אפשרויות האימות לשרתי HTTP בתוך קובץ ההגדרות ולא כדגלים של הפקודה. לכן הדרך הבטוחה והברורה היא לערוך את הקובץ ישירות. לפי אותו עמוד, שרת Streamable HTTP מקבל את השדות הבאים: | שדה | חובה | מה הוא עושה | |---|---|---| | `url` | כן | כתובת השרת | | `bearer_token_env_var` | לא | שם משתנה סביבה שהערך שלו נשלח בתור Bearer בכותרת Authorization | | `http_headers` | לא | כותרות עם ערכים קבועים | | `env_http_headers` | לא | כותרות שהערך שלהן נלקח ממשתני סביבה | ## ההגדרה המלאה לְשַׁגֵּר פותחים את `~/.codex/config.toml` ומוסיפים: ```toml [mcp_servers.shager] url = "https://app.shager.ai/api/mcp" bearer_token_env_var = "SHAGER_API_KEY" ``` ובקובץ ההגדרות של המעטפת (shell) שלכם, למשל `~/.zshrc`: ```bash export SHAGER_API_KEY="shgr_live_XXXXXXXXXXXXXXXX" ``` זהו. אין צורך לכתוב את המילה Bearer בעצמכם, Codex מוסיף אותה. היתרון של `bearer_token_env_var` על פני `http_headers` עם ערך קבוע הוא שהמפתח לא יושב בקובץ ההגדרות. זה חשוב כשאתם מגבים את תיקיית הבית, מסנכרנים dotfiles לריפו, או סתם משתפים צילום מסך של הקונפיגורציה בערוץ של הצוות. ### מתי בכל זאת להשתמש בשדה http_headers? כמעט אף פעם, בהקשר של שַׁגֵּר. שַׁגֵּר צריך כותרת אחת בלבד, `Authorization`, והשדה `bearer_token_env_var` מכסה אותה. אם בעתיד תעבדו דרך שער פנימי של החברה שדורש כותרת ניתוב נוספת, זה המקום להוסיף אותה, ורצוי עם `env_http_headers` כדי שגם היא לא תישמר כטקסט גלוי. ## הגדרה לפרויקט ספציפי התיעוד של Codex מאפשר גם להגדיר שרתי MCP ברמת הפרויקט, בקובץ `.codex/config.toml` בתוך הריפו, בתנאי שהפרויקט מסומן כמהימן. לסוכנות שמחזיקה ריפו לכל לקוח גדול, זה נוח: בריפו של הלקוח מוגדר שרת שַׁגֵּר, ובריפו אחר לא. כדאי לשלב את זה עם מפתח נפרד לכל לקוח. בְּשַׁגֵּר כל לקוח הוא סביבת עבודה (workspace), ומפתחות נוצרים ברמת הארגון. אם תרצו להפריד ברמת המפתח, צרו מפתח ייעודי לכל פרויקט בכתובת `https://app.shager.ai/dashboard/agents` ותנו לכל ריפו משתנה סביבה משלו, למשל `SHAGER_API_KEY_CLIENT_A`. ביומן הביקורת תוכלו לראות איזה מפתח ביצע כל פעולה. ## בדיקה ראשונה מפעילים `codex` בטרמינל שבו משתנה הסביבה מוגדר, ומקלידים `/mcp`. השרת `shager` צריך להופיע ברשימת השרתים הפעילים עם הכלים שלו. אם הוא לא שם, שתי הסיבות הנפוצות הן שהמשתנה לא נטען בחלון הנוכחי, או שגיאת TOML קטנה כמו מירכאות חסרות. אחרי זה, בקשה ראשונה: ```text Use the shager MCP server. Run whoami and list_workspaces, then list_channels for the first workspace. Summarize which Facebook Pages, Instagram accounts and YouTube channels are connected. ``` אפשר כמובן לכתוב לסוכן בעברית. כתבתי כאן באנגלית כי הרבה צוותים מעדיפים את ההנחיות הטכניות לסוכן באנגלית ואת התוכן עצמו בעברית. מה שחשוב הוא שהסוכן יחזיר רשימה שתואמת את מה שאתם רואים בְּשַׁגֵּר. ### כשמשהו לא עובד | מה רואים | מה כנראה קרה | מה עושים | |---|---|---| | השרת לא מופיע בפקודה `/mcp` | שגיאת תחביר בקובץ TOML או שם בלוק שגוי | בודקים שהכותרת היא בדיוק `[mcp_servers.shager]` | | השרת מופיע, הקריאות נכשלות על אימות | המשתנה ריק בחלון הנוכחי | מריצים `echo $SHAGER_API_KEY` באותו טרמינל | | `create_post` עובד, `schedule_post` נכשל | למפתח אין `publish` או שה sandbox לא אושר | אדם מאשר או יוצר מפתח עם הרשאה מתאימה | | הודעת שגיאה עם הקוד `rejected` | הרשת הייתה דוחה את הפוסט | קוראים את הודעת השגיאה (message) ומתקנים פורמט, אורך או מדיה | השגיאות של שַׁגֵּר חוזרות תמיד עם `code` וגם `message` קריאים. סוכן טוב יודע לקרוא את ההודעה, לתקן ולנסות שוב, ולא רק לדווח שהייתה תקלה. שווה לכתוב לו את זה במפורש בהנחיות. ## איפה Codex חזק במיוחד בעבודה מול שַׁגֵּר Codex הוא סוכן קוד, והוא מרגיש הכי בבית כשהעבודה יושבת בריפו. שני דפוסים שעובדים טוב: 1. **תוכן כקבצים.** מחזיקים בריפו תיקייה עם קובץ Markdown לכל קמפיין: בריף, מסרים, קישור לדף נחיתה ורשימת קבוצות חשבונות. מבקשים מהסוכן Codex לקרוא את הקובץ, לנסח כיתוב שונה לכל חשבון ולהעלות טיוטה אחת לְשַׁגֵּר עם `create_post` והשדה `per_channel`. הבריף נשאר בהיסטוריית git, והטיוטה מחכה בְּשַׁגֵּר לבדיקה. 2. **דף נחיתה ואז הפצה.** Codex בונה או מעדכן דף נחיתה בקוד, ואחרי שהוא עולה, אותו סוכן מכין פוסט שהקישור שלו מופיע בשדה `cta_url`. שַׁגֵּר יוצר לכל חשבון קישור מקוצר ותגיות UTM משלו, כך שאחרי שבוע אפשר לבקש מהסוכן Codex להריץ `get_analytics` ולראות מאיזה עמוד הגיעו הלחיצות. אם אתם מעדיפים לכתוב את כל הזרימה כקוד ולא דרך שרת MCP, אותן פעולות זמינות בממשק REST API, וקובץ OpenAPI נמצא בכתובת [https://app.shager.ai/api/v1/openapi.json](https://app.shager.ai/api/v1/openapi.json). זה שימושי במיוחד בסביבת CI, כשאין סוכן אינטראקטיבי אלא סקריפט שרץ לפי לוח זמנים. ## כמה כללי בטיחות שכדאי להגדיר מראש את הגבול האמיתי כדאי לשים בצד של שַׁגֵּר ולא רק בהגדרות האישור של הסוכן, כי הוא נשמר גם כשמישהו משנה את הקונפיגורציה המקומית. מפתח עם הרשאות `read` וגם `write` בלבד מאפשר לסוכן ליצור טיוטות בלי לתזמן או לפרסם. כשתרצו שהסוכן גם יתזמן, צרו מפתח חדש עם `publish`, החליפו את הערך של משתנה הסביבה, ובטלו את הישן. שתי נקודות נוספות. המגבלה היא 120 קריאות בדקה לכל מפתח, וסוכן שמבצע `get_post` בלולאה על מאות פוסטים יכול להגיע אליה. עדיף לבקש ממנו `list_posts` עם סינון לפי סטטוס. ובנוסף, כשאתם מבקשים מהסוכן Codex לתזמן, ציינו זמן עם אזור זמן מפורש, למשל `2026-08-24T09:00:00+03:00`. שַׁגֵּר מצפה לפורמט ISO 8601 עם offset, וזה חוסך את הטעות הקלאסית של פוסט שעולה בשש בבוקר במקום בתשע. מי שעובד גם עם Claude Code יראה שההגדרה כמעט זהה, וההבדלים מפורטים במדריך [לחיבור שַׁגֵּר אל Claude Code](/blog/connect-shager-to-claude-code). ומי שמגיע מעולם ChatGPT ותוהה למה שם זה עוד לא עובד, ההסבר נמצא במדריך [על שַׁגֵּר וגם ChatGPT](/blog/shager-and-chatgpt). התמונה הכוללת של כל הכלים שמתחברים לְשַׁגֵּר מרוכזת ב[עמוד הסוכנים](/agents). הצעד הבא אחרי חיבור עובד הוא להחליט מה Codex עושה לבד ומה מחכה לאדם. התחילו בטיוטות בלבד, עברו על עשר הראשונות, ורק אחרי זה תנו למפתח הרשאת `publish`. ## שאלות נפוצות ### Codex CLI תומך בשרתי MCP מרוחקים? כן. לפי התיעוד של OpenAI, Codex תומך בשרתי Streamable HTTP עם השדה `url` בקובץ `config.toml`, ומאפשר להעביר טוקן Bearer ממשתנה סביבה דרך `bearer_token_env_var`. זה מספיק לחיבור מלא לְשַׁגֵּר. ### אפשר להוסיף את שַׁגֵּר עם codex mcp add במקום לערוך קובץ? הפקודה מקבלת `--url`, אבל התיעוד לא מציג בה דגל להעברת טוקן מסוג Bearer. לכן הדרך המומלצת היא להוסיף את הבלוק בקובץ `config.toml` ידנית, עם `bearer_token_env_var`. ### המפתח נשמר בתוך config.toml? לא, אם משתמשים בשדה `bearer_token_env_var`. הקובץ מכיל רק את שם המשתנה, והערך נקרא מהסביבה בזמן ההפעלה. כך אפשר לשתף את קובץ ההגדרות בלי לחשוף את המפתח. --- Source: https://shager.ai/blog/connect-shager-to-codex # שַׁגֵּר בתוך Claude Desktop: מה עובד היום עם מחבר מותאם, ומה עושים אם אין כותרות _2026-08-11 · איך מחברים את שַׁגֵּר אל Claude Desktop כמחבר מותאם עם כותרת Authorization, למה claude_desktop_config.json לא המקום לשרת מרוחק, ומה עושים כשאין Request headers._ באפליקציית Claude Desktop מחברים את שַׁגֵּר כמחבר מותאם (custom connector): נכנסים לתפריט Customize ואז Connectors, מוסיפים מחבר עם הכתובת `https://app.shager.ai/api/mcp`, בוחרים באפשרות ללא התחברות, ומוסיפים תחת Request headers את הכותרת `Authorization` עם הערך `Bearer` ואחריו מפתח API. הבעיה היא שלפי התיעוד של Anthropic, אימות בכותרות נמצא כרגע בבטא וזמין רק לחלק מהארגונים. אם אצלכם אין את האזור הזה בחלון ההוספה, היום אין דרך רשמית לחבר את שַׁגֵּר דרך הממשק של Desktop, והמסלול העובד הוא Claude Code או קוד שמדבר עם ממשק API. זה לא המדריך הכי נוח לכתוב, כי התשובה תלויה בחשבון שלכם. אבל עדיף להבין את המצב לפני שמבזבזים שעה על קובץ הגדרות שלא יעבוד. ## איך Claude Desktop מתחבר לשרתים מרוחקים? הנקודה הראשונה שחשוב להבין: שרת MCP מרוחק כמו של שַׁגֵּר לא מוגדר באפליקציית Claude Desktop דרך קובץ על המחשב, אלא כמחבר בחשבון Claude שלכם. ההנחיות של Anthropic ב[מדריך המחברים המותאמים](https://support.claude.com/en/articles/11175166-get-started-with-custom-connectors-using-remote-mcp) מבחינות בין שני מנגנונים נפרדים. שרתים מקומיים מוגדרים בקובץ `claude_desktop_config.json` ורצים על המחשב. מחברים מרוחקים מוגדרים בהגדרות החשבון, והמודל Claude מתחבר אליהם מהתשתית בענן של Anthropic ולא מהמכשיר שלכם. יש לזה שתי השלכות מעשיות. הראשונה היא שמחבר שהוספתם זמין גם באתר claude.ai בדפדפן, לא רק באפליקציה. השנייה היא שהשרת חייב להיות נגיש מהאינטרנט, וזה המצב אצל שַׁגֵּר, כך שאין צורך במנהרות או בהגדרות רשת. ## הוספת שַׁגֵּר כמחבר מותאם, צעד אחר צעד התהליך מתועד בעמוד [Add a connector that isn't in the directory](https://claude.com/docs/connectors/custom/add-unlisted). בחשבון אישי (Free, Pro או Max) הוא נראה כך: 1. נכנסים לתפריט Customize ואז Connectors ולוחצים על Add custom connector. 2. בשדה הכתובת מזינים `https://app.shager.ai/api/mcp`. 3. באימות בוחרים `No sign-in`. התיעוד אומר במפורש שאם השרת עובד עם מפתח API, זו האפשרות הנכונה, והמפתח עצמו נכנס תחת Request headers. 4. פותחים את Request headers, בוחרים את שם הכותרת `authorization` מהרשימה, ובערך מזינים `Bearer shgr_live_XXXXXXXX` כולל המילה Bearer והרווח. 5. מסמנים את הכותרת כשדה Required ולוחצים Add. הסעיף הרביעי הוא המקום שבו רוב הטעויות קורות. Claude שולח את הערך בדיוק כמו שהזנתם אותו ולא מוסיף לפניו כלום. אם תזינו רק את המפתח, השרת של שַׁגֵּר יקבל כותרת בלי Bearer ויחזיר 401. בחשבון Team או Enterprise רק Owner מוסיף מחבר מותאם, דרך Organization settings ואז Connectors, וחברי הצוות מתחברים אליו אחר כך. כאן יש מלכודת: כותרות מתאימות לאישור משותף אחד לכל הארגון. אם תגדירו את שַׁגֵּר ברמת הארגון עם מפתח אחד, כל הצוות יעבוד דרך אותו מפתח, וביומן הביקורת של שַׁגֵּר כל הפעולות ייראו כאילו בוצעו על ידי אותו סוכן. לסוכנות שרוצה לדעת מי עשה מה, זו לא תמיד הבחירה הנכונה. ## מה אם אין לי Request headers? התיעוד של Anthropic ברור: אם האזור Request headers לא מופיע בחלון ההוספה, לארגון שלכם עוד אין גישה לפיצ'ר. אין עקיפה בממשק. אפשר להוסיף את שַׁגֵּר כמחבר בלי כותרת, אבל אז כל קריאה תיכשל על אימות. מה כן אפשר לעשות היום: 1. **לעבוד עם Claude Code.** הוא תומך בכותרות מותאמות בפקודה אחת, והוא מתאים במיוחד לעבודה שגרתית של הפצה. ההגדרה המלאה נמצאת במדריך [לחיבור שַׁגֵּר אל Claude Code](/blog/connect-shager-to-claude-code). 2. **לעבוד עם ממשק REST API מקוד.** סקריפט קטן שמושך משימות מגיליון ושולח טיוטות לְשַׁגֵּר, כשהטקסטים נכתבים על ידי Claude דרך ממשק API של Anthropic. נקודת ההתחלה היא [המדריך המהיר לממשק REST API](/blog/shager-rest-api-quickstart). 3. **לחכות להתחברות OAuth של שַׁגֵּר.** התחברות OAuth לשרת MCP נמצאת בפיתוח. כשהיא תעלה, ההוספה באפליקציית Desktop תהיה כמו בכל מחבר אחר: כתובת, כניסה, אישור. ### ומה עם גשרים מקומיים? יש חבילות קהילה שרצות מקומית כשרת stdio ומעבירות בקשות לשרת מרוחק עם כותרת, ואפשר להגדיר אותן בקובץ `claude_desktop_config.json`. Anthropic לא מתעדת את הדרך הזו כמסלול לחיבור שרתים מרוחקים עם כותרות, ולכן אנחנו לא ממליצים עליה כפתרון קבוע. היא מוסיפה תהליך שרץ על המחשב עם המפתח שלכם, תלות בחבילה חיצונית, ונקודה נוספת שיכולה להישבר אחרי עדכון. אם כבר עובדים כך, שמרו לפחות את המפתח במשתנה סביבה ותנו לו הרשאות מינימליות. ## הגדרות בטיחות ששוות דקה גם כשהחיבור עובד, Claude Desktop הוא סביבה שיחתית. אנשים מבקשים דברים בשפה חופשית, ולפעמים מבקשים יותר ממה שהתכוונו. שלוש הגדרות שאני ממליץ עליהן לכל מי שמחבר את שַׁגֵּר: 1. **מפתח בלי `publish` בהתחלה.** כך הסוכן יכול לקרוא חשבונות וליצור טיוטות, אבל לא לתזמן. בְּשַׁגֵּר יוצרים ומבטלים מפתחות בכתובת `https://app.shager.ai/dashboard/agents`. 2. **חסימת כלים ספציפיים.** התיעוד של Anthropic מאפשר לבחור מחבר בתפריט Customize ואז Connectors ולסמן כלי מסוים במצב Blocked. אם המפתח כן כולל `publish` אבל אתם רוצים שבצ'אט הסוכן רק יכין טיוטות, חסמו את `schedule_post` ואת `cancel_post` ברמת המחבר. 3. **כיבוי המחבר כשלא צריך אותו.** דרך כפתור ה + בצ'אט אפשר להפעיל או לכבות מחברים לשיחה בודדת. שיחה על נושא אחר לא צריכה גישה לארבעים עמודים של לקוח. עוד פרט שכדאי לזכור: אחרי שמוסיפים מחבר, אי אפשר לערוך את הגדרות האימות שלו. כשמחליפים מפתח בְּשַׁגֵּר, למשל במסגרת סבב החלפה רבעוני, צריך להסיר את המחבר ולהוסיף אותו מחדש עם הערך החדש. ## מה עושים עם החיבור באפליקציית Desktop Desktop מתאים פחות לשגרות אוטומטיות ויותר לעבודה אינטראקטיבית של מנהלת תיק לקוח. כמה שימושים שעובדים טוב בצ'אט: 1. "תראה לי אילו פוסטים מתוזמנים לשבוע הבא בסביבה של הלקוח" (`list_posts` עם סינון לפי סטטוס). 2. "כמה לחיצות היו לכל סניף בחודש האחרון, ואיזה פוסט הביא הכי הרבה" (`get_analytics`). 3. "קח את הסרטון מהקישור הזה, העלה אותו, ותכין טיוטת Reel לקבוצת הסניפים בצפון עם כיתוב שונה לכל עמוד" (`upload_media_from_url` ואז `create_post` עם `per_channel`). 4. "שלח את הטיוטה הזו לאישור של מיכל מהלקוח" (`request_approval`). הבקשה האחרונה דורשת sandbox מאושר. אם המפתח נוצר בהרשמה עצמית של סוכן ועוד לא אושר על ידי אדם, שליחה לאישור לקוח חסומה. ההסבר המלא על התהליך נמצא ב[עמוד הסוכנים](/agents), ואת ההשוואה בין המסלולים, כולל המחיר לכל כמות חשבונות, תמצאו ב[עמוד המחירים](/pricing). המסקנה המעשית: אם יש לכם Request headers, חברו את שַׁגֵּר לאפליקציית Desktop עכשיו ותהנו מצ'אט שמכיר את כל החשבונות של הלקוחות. אם אין, אל תילחמו בזה. הגדירו את Claude Code לשגרה השבועית, והשאירו את Desktop לשאלות ולסקירות עד שהתחברות OAuth של שַׁגֵּר יעלה. ## שאלות נפוצות ### אפשר להגדיר את שַׁגֵּר בקובץ claude_desktop_config.json? הקובץ הזה מיועד לשרתים מקומיים שרצים על המחשב. שַׁגֵּר הוא שרת מרוחק, והדרך הרשמית לחבר שרת מרוחק היא מחבר מותאם בהגדרות החשבון. גשרים מקומיים קיימים, אבל הם לא חלק מהמסלול שמתועד אצל Anthropic. ### המחבר נוסף אבל כל קריאה נכשלת. מה בודקים? ברוב המקרים הערך של כותרת `authorization` הוזן בלי המילה Bearer, או שהמפתח בוטל בְּשַׁגֵּר. מסירים את המחבר ומוסיפים אותו מחדש עם `Bearer ` ואחריו המפתח המלא. אם אין לכם Request headers בכלל, החיבור לא יעבוד עד שהתחברות OAuth של שַׁגֵּר יעלה. ### האם מחבר באפליקציית Desktop זמין גם באתר claude.ai בדפדפן? כן. מחברים מותאמים שייכים לחשבון ולא למכשיר, והמודל Claude מתחבר אליהם מהענן של Anthropic. מה שהגדרתם באפליקציה יופיע גם בדפדפן. --- Source: https://shager.ai/blog/connect-shager-to-claude-desktop # אין תוכן, אין קיום: מותג שלא מפרסם בעקביות פשוט לא נמצא _2026-08-11 · כשסוכנים ומנועי תשובות מחליטים מה אנשים רואים, הם בוחרים רק מתוך מה שפורסם ונגיש. מותג שלא מפרסם בעקביות לא מפסיד חשיפה. הוא פשוט לא קיים בשבילם, וזה כבר קורה._ מותג שלא מפרסם בעקביות לא מפסיד חשיפה. הוא פשוט לא נמצא. כשסוכני AI ומנועי תשובות מרכיבים לאנשים את מה שהם רואים, הם עובדים רק עם מה שקיים ברשת, נגיש וטרי מספיק כדי להיות רלוונטי, ומי שלא השאיר עקבות לא נכנס לתשובה. זו לא תחזית לעתיד. זה מה שקורה כבר היום, כשלקוח שואל עוזר AI "איזה משרד רואי חשבון בפתח תקווה מתמחה בעסקים קטנים" ומקבל שלושה שמות. העסק הרביעי, שאולי טוב יותר מכולם, לא הפסיד בתחרות. הוא בכלל לא השתתף בה. ## מה השתנה בדרך שבה אנשים מוצאים עסקים? במשך עשרים שנה, השאלה של משווקים הייתה איך להגיע למקום גבוה ברשימה. רשימה של עשר תוצאות, ואחר כך פיד שמגלגלים בו. גם אם הייתם במקום השמיני, הייתם שם. מישהו יכול היה לגלול ולמצוא אתכם. היום יש שכבה נוספת בין האדם לבין הרשת: מישהו שקורא בשבילו. זה יכול להיות AI Overview בגוגל, עוזר צ'אט, או סוכן שמבצע מחקר עבור מנהל רכש. השכבה הזו לא מציגה רשימה ארוכה. היא מסכמת, בוחרת ומצטטת. המקום השמיני כבר לא קיים. גוגל עצמה מבהירה בתיעוד שלה ל[פיצ'רים של AI בחיפוש](https://developers.google.com/search/docs/appearance/ai-features) שאין דרישות מיוחדות כדי להופיע בתשובות AI Overviews או במצב AI Mode, מעבר לכך שהעמוד צריך להיות מאונדקס וזכאי להופיע בחיפוש עם קטע תקציר. במילים אחרות, אין קיצור דרך טכני. הבסיס הוא שיהיה תוכן אמיתי, נגיש וקריא. מי שאין לו תוכן, אין לגוגל מה לצטט. ## למה עקביות חשובה יותר מוויראליות הרבה מנהלי שיווק עדיין חושבים במונחים של "הפוסט הגדול". קמפיין אחד חזק ברבעון, הרבה השקעה בהפקה, ואחר כך שקט. במודל הישן זה עבד פחות או יותר, כי תשומת לב הייתה משאב שקונים. במודל שבו סוכנים קוראים בשבילנו, שלושה דברים מתגמלים עקביות: 1. **טריות.** כשמישהו שואל מה המבצע הנוכחי, מה שעות הפתיחה בחג או מה חדש בתחום, תוכן מלפני חצי שנה פחות שימושי. עסק שמפרסם כל שבוע נותן לקורא, אנושי או לא, סיבה לחשוב שהוא פעיל. 2. **עומק נושאי.** פוסט בודד על נושא הוא נקודה. עשרים פוסטים על אותו תחום לאורך שנה הם דפוס, ודפוס הוא מה שגורם למערכת לשייך אתכם לתחום. 3. **נוכחות בכמה ערוצים.** עמוד פייסבוק, חשבון אינסטגרם, ערוץ יוטיוב ואתר שמדברים באותו קול מחזקים זה את זה. כשמותג מופיע רק במקום אחד, קל לפספס אותו. ברשתות החברתיות זה בולט עוד יותר. פיד הוא מנגנון בחירה. עמוד שלא פרסם חודש פשוט לא נכנס לבחירה, לא משנה כמה עוקבים יש לו. ## הטענה הנגדית: "יותר תוכן זה סתם רעש" יש בטענה הזו משהו נכון, ואסור להתעלם ממנו. עקביות היא לא היתר להציף. גוגל מגדירה ב[מדיניות הספאם שלה](https://developers.google.com/search/docs/essentials/spam-policies) מה שהיא מכנה scaled content abuse: יצירה של כמויות גדולות של תוכן לא מקורי שמביא מעט ערך או בכלל לא, לא משנה איך הוא נוצר, ואחת הדוגמאות שהיא נותנת היא שימוש בכלי AI כדי לייצר הרבה עמודים בלי להוסיף ערך למשתמשים. גם [מדיניות הספאם של Meta](https://transparency.meta.com/policies/community-standards/spam/) אוסרת פרסום בתדירות גבוהה מאוד, ידנית או אוטומטית, ומציינת תוכן חוזר כאחד הסימנים לספאם. אז התזה המדויקת היא כזו: מותג צריך לפרסם בעקביות תוכן שיש בו ערך אמיתי, בקצב שהוא יכול להחזיק לאורך זמן. לא כמה שיותר. כמה שאפשר להחזיק בלי לרדת באיכות. ## איך נראית עקביות בפועל אצל סוכנות ברוב העסקים שאני רואה, הבעיה היא לא חוסר ברעיונות. היא חוסר בזמן ובתהליך. הנה מבנה עבודה שעובד אצל סוכנויות שמחזיקות עשרות לקוחות: 1. **שלושה עד חמישה עמודי תוכן לכל לקוח.** נושאים קבועים שהלקוח רוצה להיות מזוהה איתם. לא יותר, כי אז הכל מתפזר. 2. **מקור אחד, הרבה צורות.** הקלטת וידאו אחת של בעל העסק הופכת לסרטון Reel, לסרטון Short, לפוסט עם ציטוט ולמאמר באתר. החומר הגולמי הוא המשאב היקר. ההפצה צריכה להיות זולה. 3. **קצב מינימלי שנקבע מראש.** כל לקוח מקבל רצפה שבועית שלא יורדים ממנה, גם בשבוע עמוס. את המספר קובעים לפי מה שהלקוח מסוגל לייצר, לא לפי מה שנשמע טוב במצגת. 4. **לוח שנה ישראלי.** חגים, חופשות וימי זיכרון משנים את הקצב ואת הטון. תכנון שמתעלם מהם נשבר כל ספטמבר. 5. **ניסוח שונה לכל חשבון.** אותו מסר, אבל לא אותו טקסט בשלושים עמודים. זה גם מונע תחושת שכפול וגם מתאים לקהל המקומי. הצעד הרביעי והחמישי הם בדיוק איפה שסוכנויות נשברות כשהכל ידני. פירטתי את השיטה לניסוח שונה לכל חשבון ב[מאמר על גיוון כיתובים עם AI](/blog/caption-variation-per-account-with-ai). ## למה כאן נכנסים סוכנים אם עקביות היא תנאי לקיום, צריך לשאול מי מחזיק אותה. התשובה הכנה היא שבני אדם לא מחזיקים עקביות לאורך זמן כשמדובר בעבודה חוזרת. הם חולים, יוצאים למילואים, מחליפים עבודה, ובחגים הכל עוצר. סוכן AI שמחובר לפלטפורמת הפצה יכול להחזיק את הרצפה. הוא לא ממציא את האסטרטגיה, אבל הוא מוודא שהתוכן שאושר יוצא בזמן, בכל החשבונות, עם תיוג נכון ועם ניסוח מותאם. כך נראית בקשה טיפוסית לסוכן שמחובר לְשַׁגֵּר: ```text יש לך גישה לשגר דרך MCP. בסביבת העבודה של הלקוח "מאפיית השכונה": 1. קרא את רשימת הערוצים עם list_channels. 2. העלה את הווידאו מהקישור עם upload_media_from_url, כולל width, height ו duration_ms. 3. צור טיוטה אחת עם create_post בפורמט REEL לכל הסניפים, עם per_channel שבו כל סניף מקבל ניסוח שמזכיר את השכונה שלו. 4. שים את קישור ההזמנה ב cta_url ואת הקריאה לפעולה ב first_comment. 5. שלח לאישור הלקוח עם request_approval ותחזיר לי את הקישור. אל תתזמן לפני שהלקוח אישר. ``` הסוכן הוא לא העיקר כאן. העיקר הוא שהתהליך מתבצע גם בשבוע שבו אף אחד בסוכנות לא היה פנוי. הסברתי למה ההפצה עצמה היא העבודה הנכונה לסוכן במאמר [למה סוכן AI צריך להריץ את ההפצה](/blog/why-agents-should-run-distribution). ## ומה עם האתר עצמו? רשתות חברתיות הן חצי מהתמונה. סוכנים ומנועי תשובות קוראים גם אתרים, ואתר שכל התוכן שלו נעול בתמונות, בסליידרים או בקבצי PDF סרוקים קשה לקריאה. גוגל ממליצה במפורש להחזיק את התוכן החשוב בצורת טקסט ולאפשר סריקה, וזה נכון לכל קורא אוטומטי. יש גם צעדים שאתרים עושים כדי להקל על סוכנים לקרוא אותם, כמו קובץ llms.txt וגרסאות Markdown של עמודים. גוגל אומרת שאין צורך בהם כדי להופיע בתשובות AI Overviews, אבל הם יכולים לעזור לסוכנים אחרים. כתבתי על זה ב[מדריך לאתרים שמוכנים לסוכנים](/blog/agent-ready-websites-llms-txt). שַׁגֵּר עצמו מפרסם קבצים כאלה, כי אנחנו מצפים שסוכנים יקראו אותנו. ## מה לעשות השבוע אם אתם מנהלים מותג או סוכנות, הנה בדיקה פשוטה: 1. פתחו את העמודים של שלושת הלקוחות הכי שקטים שלכם. מתי הפוסט האחרון? 2. שאלו עוזר AI שאלה שלקוח פוטנציאלי היה שואל בתחום שלהם. האם הם מופיעים? 3. אם לא, אל תתחילו מקמפיין. תתחילו מרצפה: מה הקצב המינימלי שאפשר להחזיק חצי שנה בלי להתפשר על איכות? הבדיקה הזו לא מדעית, אבל היא מראה מהר מאוד איפה אתם עומדים. ## שאלות נפוצות ### האם פרסום יומי משפר את הסיכוי להופיע בתשובות של AI? אין מסמך רשמי שקובע קצב מסוים. מה שגוגל כן אומרת הוא שאין דרישות מיוחדות מעבר לתוכן מאונדקס ומועיל, ושכמויות גדולות של תוכן חסר ערך נחשבות ספאם. לכן הקצב הנכון הוא הקצב שבו אתם מסוגלים לייצר ערך אמיתי לאורך זמן. ### האם תוכן שנכתב בעזרת AI נחשב ספאם? לא בעצם היותו כתוב בעזרת AI. ההנחיות של גוגל על [תוכן מועיל](https://developers.google.com/search/docs/fundamentals/creating-helpful-content) עוסקות ב"איך" נוצר התוכן ומעודדות שקיפות, והבעיה מתחילה כשאוטומציה משמשת בעיקר כדי לתמרן דירוג. תוכן שאדם עם ידע אמיתי עמד מאחוריו ובדק אותו הוא דבר אחר לגמרי. ### מה המינימום שעסק קטן צריך לפרסם? אין מספר אחד נכון. התחילו ממה שאתם יכולים להחזיק בלי מאמץ חריג, גם בשבוע עמוס, וודאו שהתוכן יוצא בכל הערוצים שלכם ולא רק באחד. עקביות לאורך חצי שנה שווה יותר מחודש אחד אינטנסיבי. אם הגעתם למסקנה שהבעיה אצלכם היא התהליך ולא הרעיונות, הצעד הבא הוא לראות איך סוכן מחזיק את הרצפה בשבילכם. [עמוד הסוכנים](/agents) מסביר איך מחברים סוכן לְשַׁגֵּר, ו[המאמר על שיווק מותג ולידים בעולם B2B](/blog/b2b-brand-marketing-lead-generation) נותן את ההקשר העסקי למה עקביות מתורגמת בסוף לפניות. --- Source: https://shager.ai/blog/no-content-no-existence # איך מחברים את שַׁגֵּר אל Claude Code: פקודה אחת, מפתח אחד ובדיקה שהכול עובד _2026-08-04 · מדריך מעשי לחיבור שרת MCP של שַׁגֵּר אל Claude Code: הפקודה claude mcp add עם כותרת Authorization, בחירת scope, קובץ .mcp.json לצוות ובדיקת חיבור ראשונה ומהירה._ כדי לחבר את שַׁגֵּר אל Claude Code מריצים פקודה אחת בטרמינל: `claude mcp add` עם תעבורת HTTP, הכתובת `https://app.shager.ai/api/mcp` וכותרת `Authorization` שמכילה מפתח API של שַׁגֵּר. אחרי זה פותחים את Claude Code, מקלידים `/mcp` כדי לוודא שהשרת מחובר, ומבקשים מהסוכן להריץ את הכלי `whoami`. כל התהליך לוקח פחות מחמש דקות, ובסופו לסוכן יש גישה לכל הכלים של שַׁגֵּר: סביבות עבודה, חשבונות, מדיה, פוסטים ואנליטיקס. המדריך הזה מיועד למי שכבר עובד עם Claude Code ורוצה שהסוכן יוכל להכין ולהפיץ תוכן לעשרות עמודים וערוצים בלי לעבור בממשק ידנית. אם אתם עוד לא בטוחים מה סוכן אמור לעשות בתוך מערכת הפצה, כדאי להתחיל מ[עמוד הסוכנים של שַׁגֵּר](/agents) ולחזור לכאן. ## מה צריך לפני שמתחילים? שלושה דברים, וזהו: 1. Claude Code מותקן ומחובר לחשבון שלכם. 2. מפתח API של שַׁגֵּר שמתחיל בתחילית `shgr_live_`. 3. סביבת עבודה אחת לפחות בְּשַׁגֵּר, עדיף עם חשבון מחובר אחד כדי שתוכלו לבדוק משהו אמיתי. את המפתח אפשר להשיג בשתי דרכים. הדרך הרגילה היא שאדם בצוות נכנס לכתובת `https://app.shager.ai/dashboard/agents`, יוצר מפתח ובוחר לו הרשאות. הדרך השנייה היא שהסוכן עצמו נרשם דרך נקודת הקצה (endpoint) של ההרשמה העצמית ומקבל sandbox שאדם מאשר אחר כך. את המסלול השני פירטנו במדריך על [הרשמה עצמית של סוכן ואישור בעלות](/blog/agent-self-signup-and-claim). ### איזה הרשאות לתת למפתח? למפתחות של שַׁגֵּר יש שלוש הרשאות: `read`, `write` וגם `publish`. בשבוע הראשון אני ממליץ על `read` וגם `write` בלבד. כך הסוכן יכול לקרוא חשבונות, להעלות מדיה וליצור טיוטות, אבל לא לתזמן ולא לפרסם. אחרי שראיתם כמה טיוטות טובות ואתם סומכים על התהליך, יוצרים מפתח חדש עם `publish` ומחליפים. זה עדיף בהרבה על להתחיל עם הכול פתוח ולגלות טעות אחרי שפוסט כבר עלה לארבעים עמודים. ## הפקודה עצמה התיעוד הרשמי של Anthropic מתאר את התחביר להוספת שרת מרוחק עם טוקן ב[עמוד MCP של Claude Code](https://code.claude.com/docs/en/mcp): קודם הדגל `--transport http`, אחריו שם השרת, אחריו הכתובת, ובסוף הכותרת. עבור שַׁגֵּר זה נראה כך: ```bash claude mcp add --transport http shager https://app.shager.ai/api/mcp \ --header "Authorization: Bearer shgr_live_XXXXXXXXXXXXXXXX" ``` כמה הערות מהשטח: השם `shager` הוא השם שהסוכן יראה. הכלים יופיעו אצלו בשמות כמו `mcp__shager__create_post`, ושם קצר וברור עוזר כשמגדירים הרשאות בהמשך. הפקודה לא בודקת את המפתח בזמן ההוספה. התיעוד אומר במפורש שטוקן שגוי ייכשל רק בזמן ההתחברות, כך שאם טעיתם בהעתקה תגלו את זה בפקודה `/mcp` ולא כאן. אם תכתבו בפקודה `$SHAGER_API_KEY` במקום המפתח עצמו, מעטפת הפקודות (shell) תחליף אותו בערך האמיתי עוד לפני שהכלי Claude Code רואה אותו, והמפתח יישמר כטקסט גלוי בקובץ ההגדרות. זה בסדר על מחשב אישי, פחות בסדר על מכונה משותפת. ## איפה החיבור נשמר: local, project או user הפקודה מקבלת דגל `--scope`, ולכל אחת מהאפשרויות יש משמעות מעשית לסוכנות: | Scope | איפה זמין | משותף עם הצוות | איפה נשמר | |---|---|---|---| | local (ברירת מחדל) | רק בפרויקט הנוכחי | לא | `~/.claude.json` | | project | רק בפרויקט הנוכחי | כן, דרך git | `.mcp.json` בשורש הפרויקט | | user | בכל הפרויקטים שלכם | לא | `~/.claude.json` | אם אתם עובדים לבד וְשַׁגֵּר הוא כלי שאתם רוצים בכל מקום, `--scope user` הוא הבחירה הנוחה. אם יש לכם ריפו של "מערכת תוכן" שכל הצוות עובד ממנו, עדיף project, אבל אז אסור שהמפתח יישב בקובץ. ### קובץ .mcp.json לצוות, בלי מפתח בתוכו Claude Code תומך בהרחבת משתני סביבה בתוך `.mcp.json`, כולל בשדות `url` וגם `headers`. התחביר מתועד באותו [עמוד MCP](https://code.claude.com/docs/en/mcp) ונראה כך: ```json { "mcpServers": { "shager": { "type": "http", "url": "https://app.shager.ai/api/mcp", "headers": { "Authorization": "Bearer ${SHAGER_API_KEY}" } } } } ``` כל אחד בצוות מגדיר אצלו את `SHAGER_API_KEY` עם המפתח האישי שלו, והקובץ עצמו נכנס למאגר git בלי סודות. יש לזה יתרון נוסף: ביומן הביקורת של שַׁגֵּר תראו איזה מפתח ביצע כל קריאה, כלומר מי בצוות עמד מאחורי כל פעולה של הסוכן. אם המשתנה לא מוגדר, Claude Code יציג אזהרה בפקודה `/mcp` והחיבור ייכשל, וזה בדיוק מה שאתם רוצים. בפעם הראשונה שהכלי Claude Code פוגש שרת מהקובץ `.mcp.json` בסשן אינטראקטיבי, הוא מבקש אישור לפני השימוש בו. זה התנהגות מכוונת, לא תקלה. ## בדיקה ראשונה: חמש דקות שחוסכות שעה אחרי ההוספה, פותחים `claude` בתיקייה הרלוונטית ומקלידים `/mcp`. השרת `shager` צריך להופיע במצב connected. אם הוא מופיע במצב failed, פרטי השגיאה יכללו את קוד תגובת HTTP. קוד 401 כמעט תמיד אומר שהמפתח הועתק חלקית או שחסרה המילה `Bearer` לפניו. עכשיו בקשה ראשונה בשפה טבעית: ```text תריץ whoami ו list_workspaces בשגר ותגיד לי לאיזה ארגון אתה מחובר, אילו הרשאות יש למפתח, ואילו סביבות עבודה קיימות. ``` אם התשובה כוללת את שם הארגון ואת רשימת הסביבות, החיבור עובד. הצעד הבא הוא `list_channels` על סביבה אחת, כדי לראות את העמודים והערוצים המחוברים עם המזהים שלהם. ### טיוטה אחת לפני הכול לפני שנותנים לסוכן לרוץ על עשרות חשבונות, כדאי לבקש ממנו פוסט טיוטה אחד: ```text בסביבת העבודה "לקוח בדיקה", צור טיוטה עם create_post לשני החשבונות הראשונים ברשימה. כיתוב שונה לכל חשבון דרך per_channel, cta_url לדף הנחיתה, ו first_comment שמזמין ללחוץ. אל תתזמן. ``` נכנסים לְשַׁגֵּר ומסתכלים על הטיוטה בעיניים. בודקים שכל חשבון קיבל ניסוח משלו, שהקישור נכון, ושהתגובה הראשונה הגיונית. הבעיה הנפוצה בטיוטות ראשונות של סוכן היא בדרך כלל לא טכנית אלא טון: עברית תקינה, אבל רשמית מדי לעמוד של סניף שכונתי. את זה מתקנים בהנחיות, ולכן השלב הבא הגיוני הוא [לבנות skill ייעודי לְשַׁגֵּר](/blog/build-a-claude-skill-for-shager) שמחזיק את כללי הטון, הפורמט והבטיחות במקום אחד. ## תקלות נפוצות ואיך לזהות אותן מהר | סימפטום | סיבה סבירה | מה עושים | |---|---|---| | השרת failed עם 401 | מפתח חסר, שגוי או בוטל | יוצרים מפתח חדש ובודקים שיש `Bearer ` עם רווח | | השרת מחובר אבל create_post נכשל על הרשאה | למפתח אין `write` | מוסיפים הרשאה או יוצרים מפתח חדש | | schedule_post נכשל | למפתח אין `publish`, או שסביבת sandbox עדיין לא אושרה | אדם מאשר את סביבת sandbox או מעדכן הרשאות | | שגיאות בקצב גבוה | יותר מ 120 קריאות בדקה למפתח | לבקש מהסוכן לעבוד באצוות ולא חשבון אחרי חשבון | כל השגיאות של שַׁגֵּר חוזרות במבנה `{ "error": { "code", "message" } }`, כך שהסוכן מקבל הסבר קריא ולא רק קוד. כשפוסט נדחה כי הרשת הייתה דוחה אותו, למשל וידאו באורך שלא מתאים לפורמט Short, ההודעה אומרת מה בדיוק לא עבר. ## מה הסוכן יכול לעשות מכאן אחרי החיבור, Claude Code רואה את אותן פעולות שקיימות בממשק REST API: ניהול סביבות עבודה וקבוצות חשבונות, העלאת מדיה מכתובת URL, יצירת פוסטים כטיוטה או מתוזמנים, שליחה לאישור לקוח, ומשיכת לחיצות לפי חשבון ולפי פוסט עם `get_analytics`. ההבדל מכלי פרסום רגיל הוא שהסוכן עובד ברמת החשבון: כיתוב שונה לכל עמוד, קישור מקוצר ופרמטרי UTM נפרדים לכל עמוד, ופיזור זמני השליחה בין חשבונות כברירת מחדל של 30 עד 90 שניות. אם חלק מהצוות שלכם עובד בעורך Cursor ולא בטרמינל, ההגדרה שם כמעט זהה ומופיעה במדריך [לחיבור שַׁגֵּר אל Cursor](/blog/connect-shager-to-cursor). הגישה לממשק API ולשרת MCP כלולה בכל המסלולים, כולל החינמי, כפי שמופיע ב[עמוד המחירים](/pricing). הצעד הבא אחרי חיבור עובד הוא לא עוד פיצ'ר, אלא שגרה: להגדיר לסוכן מה הוא עושה כל שבוע, באיזה סדר, ואיפה הוא עוצר ומחכה לאדם. התחילו מטיוטה אחת, תקנו את ההנחיות, ורק אז הרחיבו לקבוצת חשבונות שלמה. ## שאלות נפוצות ### האם Claude Code תומך באימות OAuth מול שַׁגֵּר? לא כרגע, כי שַׁגֵּר עדיין לא מציע התחברות OAuth לשרת MCP. האימות היום הוא מפתח API בכותרת `Authorization`, וזה עובד היטב בכלי Claude Code כי הוא תומך בכותרות מותאמות. OAuth נמצא בפיתוח. ### מה ההבדל בין scope מסוג user לבין project? user שומר את החיבור אצלכם בלבד וזמין בכל פרויקט על המחשב. project כותב קובץ `.mcp.json` לשורש הריפו כדי שכל הצוות יקבל את אותו חיבור. בשני המקרים עדיף שהמפתח עצמו יגיע ממשתנה סביבה. ### איך מבטלים גישה של סוכן אם משהו השתבש? נכנסים לכתובת `https://app.shager.ai/dashboard/agents` ומבטלים את המפתח. מהרגע הזה כל קריאה של הסוכן תיכשל, וביומן הביקורת אפשר לראות בדיוק אילו פעולות הוא ביצע עד אז. --- Source: https://shager.ai/blog/connect-shager-to-claude-code # למה סוכן AI צריך להריץ את ההפצה ולא רק לכתוב את הפוסטים _2026-08-04 · כתיבה היא החלק הקל. ההפצה לעשרות חשבונות היא עבודה חוזרת, מבוססת חוקים ורגישה לטעויות, ובדיוק שם סוכן AI עם כלים נכונים ובקרה אנושית מחזיר את ההשקעה שלו._ סוכן AI צריך להריץ את ההפצה כי זה החלק בעבודה השיווקית שהכי מתאים לו: הרבה צעדים קטנים, חוקים ברורים, ואפס צורך בהשראה. הכתיבה עצמה כבר מזמן לא צוואר הבקבוק בסוכנות. מה שאוכל את השבוע הוא להעלות את אותו קמפיין לארבעים עמודים, להתאים פורמט, לתזמן, לבדוק שהכל יצא ולאסוף נתונים, וזו בדיוק עבודה שסוכן עם גישה לכלים הנכונים עושה טוב יותר מאדם עייף ביום חמישי בצהריים. רוב הסוכנויות שאני מכיר התחילו להשתמש בבינה מלאכותית מהצד הלא נכון. נתנו למודל לכתוב פוסטים, ואז העתיקו אותם ידנית לממשק של כל רשת. החיסכון היה קטן, כי הכתיבה הייתה בערך חמישית מהעבודה. השאר נשאר ידני. ## מה בעצם כולל "להפיץ קמפיין"? כדאי לפרק את זה לצעדים, כי ברגע שרואים את הרשימה מבינים למה זה לא תפקיד של אדם. נניח רשת של 30 סניפים, לכל אחד עמוד פייסבוק וחשבון אינסטגרם מקצועי, וחלקם גם ערוץ יוטיוב: 1. לאסוף את הנכסים: וידאו, תמונה, טקסט בסיס, קישור לדף נחיתה. 2. לבדוק שהווידאו עומד בדרישות של כל פורמט: Reel, Short, Story או פוסט רגיל. 3. להתאים ניסוח לכל עמוד, כדי שהפוסטים לא ייראו כמו שכפול. 4. לבנות קישור עם תיוג UTM נפרד לכל חשבון, אחרת אי אפשר לדעת מאיזה סניף הגיע הליד. 5. לשים את הקישור בתגובה הראשונה, איפה שזה רלוונטי. 6. לשלוח ללקוח לאישור, לחכות, לתקן. 7. לתזמן, ולפזר את הפרסום כדי שלא יצאו 60 פוסטים באותה שנייה. 8. לבדוק אחרי הפרסום אילו פוסטים נכשלו ולמה. 9. לאסוף לחיצות לפי חשבון ולהכין דוח. תשעה צעדים, כפול 60 חשבונות, כפול כמה קמפיינים בשבוע. אף אחד מהצעדים האלה לא דורש שיקול דעת יצירתי. כולם דורשים דיוק ועקביות. אנשים טובים בשיקול דעת וגרועים בעקביות לאורך זמן. סוכנים הפוך. ## למה עכשיו זה אפשרי, ולא לפני שנתיים? הסיבה המעשית היא שסוכנים קיבלו דרך מסודרת לעבוד עם מערכות חיצוניות. [Model Context Protocol](https://www.anthropic.com/news/model-context-protocol), שאנתרופיק פרסמה בנובמבר 2024 כתקן פתוח, מגדיר איך סוכן מגלה אילו כלים זמינים לו ואיך הוא קורא להם. במקום שמודל יכתוב טקסט ואדם יעתיק אותו, המודל קורא לכלי שנקרא `create_post` עם הפרמטרים הנכונים, ומקבל בחזרה תשובה מובנית. זה ההבדל בין עוזר כתיבה לבין מפעיל. עוזר כתיבה מייצר טיוטות. מפעיל מבצע תהליך מקצה לקצה ומדווח מה קרה. הסברתי את הפרוטוקול עצמו בשפה של משווקים במאמר [MCP למשווקים](/blog/mcp-explained-for-marketers). ## איך נראה תהליך הפצה שסוכן מריץ בְּשַׁגֵּר שַׁגֵּר נבנה מראש כך שסוכן יוכל להפעיל אותו. יש שרת MCP מרוחק וגם REST API עם אותן פעולות בדיוק, כך שאין יכולת שקיימת רק בממשק. כך נראה רצף טיפוסי של קריאות לקמפיין שבועי: ```text whoami() list_workspaces() list_channels(workspace_id) list_groups(workspace_id) upload_media_from_url(workspace_id, url, file_name, width, height, duration_ms) create_post(workspace_id, caption, group_ids, media_ids, format: "REEL", cta_url, first_comment, campaign, per_channel: [...], stagger_seconds: [30, 90]) request_approval(workspace_id, post_id, reviewer_name) get_post(workspace_id, post_id) schedule_post(workspace_id, post_id, schedule_at: "2026-08-09T10:00:00+03:00") get_analytics(workspace_id, from, to) ``` כמה דברים קורים כאן בלי שמישהו יצטרך לזכור אותם. השדה `cta_url` גורם לכך שכל חשבון מקבל קישור מקוצר ותיוג UTM משלו, כשהפרמטר utm_content מזהה את החשבון. השדה `per_channel` מאפשר ניסוח שונה לכל עמוד. השדה `stagger_seconds` מפזר את השליחה בין חשבונות של אותה רשת, ובברירת מחדל ההמתנה היא בין 30 שניות לדקה וחצי. ולפני השליחה, כל פוסט נבדק מול החוקים של הרשת שאליה הוא יוצא. את התהליך המלא, מהבריף ועד הדוח, פירטתי ב[מדריך לצינור תוכן של סוכן מקצה לקצה](/blog/agent-content-pipeline-end-to-end). ## חלוקת העבודה: מה נשאר אצל בני אדם הטענה כאן היא לא שסוכן מחליף את הצוות. היא שהצוות מפסיק לעשות עבודה של רובוט. כך אני ממליץ לחלק: | תחום | סוכן | אדם | |---|---|---| | אסטרטגיה ומסר מרכזי | מציע כיוונים | מחליט | | ניסוח לכל חשבון | כותב וריאציות | בודק דגימה | | התאמת פורמט ומדיה | מבצע | מטפל בחריגים | | תיוג וקישורים | מבצע | מגדיר מוסכמה פעם אחת | | אישור לקוח | שולח ועוקב | הלקוח מאשר | | תזמון ופרסום | מבצע בהרשאה | מחליט אם לתת הרשאה | | ניטור כשלים | בודק ומדווח | מחליט מה לתקן | | דוח ותובנות | מרכיב | מפרש ומציג ללקוח | שימו לב לשורה של אישור לקוח. בְּשַׁגֵּר הסוכן יוצר קישור אישור עם `request_approval`, והלקוח מאשר בלי להתחבר לשום מערכת. הסוכן לא "מחליט" שהפוסט מאושר. הוא מחכה. הרחבתי על זה במאמר על [אישור אנושי לפוסטים של סוכן](/blog/human-approval-for-agent-posts). ## אבל מה עם הסיכון? זו השאלה הנכונה, והיא הסיבה שרוב הסוכנויות עדיין מהססות. סוכן שמפרסם לשישים עמודים יכול גם לטעות בשישים עמודים. לכן ההרשאות צריכות להיות מדורגות, והמערכת צריכה לתמוך בזה מהיסוד. בְּשַׁגֵּר זה בנוי כך: 1. סוכן יכול לפתוח לעצמו סביבת ארגז חול בלי אדם, דרך קריאת הרשמה אחת. בסביבה הזו הוא יכול ליצור טיוטות, להעלות מדיה ולקרוא נתונים, אבל לא לתזמן ולא לפרסם. 2. רק אחרי שאדם פותח את קישור התביעה (claim_url), מתחבר ומאשר, הסביבה עוברת לבעלותו. בשלב הזה האדם בוחר אם המפתח של הסוכן מקבל גם הרשאת `publish`. 3. למפתחות יש שלוש הרשאות: `read`, `write` וגם `publish`. אפשר לתת לסוכן כתיבה בלי פרסום, ולהשאיר את הכפתור האחרון לאדם. 4. כל קריאה של סוכן נרשמת ביומן ביקורת בלוח הבקרה של הסוכנים, כך שתמיד אפשר לדעת מי עשה מה ומתי. את תהליך ההרשמה העצמית אפשר לקרוא ב[מתכון ההרשמה לסוכנים](/auth.md). את הכללים המעשיים לפרסום בהיקף פירטתי ב[חוקי בטיחות לסוכנים](/blog/safety-rules-for-agents-posting-at-scale). ## איפה סוכנים עדיין לא טובים כדי להיות הוגן, יש דברים שלא הייתי נותן לסוכן לעשות לבד: 1. תוכן שתלוי באירוע חדשותי או ברגישות ציבורית. סוכן לא קורא את מצב הרוח בארץ באותו בוקר. 2. תגובה למשבר אצל לקוח. כאן צריך אדם עם אחריות. 3. החלטה על תקציב או על שינוי מסר אסטרטגי. 4. כל דבר שמבטיח ללקוח קצה משהו משפטי, כמו מחיר, תנאי מבצע או התחייבות. בכל המקרים האלה הסוכן יכול להכין, אבל אדם צריך לחתום. ## איך מתחילים בלי לשבור כלום הדרך הבטוחה היא בשלבים. בשבוע הראשון הסוכן רק יוצר טיוטות לקמפיין אחד, ואתם בודקים אותן בממשק. בשבוע השני הוא שולח לאישור לקוח בעצמו. בשבוע השלישי, אם הכל עבד, נותנים למפתח הרשאת פרסום עבור סביבת עבודה אחת. רק אחר כך מרחיבים. זה גם מה שאני ממליץ ללקוחות של סוכנויות לשמוע: הסוכן לא מקבל מפתחות לכל הממלכה ביום הראשון. הוא מרוויח אותם. ## שאלות נפוצות ### האם סוכן AI יכול לפרסם לבד בְּשַׁגֵּר בלי אדם? סוכן יכול להירשם לבד ולעבוד בארגז חול, אבל לא לתזמן ולא לפרסם. רק אחרי שאדם תובע את הסביבה ובוחר לתת הרשאת `publish`, המפתח של הסוכן יכול לתזמן ולפרסם. גם אז כל קריאה נרשמת ביומן ביקורת. ### במה זה שונה מכלי תזמון רגיל עם AI מובנה? כלי תזמון עם עוזר כתיבה עוזר לאדם שיושב מול המסך. כאן הסוכן עצמו הוא המפעיל: הוא קורא לפעולות דרך MCP או REST, מקבל תשובות מובנות ומריץ תהליך שלם. האדם מגדיר כללים ומאשר, במקום ללחוץ על כל כפתור. ### אילו רשתות סוכן יכול להפעיל דרך שַׁגֵּר היום? עמודי פייסבוק, חשבונות אינסטגרם מקצועיים וערוצי יוטיוב זמינים היום, דרך הממשקים הרשמיים של הרשתות בלבד. טיקטוק ולינקדאין בפיתוח. אם אתם רוצים לראות איך זה נראה בפועל, הנקודה הטבעית להתחיל בה היא [עמוד הסוכנים של שַׁגֵּר](/agents), שמרכז את כתובת שרת MCP, את תיעוד REST API ואת קובץ הסקיל. משם אפשר לחבר את Claude Code או כל לקוח אחר ולהריץ קמפיין טיוטה ראשון עוד היום. --- Source: https://shager.ai/blog/why-agents-should-run-distribution # מדיניות פרטיות שַׁגֵּר היא מערכת לסוכנויות ולצוותי שיווק: מתזמנים בה תוכן, מפיצים אותו לחשבונות ברשתות החברתיות שאתם מנהלים, ומודדים את הקליקים והלידים שהוא מביא. המערכת מופעלת על ידי יניב פרסלר (Yaniv Presler). בכל שאלה על פרטיות אפשר לכתוב לכתובת yaniv.presler@gmail.com. המדיניות חלה על האתר shager.ai, על אפליקציית שַׁגֵּר ועל הקישורים המקוצרים שֶׁשַּׁגֵּר יוצרת. היא נכתבה בשביל מי שמשתמש בְּשַׁגֵּר (אנשי סוכנויות והלקוחות שלהם) ובשביל כל מי שסוכנות הזינה את הפרטים שלו למערכת. ## מי אחראי על המידע | המידע | מי מחליט מה נעשה בו | התפקיד שלנו | |---|---|---| | חשבון הַשַּׁגֵּר שלכם (שם, מייל, התחברות, הגדרות צוות, איש קשר לחיוב) | יניב פרסלר (Yaniv Presler) | בעלי המאגר (Controller) | | מבקרים באתר והודעות מטופס יצירת הקשר | יניב פרסלר (Yaniv Presler) | בעלי המאגר (Controller) | | מידע שהסוכנות מכניסה על הלקוחות שלה ועל הקהל שלהם: פרטי לקוחות, אנשי קשר לאישור, פוסטים, מדיה, חשבונות מחוברים, קליקים ולידים | הסוכנות (הלקוחה שלנו) | מחזיקים במידע עבורה (Processor), לפי [הסכם עיבוד הנתונים](/dpa) | אם אתם לקוחות של סוכנות שעובדת עם שַׁגֵּר, הסוכנות אחראית על המידע שלכם. אפשר לפנות אליה ישירות, או לכתוב לנו ונעביר את הבקשה. **התקנה עצמית.** אפשר להתקין את שַׁגֵּר גם על שרתים של הלקוח. במקרה כזה, מי שמפעיל את ההתקנה הוא האחראי על כל המידע שבה, והמדיניות הזו חלה רק אם הוא אימץ אותה. ## איזה מידע נשמר ### חשבון המשתמש - שם וכתובת מייל. - סיסמה מוצפנת בגיבוב (hash), או התחברות עם גוגל (ואז אנחנו מקבלים מגוגל שם, מייל ותמונת פרופיל). - התפקיד שלכם בצוות ומי עוד בצוות. ### תוכן העבודה - לקוחות, פוסטים, טקסטים, קבצי מדיה, מועדי פרסום והגדרות קמפיין. - אנשי קשר לאישור שהסוכנות מזינה (שם, מייל, טלפון), ההחלטות וההערות שלהם. - לידים שנאספים דרך שַׁגֵּר, לפי מה שהסוכנות הגדירה. ### חשבונות רשת מחוברים - מזהה החשבון או העמוד, שם, שם משתמש ותמונה. - ההרשאות שאישרתם ומפתחות הגישה שהרשת הנפיקה. **מפתחות הגישה מוצפנים במסד הנתונים.** - תוצאות פרסום: מזהי פוסטים, קישורים, סטטוס ונתונים שהרשת מחזירה. ### קליקים על קישורים מקוצרים כשמישהו לוחץ על קישור מקוצר של שַׁגֵּר, נשמרים הזמן, המדינה, סוג מכשיר כללי, האתר שממנו הגיע, וקוד מבקר חד כיווני שמתחלף כל יום (כדי לספור מבקרים ייחודיים). **כתובות IP לא נשמרות.** אי אפשר לשחזר מהקוד היומי כתובת IP, ואי אפשר לקשר בעזרתו את אותו מבקר בין ימים שונים. ### טופס יצירת קשר שם, מייל, חברה, ההודעה ומועד השליחה. המידע משמש רק כדי לענות לכם, ונמחק אחרי 12 חודשים. ### רישומים טכניים כשאתם מתחברים לאפליקציה, נשמרות בחיבור כתובת IP וסוג הדפדפן, כדי להגן על החשבון. הן נמחקות כשהחיבור מסתיים או פג. השרתים שומרים גם רישומים טכניים קצרי טווח, כמו רישומי שגיאות, רק כל עוד צריך אותם לאבטחה ולטיפול בתקלות. (זה נפרד מהקליקים על קישורים מקוצרים, שבהם כתובת IP לא נשמרת.) ## השפה והמדינה שלכם כשנכנסים לאתר shager.ai אנחנו בודקים לאיזו מדינה שייכת כתובת הרשת (IP) שלכם, כדי להציג את האתר בשפה שלכם (עברית בישראל, אנגלית בשאר העולם). הבדיקה נעשית בשרת שלנו מול עותק מקומי של מאגר מדינות. הכתובת לא נשמרת ולא נשלחת לאף אחד. איתור המדינה מתבסס על המאגר של [DB-IP](https://db-ip.com), ברישיון CC BY 4.0. ## למה המידע משמש רק כדי לתת את השירות: לפרסם את התוכן שתזמנתם בחשבונות שחיברתם, להציג תוצאות ולידים, לנהל אישורי לקוח, לשמור על אבטחת השירות ולענות לפניות. איננו מוכרים מידע. איננו משתמשים בו לפרסום. איננו משתמשים בו לאימון מודלים של בינה מלאכותית, לא שלנו ולא של אף אחד אחר. | מטרה | בסיס חוקי (GDPR) | |---|---| | מתן השירות שנרשמתם אליו | ביצוע חוזה (סעיף 6(1)(ב)) | | עיבוד המידע של הסוכנות | לפי הוראות הסוכנות, במסגרת [הסכם עיבוד הנתונים](/dpa) | | אבטחה, מניעת שימוש לרעה, רישומי מערכת | אינטרס לגיטימי (סעיף 6(1)(ו)) | | מענה לפניות מטופס יצירת הקשר | אינטרס לגיטימי, או צעדים לקראת התקשרות | | שמירת רשומות שהחוק מחייב | חובה חוקית (סעיף 6(1)(ג)) | ## יוטיוב וגוגל שַׁגֵּר משתמשת בשירותי YouTube API Services כדי להעלות סרטונים ולהגיב בערוצים שחיברתם. חיבור ערוץ יוטיוב מהווה הסכמה ל[תנאי השימוש של יוטיוב](https://www.youtube.com/t/terms). המידע מטופל גם לפי [מדיניות הפרטיות של גוגל](https://policies.google.com/privacy). אפשר לבטל את הגישה של שַׁגֵּר בכל רגע ב[הגדרות האבטחה של חשבון הגוגל](https://myaccount.google.com/permissions), או בהסרת הערוץ בְּשַׁגֵּר (שמבטלת את הגישה מיד). השימוש של שַׁגֵּר במידע שמתקבל דרך Google APIs, וההעברה שלו, עומדים במדיניות [Google API Services User Data Policy](https://developers.google.com/terms/api-services-user-data-policy), כולל דרישות Limited Use. בפרט: - אנחנו משתמשים במידע מגוגל רק כדי לתת את היכולות שאתם רואים בְּשַׁגֵּר. - איננו מעבירים אותו לאחרים, אלא אם זה נדרש כדי לתת את היכולות האלה, לצורכי אבטחה, או כשהחוק מחייב. - איננו משתמשים בו לפרסום ואיננו מוכרים אותו. - אף אחד בְּשַׁגֵּר לא קורא אותו, אלא אם ביקשתם (למשל בפניית תמיכה), אם זה נדרש לאבטחה, או אם החוק מחייב. - איננו משתמשים בו לאימון מודלים של בינה מלאכותית. ## פייסבוק ואינסטגרם שַׁגֵּר מפרסמת בעמודי פייסבוק ובחשבונות אינסטגרם מקצועיים שחיברתם, דרך הממשקים הרשמיים (API) של Meta. עמודי פייסבוק מתחברים בהתחברות עם פייסבוק. חשבונות אינסטגרם מתחברים ישירות בהתחברות עם אינסטגרם, שמעבירה לנו את מזהה החשבון, שם המשתמש, השם, תמונת הפרופיל וסוג החשבון, ומפתח גישה לפרסום בשמו. **כדי למחוק את המידע**, הסירו את האפליקציה בהגדרות פייסבוק (**הגדרות ופרטיות ← הגדרות ← אינטגרציות עסקיות**) או באינסטגרם (**הגדרות ← הרשאות אתרים ← אפליקציות ואתרים**). אנחנו מוחקים את מפתחות הגישה מיד ומציגים קישור שבו אפשר לבדוק את סטטוס בקשת המחיקה. אפשר גם לכתוב לכתובת yaniv.presler@gmail.com. ## טיקטוק ולינקדאין (בקרוב) טיקטוק ולינקדאין עוד לא זמינים בְּשַׁגֵּר. כשיהיו, יחולו אותם עקרונות: גישה רק לחשבונות שחיברתם, בקשת ההרשאות שנחוצות לפרסום ולדיווח בלבד, שמירת המפתחות מוצפנים, עמידה בתנאי המפתחים ובכללי שמירת המידע של כל רשת, ואפשרות לנתק בכל רגע. נעדכן את המדיניות לפני שהם יעלו לאוויר. ## עוזר הכתיבה בְּשַׁגֵּר יש עוזר כתיבה (לא חובה להשתמש בו) שמבוסס על Anthropic. כשאתם בוחרים להשתמש בו, הטקסט ששלחתם (למשל טיוטה של פוסט או הנחיות) נשלח לחברת Anthropic כדי לקבל הצעה. שום דבר אחר לא נשלח: לא אנשי קשר, לא מפתחות גישה ולא לידים. לפי התנאים המסחריים של Anthropic, היא לא משתמשת בטקסט הזה לאימון המודלים שלה. ## עם מי המידע משותף - **הרשתות החברתיות:** התוכן שבחרתם לפרסם, בחשבונות שבחרתם. הרשתות הן יעדים שאתם בוחרים, לא ספקים שעובדים בשבילנו, וחלה עליהן מדיניות משלהן. - **ספקי שירות (מעבדי משנה):** אחסון השרתים (Hetzner Online GmbH — Helsinki, Finland (EU)) ושאר הספקים שמופיעים ב[רשימת מעבדי המשנה](/subprocessors). - **Anthropic:** רק טקסט ששלחתם לעוזר הכתיבה, כשבחרתם להשתמש בו. - **רשויות:** רק אם החוק מחייב. - **רוכש של העסק:** אם העסק יימכר או ימוזג, המידע יעבור באותן התחייבויות, ונודיע לכם מראש. ## איפה המידע נשמר השרתים שלנו נמצאים באיחוד האירופי: Hetzner Online GmbH — Helsinki, Finland (EU). טקסט שנשלח לעוזר הכתיבה מעובד אצל Anthropic בארצות הברית, עם אמצעי ההגנה שמתוארים ב[הסכם עיבוד הנתונים](/dpa). ישראל והאיחוד האירופי מכירים זה בזה כמי שמגנים על מידע אישי ברמה נאותה. ## כמה זמן המידע נשמר - **כל עוד החשבון פעיל.** לבקשת מחיקה (yaniv.presler@gmail.com) המידע נמחק תוך **7 ימים**, ומהגיבויים תוך **30 יום**. - **הסרת ערוץ:** מפתחות הגישה נמחקים מיד (ביוטיוב הם גם מבוטלים מול גוגל). - **מידע שנמשך מממשקי הרשתות (API)** מתעדכן או נמחק תוך **30 יום**. - **קליקים על קישורים מקוצרים** נשמרים כחלק מהדוחות של סביבת העבודה, ונמחקים יחד איתה. - **פניות מטופס יצירת הקשר** נמחקות אחרי **12 חודשים**. ## אבטחה התקשורת מוצפנת (HTTPS), מפתחות הגישה מוצפנים במנוחה, והגישה לשרתים מוגבלת למפעיל. עוד פרטים ב[עמוד האבטחה](/security). ## הזכויות שלכם לפי חוק הגנת הפרטיות, כולל תיקון 13 (בתוקף מאוגוסט 2025), אפשר לבקש לעיין במידע שאנחנו שומרים עליכם, לתקן אותו או למחוק אותו. אם תקנות GDPR חלות עליכם, אפשר גם לבקש להגביל את העיבוד או להתנגד לו, לקבל את המידע בפורמט שאפשר להעביר, ולבטל הסכמה כשהעיבוד מבוסס עליה. כדי להגיש בקשה, כתבו לכתובת yaniv.presler@gmail.com. נענה תוך 30 יום. אם המידע נמצא בסביבת עבודה של סוכנות, נעביר אליה את הבקשה (היא זו שמחליטה) ונעזור לה לענות. אפשר גם להתלונן לרשות להגנת הפרטיות, או לרשות להגנת המידע במדינה שלכם באיחוד האירופי. **נציג באיחוד האירופי:** עוד לא מינינו נציג באיחוד לפי סעיף 27 בתקנות GDPR. עד שנמנה, פנו אלינו ישירות בכתובת yaniv.presler@gmail.com. ## עוגיות אנחנו משתמשים רק בעוגיות הכרחיות משלנו, להתחברות ולחיבור חשבונות. אין עוגיות סטטיסטיקה, פרסום או צד שלישי. פירוט ב[מדיניות העוגיות](/cookies). ## ילדים שַׁגֵּר היא שירות לעסקים. היא לא מיועדת לילדים, ואיננו אוספים ביודעין מידע על ילדים מתחת לגיל 16. ## שינויים אם נשנה את המדיניות, נעדכן את התאריך למעלה. אם השינוי מהותי, נודיע לבעלי החשבונות במייל או באפליקציה לפני שייכנס לתוקף. ## יצירת קשר יניב פרסלר (Yaniv Presler) הכרמים 20/2, ישראל (HaKramim St. 20/2, Israel) yaniv.presler@gmail.com --- Source: https://shager.ai/privacy # תנאי שימוש שַׁגֵּר מופעלת על ידי יניב פרסלר (Yaniv Presler). השימוש בְּשַׁגֵּר מהווה הסכמה לתנאים האלה, ל[מדיניות הפרטיות](/privacy) ול[מדיניות השימוש ההוגן](/acceptable-use). אם אתם משתמשים בְּשַׁגֵּר בשם חברה, אתם מאשרים שאתם מוסמכים לחייב אותה, ו"אתם" פירושו החברה. שַׁגֵּר היא שירות לעסקים: לסוכנויות, למשווקים ולחברות. היא לא מיועדת לצרכנים פרטיים. ## השירות שַׁגֵּר מאפשרת לתזמן, לאשר מול לקוחות ולהפיץ תוכן לחשבונות ברשתות החברתיות שאתם מנהלים, ולמדוד קליקים ולידים. הפרסום נעשה רק דרך הממשק הרשמי (API) של כל רשת. הרשתות שפעילות היום: עמודי פייסבוק, חשבונות אינסטגרם מקצועיים ויוטיוב. טיקטוק ולינקדאין יגיעו בקרוב, ועדיין לא זמינים. ## החשבון שלכם - מסרו פרטים נכונים ועדכנו אותם. - שמרו על פרטי ההתחברות שלכם ושל הצוות. אתם אחראים למה שקורה בחשבון, כולל מה שאנשי הצוות עושים. - אם נראה לכם שמישהו נכנס לחשבון בלי רשות, כתבו לכתובת yaniv.presler@gmail.com. ## האחריות שלכם - מחברים רק חשבונות שיש לכם הרשאה לנהל, ומפרסמים רק תוכן שיש לכם זכות לפרסם. - עומדים בתנאי הרשתות, כולל [תנאי השימוש של יוטיוב](https://www.youtube.com/t/terms), תנאי Meta והנחיות הקהילה של כל רשת. בחיבור ערוץ יוטיוב אתם מסכימים להיות כפופים ל[תנאי השימוש של יוטיוב](https://www.youtube.com/t/terms), והטיפול של גוגל במידע מתואר ב[מדיניות הפרטיות של Google](https://policies.google.com/privacy). - לא משתמשים בְּשַׁגֵּר לספאם, להטעיה, להתחזות, לתוכן לא חוקי, או כדי לעקוף מגבלות או מנגנוני זיהוי של הרשתות. הרשימה המלאה ב[מדיניות השימוש ההוגן](/acceptable-use). - אם אתם מזינים מידע אישי של אנשים אחרים (למשל אנשי קשר לאישור או לידים), ודאו שמותר לכם, ושמסרתם להם את מה שהחוק מחייב. ## התוכן שלכם התוכן נשאר שלכם. אתם מרשים לְשַׁגֵּר לאחסן, לעבד (למשל להמיר פורמט של תמונה) ולפרסם אותו בחשבונות שבחרתם, רק כדי לתת את השירות. אתם אחראים לתוכן ולתוצאות הפרסום שלו. איננו בודקים תוכן לפני שהוא מתפרסם. ## לקוחות ומידע אישי כשאתם מכניסים לְשַׁגֵּר מידע של הלקוחות שלכם או של הקהל שלהם, אתם בעלי המאגר ואנחנו מחזיקים במידע עבורכם. [הסכם עיבוד הנתונים](/dpa) הוא חלק מהתנאים האלה וחל אוטומטית. ## עוזר הכתיבה עוזר הכתיבה מציע טקסטים. ההצעות עלולות להיות שגויות או לא מתאימות, אז בדקו אותן לפני פרסום. האחריות על מה שמתפרסם היא שלכם. ## תשלום אם אתם במסלול בתשלום, החיוב הוא לפי ההזמנה או לפי עמוד המחירים בזמן ההרשמה. נודיע לפחות 30 יום מראש על שינוי מחיר שנוגע לכם. אין החזר על תשלומים, אלא אם החוק מחייב או שהסכמנו על כך בכתב. ## זמינות ושינויים השירות ניתן כמו שהוא (AS IS). הרשתות משנות את הממשקים שלהן ויכולות לדחות או להגביל פרסומים; איננו אחראים להחלטות שלהן. ייתכנו הפסקות לתחזוקה. איננו מבטיחים חשיפה, מעורבות או מספר לידים. אנחנו יכולים לשנות ולשפר יכולות. אם נסיר יכולת מרכזית במסלול בתשלום, נודיע מראש. ## השעיה וסיום אנחנו רשאים להשעות חשבון שמפר את התנאים או את מדיניות השימוש ההוגן, או שמסכן את השירות, את הרשתות או אנשים אחרים. כשאפשר, נודיע קודם וניתן הזדמנות לתקן. אפשר להפסיק להשתמש בְּשַׁגֵּר ולבקש למחוק את החשבון בכל זמן, בכתיבה לכתובת yaniv.presler@gmail.com. לפני המחיקה אפשר לייצא את המידע. אחרי המחיקה המידע נמחק כמו שמתואר ב[מדיניות הפרטיות](/privacy). ## התקנה עצמית אם אתם מריצים את שַׁגֵּר על השרתים שלכם, אתם המפעילים של ההתקנה. האחריות על האבטחה, הגיבויים, העדכונים, העמודים המשפטיים והעמידה בחוק היא שלכם, וכך גם על אפליקציות המפתחים של הרשתות שאתם מחברים אליה. ## הגבלת אחריות במידה המרבית שהחוק מתיר, איננו אחראים לנזק עקיף או תוצאתי (כמו אובדן רווחים, אובדן מידע, אובדן חשיפה או הפסקת פעילות), ואחריותנו הכוללת מוגבלת לסכום ששילמתם לנו במהלך 12 החודשים האחרונים. שום דבר בתנאים לא מגביל אחריות שהחוק לא מאפשר להגביל, כמו אחריות להונאה או לפעולה בזדון. ## שיפוי אם צד שלישי יתבע אותנו בגלל תוכן שפרסמתם דרך שַׁגֵּר או בגלל שהפרתם את התנאים, תכסו את ההוצאות הסבירות שלנו בגין התביעה. ## שינויים בתנאים אם נשנה את התנאים, נעדכן את התאריך למעלה. אם השינוי מהותי, נודיע לבעלי החשבונות לפחות 14 יום מראש. המשך שימוש אחרי שהשינוי נכנס לתוקף מהווה הסכמה לתנאים החדשים. ## דין וסמכות שיפוט על התנאים חל הדין הישראלי, וסמכות השיפוט הבלעדית נתונה לבתי המשפט בתל אביב יפו. ## יצירת קשר שאלות: yaniv.presler@gmail.com. --- Source: https://shager.ai/terms # מדיניות עוגיות ## בקצרה שַׁגֵּר משתמשת רק בעוגיות שהשירות לא יכול לעבוד בלעדיהן: כדי שתישארו מחוברים, וכדי לחבר חשבון רשת בצורה בטוחה. **אין** עוגיות סטטיסטיקה, **אין** עוגיות פרסום ו**אין** עוגיות של צד שלישי. בגלל זה אין באנר עוגיות: החוק לא מחייב לבקש הסכמה לעוגיות הכרחיות. העוגיות שבטבלה משמשות את האפליקציה. כדי לקרוא את האתר הציבורי (shager.ai) לא צריך אף אחת מהן. ## העוגיות שאנחנו משתמשים בהן | עוגייה | למה | מי יוצר אותה | כמה זמן | |---|---|---|---| | `better-auth.session_token` | שומרת אתכם מחוברים לאפליקציה | שַׁגֵּר (צד ראשון) | עד שתתנתקו או שהחיבור יפוג | | עוגיות `better-auth.*` נוספות | עוזרות בתהליך ההתחברות, למשל בהתחברות עם גוגל | שַׁגֵּר (צד ראשון) | מכמה דקות ועד אורך החיבור | | `shager_connect_` | מגינה על חיבור חשבון רשת (OAuth state), כדי שאף אחד אחר לא יוכל להשלים אותו בשמכם | שַׁגֵּר (צד ראשון) | נמחקת כשהחיבור מסתיים, ולכל היותר אחרי 24 שעות | בחיבור HTTPS חלק מהשמות עשויים להתחיל בקידומת `__Secure-`. כולן מסומנות `HttpOnly` כשאפשר, כך שסקריפטים בדף לא יכולים לקרוא אותן. ## במה אנחנו לא משתמשים - אין כלי סטטיסטיקה או מעקב (אין Google Analytics, אין פיקסלים). - אין עוגיות פרסום או רימרקטינג. - אין עוגיות של רשתות חברתיות בעמודים שלנו. קישורים מקוצרים של שַׁגֵּר לא יוצרים עוגיות. איך סופרים קליקים עליהם מוסבר ב[מדיניות הפרטיות](/privacy). ## ניהול עוגיות אפשר לחסום או למחוק עוגיות בהגדרות הדפדפן. אם תחסמו את העוגיות שלמעלה, לא תוכלו להתחבר לאפליקציה או לחבר חשבונות. האתר הציבורי ימשיך לעבוד. ## שינויים אם נוסיף אי פעם עוגייה שאינה הכרחית, נעדכן את העמוד הזה ונבקש את הסכמתכם לפני שנשתמש בה. שאלות: yaniv.presler@gmail.com. --- Source: https://shager.ai/cookies # הצהרת נגישות אנחנו רוצים שכל אחד, כולל אנשים עם מוגבלות, יוכל להשתמש באתר ובאפליקציה של שַׁגֵּר. ההצהרה מתפרסמת לפי חוק שוויון זכויות לאנשים עם מוגבלות ותקנות הנגישות לשירות. ## רמת הנגישות שאנחנו מכוונים אליה היעד שלנו הוא עמידה בהנחיות **WCAG 2.2 ברמה AA** וב**תקן הישראלי ת"י 5568**, שמבוסס על הנחיות WCAG. ## איך אנחנו בונים את האתר אנחנו מתכננים ובונים לפי העקרונות האלה: - האתר כתוב בעברית, מימין לשמאל, ויש לו גרסה מלאה באנגלית. כל עמוד מצהיר על השפה ועל כיוון הכתיבה שלו. - העמודים בנויים עם כותרות, אזורים ורשימות אמיתיים, כדי שקוראי מסך יוכלו לנווט בהם. - אפשר להפעיל הכול במקלדת, ותמיד רואים איפה נמצא הפוקוס. - הטקסטים והכפתורים עומדים בדרישות הניגודיות, גם במצב בהיר וגם במצב כהה. - אפשר להגדיל טקסט עד 200% בלי לאבד תוכן, והעיצוב מתאים גם למסכים צרים. - האנימציות מכבדות את הגדרת "הפחתת תנועה" של המערכת. - לטפסים יש תוויות גלויות והודעות שגיאה ברורות. - איננו משתמשים בתוסף נגישות חיצוני. אנחנו מתקנים את האתר עצמו. ## מגבלות ידועות כדי להיות כנים, אלה הדברים שעדיין לא גמורים: - **תמונות בבלוג:** אנחנו עדיין מוסיפים טקסט חלופי מלא לחלק מהתמונות בפוסטים ישנים. - **תוכן של צד שלישי:** תצוגות מקדימות של פוסטים מהרשתות ומדיה שמשתמשים העלו עלולות לא להיות נגישות לגמרי. התוכן הזה לא בשליטתנו. - **האפליקציה:** חלקים באפליקציה חדשים יותר מהאתר הציבורי, ועדיין נבדקים מול אותו תקן. אם מצאתם משהו נוסף, נשמח לשמוע. ## בדיקה האתר נבדק לאחרונה מבחינת נגישות בתאריך 2026-10-13. אנחנו בודקים שוב בכל פעם שאנחנו עושים שינוי משמעותי. ## דיווח על בעיה אם נתקלתם בבעיית נגישות, או שאתם צריכים מידע בפורמט אחר, פנו לרכז הנגישות: יניב פרסלר (Yaniv Presler) yaniv.presler@gmail.com הכרמים 20/2, ישראל (HaKramim St. 20/2, Israel) כתבו מה הבעיה, באיזה עמוד היא קרתה, ואם אפשר גם באיזה דפדפן ובאיזו טכנולוגיה מסייעת השתמשתם. נענה תוך **14 יום**. --- Source: https://shager.ai/accessibility # פרטי המפעיל ## המפעיל שַׁגֵּר (shager.ai) מופעלת על ידי: יניב פרסלר (Yaniv Presler) הכרמים 20/2, ישראל (HaKramim St. 20/2, Israel) מספר עוסק: 031204175 מייל: yaniv.presler@gmail.com ## אחריות על התוכן יניב פרסלר (Yaniv Presler) אחראי על התוכן באתר. יצירת קשר: yaniv.presler@gmail.com. ## אחסון Hetzner Online GmbH — Helsinki, Finland (EU) ## מחלוקות שַׁגֵּר מוצעת רק לעסקים, לא לצרכנים. לכן פלטפורמת יישוב הסכסוכים המקוונת של האיחוד האירופי (ODR), שמיועדת לסכסוכי צרכנות, לא חלה עליה, ואיננו משתתפים בהליכי יישוב סכסוכים מול גוף בוררות לצרכנים. אם יש לכם תלונה, כתבו לכתובת yaniv.presler@gmail.com וננסה לפתור אותה ישירות. ## קישורים לאתרים אחרים האתר מקשר לאתרים אחרים, למשל לתנאי השימוש של הרשתות. איננו אחראים לתוכן שלהם. ## מידע משפטי נוסף - [מדיניות פרטיות](/privacy) - [תנאי שימוש](/terms) - [מדיניות עוגיות](/cookies) - [הצהרת נגישות](/accessibility) - [הסכם עיבוד נתונים](/dpa) - [מעבדי משנה](/subprocessors) - [מדיניות שימוש הוגן](/acceptable-use) - [אבטחה](/security) --- Source: https://shager.ai/imprint # הסכם עיבוד נתונים הסכם עיבוד הנתונים הזה ("**ההסכם**") הוא חלק מ[תנאי השימוש](/terms) בין יניב פרסלר (Yaniv Presler) ("**שַׁגֵּר**", "**אנחנו**") לבין הלקוח שמשתמש בְּשַׁגֵּר ("**הלקוח**", "**אתם**"). הוא חל אוטומטית בכל פעם שֶׁשַּׁגֵּר מעבדת מידע אישי בשמכם. אם אתם צריכים עותק חתום, כתבו לכתובת yaniv.presler@gmail.com. ## 1. הגדרות למונחים כמו "מידע אישי", "עיבוד", "בעל שליטה" (Controller), "מעבד" (Processor), "נושא מידע" ו"אירוע אבטחה" יש המשמעות שבתקנות הגנת המידע של האיחוד האירופי 2016/679 ("**GDPR**"). כשחל חוק הגנת הפרטיות, התשמ"א 1981, והתקנות לפיו, כולל תקנות הגנת הפרטיות (אבטחת מידע), התשע"ז 2017 ותיקון 13 ("**חוק הגנת הפרטיות**"), חלים גם המונחים המקבילים שבו ("בעל מאגר" מקביל לבעל שליטה, "מחזיק" מקביל למעבד). "**דיני הגנת המידע**" הם כל החוקים האלה, ככל שהם חלים. "**מידע הלקוח**" הוא מידע אישי שֶׁשַּׁגֵּר מעבדת בשמכם כשהיא נותנת את השירות. ## 2. תפקידים - לגבי מידע הלקוח, **אתם בעלי השליטה (בעלי המאגר)** ו**שַׁגֵּר היא המעבד (המחזיק)**. - לגבי המידע של בעלי החשבונות שלכם, שֶׁשַּׁגֵּר צריכה כדי לנהל את החשבון (התחברות, חיוב, תמיכה), שַׁגֵּר היא בעלת שליטה עצמאית לפי [מדיניות הפרטיות](/privacy). ההסכם הזה לא חל על המידע הזה. - אם אתם עצמכם מעבדים עבור הלקוחות שלכם, שַׁגֵּר היא מעבד המשנה שלכם, ואתם מאשרים שהלקוחות שלכם הסמיכו אתכם למנות אותנו. ## 3. פרטי העיבוד | נושא | פירוט | |---|---| | מהות | מתן השירות של שַׁגֵּר: תזמון, אישור, פרסום ומדידה של תוכן ברשתות החברתיות | | משך | כל עוד תנאי השימוש בתוקף, ועוד תקופות המחיקה שבסעיף 11 | | אופי | אחסון, ארגון, שליחה לרשתות שבחרתם, משיכת תוצאות, מחיקה | | מטרה | רק כדי לתת לכם את השירות, כמו שמתואר בתנאים ולפי ההגדרות שלכם | | נושאי המידע | העובדים ואנשי הצוות שלכם; הלקוחות שלכם ואנשי הקשר שלהם; מי שמאשר תוכן; מי שלוחץ על הקישורים המקוצרים שלכם; לידים שאתם אוספים; אנשים שמופיעים בתוכן | | סוגי המידע | שמות, מיילים, טלפונים, תפקידים; מזהים, שמות, תמונות ומפתחות גישה של חשבונות רשת; תוכן שאתם מעלים (טקסט, תמונות, וידאו), שעשוי לכלול דמות של אנשים; החלטות והערות אישור; נתוני קליקים על קישורים מקוצרים (זמן, מדינה, סוג מכשיר כללי, אתר מפנה, קוד מבקר חד כיווני שמתחלף כל יום, **בלי כתובת IP**); פרטי לידים שבחרתם לאסוף | | מידע רגיש | לא מיועד. אל תעלו מידע בעל רגישות מיוחדת, אלא אם יש לכם בסיס חוקי לכך ועדכנתם אותנו | ## 4. ההוראות שלכם אנחנו מעבדים את מידע הלקוח רק לפי ההוראות המתועדות שלכם. התנאים, ההסכם הזה ואופן ההגדרה והשימוש שלכם בשירות הם ההוראות. אם נראה לנו שהוראה מפרה את דיני הגנת המידע, נודיע לכם. אם החוק מחייב אותנו לעבד מידע בצורה אחרת, נודיע לכם מראש, אלא אם החוק אוסר זאת. האחריות לבסיס החוקי לעיבוד, ולמסירת המידע שהחוק מחייב לנושאי המידע, היא שלכם. ## 5. סודיות כל מי בְּשַׁגֵּר שיכול לגשת למידע הלקוח מחויב בסודיות, וניגש אליו רק כשצריך כדי לתת את השירות, כדי לתת תמיכה שביקשתם, או לצורכי אבטחה. ## 6. אבטחה אנחנו מיישמים את האמצעים הטכניים והארגוניים שב**נספח 1**, שמתאימים לרמת הסיכון. אנחנו יכולים לשפר אותם עם הזמן, אבל לא נוריד את רמת ההגנה הכוללת. ## 7. מעבדי משנה אתם נותנים לנו הרשאה כללית להשתמש במעבדי משנה. הרשימה העדכנית נמצאת ב[עמוד מעבדי המשנה](/subprocessors). - כל מעבד משנה מחויב אצלנו בחוזה כתוב, עם התחייבויות להגנת מידע שאינן פחותות מההסכם הזה. - נודיע לכם לפחות **30 יום** לפני שמעבד משנה חדש יתחיל לעבד את מידע הלקוח, במייל או באפליקציה, ונעדכן את עמוד מעבדי המשנה. - אפשר להתנגד מטעמים סבירים של הגנת מידע בתוך התקופה הזו. אז ננסה בתום לב למצוא פתרון. אם לא נמצא, תוכלו לסיים את השירות שנפגע ולקבל החזר יחסי על תשלום מראש עבורו. - אנחנו נשארים אחראים כלפיכם לעבודה של מעבדי המשנה שלנו. הרשתות החברתיות שאתם מפרסמים בהן (כמו Meta וגוגל) אינן מעבדי משנה שלנו. אתם בוחרים לשלוח אליהן תוכן, וחלים עליהן התנאים שלהן. ## 8. העברה למדינות אחרות - מידע הלקוח מאוחסן באיחוד האירופי (Hetzner Online GmbH, שרתים בהלסינקי, פינלנד). - טקסט שמשתמש בוחר לשלוח לעוזר הכתיבה מעובד אצל Anthropic PBC בארצות הברית. כשהטקסט כולל מידע אישי מהאיחוד האירופי, ההעברה נשענת על מסגרת פרטיות המידע בין האיחוד לארצות הברית (EU-U.S. Data Privacy Framework) כשהמקבל מוסמך לפיה, ואחרת על הסעיפים החוזיים התקניים (SCCs) של הנציבות האירופית, שכלולים בתנאי עיבוד הנתונים של הספק. - העברה מישראל נשענת על תקנות הגנת הפרטיות (העברת מידע למאגרי מידע שמחוץ לגבולות המדינה), התשס"א 2001, כולל העברה למדינות האיחוד האירופי. - לא נעביר את מידע הלקוח למדינה אחרת בלי מנגנון העברה חוקי. ## 9. עזרה לכם בהתחשב באופי העיבוד, נעזור לכם: - לענות לבקשות של נושאי מידע (עיון, תיקון, מחיקה, הגבלה, ניוד, התנגדות). אם בקשה כזו תגיע ישירות אלינו, נעביר אותה אליכם בלי עיכוב מיותר, ולא נענה עליה בעצמנו אלא אם תבקשו; - לעמוד בחובות שלכם בנושאי אבטחה, דיווח על אירועים, הערכת השפעה על פרטיות והתייעצות מוקדמת עם רשויות. הרבה מזה אפשר לעשות לבד באפליקציה, למשל לערוך או למחוק אנשי קשר, פוסטים וחשבונות. ## 10. אירוע אבטחה אם נדע על אירוע אבטחה שפוגע במידע הלקוח, נודיע לכם **בלי עיכוב מיותר, ובכל מקרה תוך 72 שעות**. ההודעה תתאר, לפי מה שידוע באותו רגע, מה קרה, איזה מידע ואילו נושאי מידע נפגעו, מה ההשלכות הצפויות, ומה עשינו או מה אנחנו מציעים לעשות. נשלח עוד מידע כשיהיה, וננקוט צעדים סבירים כדי לבלום את האירוע. ## 11. מחיקה והחזרה - כל עוד השירות פעיל, אפשר לייצא ולמחוק מידע באפליקציה. - כשהשירות מסתיים, או לבקשתכם, נמחק את מידע הלקוח תוך **7 ימים**, ומהגיבויים תוך **30 יום**, אלא אם החוק מחייב לשמור אותו. - לפני המחיקה אפשר לבקש מאיתנו עותק של המידע בפורמט נפוץ שמחשב יכול לקרוא. - מפתחות גישה נמחקים מיד כשאתם מסירים חשבון מחובר (ביוטיוב הם גם מבוטלים מול גוגל). ## 12. ביקורת נעמיד לרשותכם את המידע שצריך כדי להראות שאנחנו עומדים בהסכם, כולל תשובות בכתב לשאלוני אבטחה סבירים, פעם בשנה או אחרי אירוע אבטחה. אם זה לא מספיק, או שרשות דורשת זאת, תוכלו לערוך אצלנו ביקורת: על חשבונכם, בהודעה של 30 יום מראש לפחות, בשעות העבודה, בלי לשבש את השירות, ודרך מבקר שמחויב בסודיות. כרגע אין לנו הסמכות של צד שלישי כמו SOC 2 או ISO 27001. ## 13. אחריות האחריות של כל צד לפי ההסכם כפופה להגבלות האחריות שב[תנאי השימוש](/terms), ככל שהחוק מתיר. ## 14. סדר עדיפות ודין אם יש סתירה בין ההסכם הזה לתנאי השימוש, ההסכם גובר בענייני הגנת מידע. אם הסעיפים החוזיים התקניים חלים וסותרים את ההסכם, הסעיפים גוברים. על ההסכם חלים הדין וסמכות השיפוט שבתנאי השימוש, אלא אם דיני הגנת המידע מחייבים אחרת. ## נספח 1: אמצעי אבטחה ### הצפנה - כל החיבורים משתמשים בפרוטוקול TLS (HTTPS), כולל בין האפליקציה לממשקי הרשתות. - מפתחות הגישה לרשתות מוצפנים במנוחה בתקן AES-256-GCM. - סיסמאות נשמרות רק כגיבוב (hash) עם salt. ### בקרת גישה - הגישה לשרתים ולמסדי הנתונים בסביבת הייצור מוגבלת למפעיל. הכניסה לשרתים היא רק עם מפתחות SSH; כניסה עם סיסמה חסומה. - באפליקציה, המידע של כל סביבת עבודה מופרד מהאחרות, ותפקידים בצוות קובעים מי יכול לעשות מה. - החיבורים לאפליקציה משתמשים בעוגיות מאובטחות מסוג HttpOnly. - קישורי אישור ללקוח כוללים קוד אקראי שנשמר רק כגיבוב, פגים אחרי זמן, אפשר לבטל אותם, והם פותחים פוסט אחד בלבד. ### צמצום מידע - אנחנו מבקשים רק את הרשאות OAuth שכל יכולת צריכה (הרשאה מינימלית). - קליקים על קישורים מקוצרים נרשמים בלי כתובות IP, עם קוד מבקר חד כיווני שמתחלף כל יום. - רק טקסט שהמשתמש בחר לשלוח מגיע לעוזר הכתיבה. ### זמינות ושחזור - השרתים מאוחסנים באיחוד האירופי, בחוות שרתים מקצועית. קבצי המדיה נשמרים בשרתים שלנו, לא אצל ספק אחסון חיצוני. - גיבוי יומי של השרתים. מידע שנמחק נעלם מהגיבויים תוך 30 יום. ### תפעול - עדכוני אבטחה של מערכת ההפעלה מותקנים אוטומטית. - חומת אש מאפשרת רק תעבורת אינטרנט (HTTP/HTTPS) וגישת SSH. - אפשר לדווח על חולשות לכתובת yaniv.presler@gmail.com (ראו [עמוד האבטחה](/security)). ## נספח 2: מעבדי משנה ראו את [עמוד מעבדי המשנה](/subprocessors), שהוא חלק מההסכם. --- Source: https://shager.ai/dpa # מעבדי משנה אלה ספקים חיצוניים שעשויים לעבד מידע אישי כשאנחנו נותנים את השירות. כולם מחויבים בהסכם כתוב שמגן על המידע לפחות כמו [הסכם עיבוד הנתונים](/dpa) שלנו. ## מעבדי המשנה כיום | ספק | מה הוא עושה | איזה מידע | מיקום | |---|---|---|---| | Hetzner Online GmbH | אחסון שרתים, נתונים וגיבויים | כל המידע של השירות, שנשמר בשרתים שלנו | גרמניה (החברה); השרתים בהלסינקי, פינלנד (האיחוד האירופי) | | Anthropic PBC | עוזר הכתיבה | רק טקסט שמשתמש בחר לשלוח לעוזר | ארצות הברית | | Internet Security Research Group (Let's Encrypt) | תעודות TLS לחיבור מוצפן | אין מידע אישי, רק שמות הדומיין שלנו | ארצות הברית | | GoDaddy | DNS לדומיין שלנו | אין מידע אישי, רק רשומות DNS | ארצות הברית | ## מתוכננים | ספק | מה יעשה | סטטוס | |---|---|---| | ספק מיילים מערכתיים | שליחת מיילים של התחברות, אישורים והתראות | עוד לא בשימוש. יופיע כאן לפני שנתחיל להשתמש בו. | | ספק הודעות SMS / וואטסאפ | שליחת קישורי אישור בהודעת SMS או בוואטסאפ, אם הסוכנות בוחרת בזה | עוד לא בשימוש. יופיע כאן לפני שנתחיל להשתמש בו. | ## לא מעבדי משנה: הרשתות החברתיות Meta Platforms (פייסבוק, אינסטגרם) וגוגל (יוטיוב), ובהמשך טיקטוק ולינקדאין, מקבלות את התוכן שבחרתם לפרסם, בחשבונות שבחרתם. הן יעדים שאתם בוחרים, לא ספקים שעובדים בשבילנו, וחלים עליהן התנאים ומדיניות הפרטיות שלהן. ## שינויים נעדכן את העמוד הזה ונודיע ללקוחות שקיבלו את הסכם עיבוד הנתונים לפחות **30 יום** לפני שמעבד משנה חדש יתחיל לעבד מידע אישי. אם יש לכם התנגדות סבירה מטעמי הגנת מידע, כתבו לכתובת yaniv.presler@gmail.com בתוך התקופה הזו. התהליך מתואר ב[הסכם עיבוד הנתונים](/dpa). התקנה עצמית מופעלת על ידי הלקוח, שבוחר ספקים משלו. הרשימה הזו לא חלה עליה. --- Source: https://shager.ai/subprocessors # מדיניות שימוש הוגן שַׁגֵּר עוזרת לסוכנויות לפרסם בהרבה חשבונות. זה עובד רק אם כל פוסט לגיטימי, ורק אם הרשתות ממשיכות לסמוך על הכלים שמפרסמים אצלן. המדיניות הזו היא חלק מ[תנאי השימוש](/terms). ## אסור להשתמש בְּשַׁגֵּר בשביל ### ספאם ושכפול המוני - לפרסם את אותו תוכן, או כמעט אותו תוכן, בהרבה חשבונות כדי להציף פידים, לתמרן את האלגוריתם או להיראות גדולים ממה שאתם. - פוסטים, תגובות או קישורים חוזרים, לא רצויים או מטעים. - לפרסם בקצב או בכמות שנועדו לעקוף את המגבלות של רשת. ### מעורבות מזויפת - לקנות, למכור או להחליף לייקים, עוקבים, צפיות, תגובות או שיתופים. - להפעיל רשתות של חשבונות מזויפים, אוטומטיים או לא אותנטיים, או לתאם בין חשבונות כדי לזייף פופולריות. - להשתמש בתגובות (כולל התגובה הראשונה) כדי לתמרן מעורבות ולא כדי לתת מידע. ### התחזות והטעיה - להתחזות לאדם, למותג או לארגון אחר, או לחבר חשבונות שאין לכם הרשאה לנהל. - להסתיר שתוכן הוא ממומן או שיווקי כשהחוק או הרשת מחייבים לציין זאת. - קישורים מטעים: קישור מקוצר צריך להוביל למקום שאנשים מצפים לו. ### תוכן לא חוקי או פוגעני - תוכן שמפר את החוק, זכויות יוצרים, סימני מסחר או פרטיות, או שאין לכם זכות לפרסם. - הסתה ושנאה, הטרדה, איומים, תוכן מיני שמערב קטינים, קיצוניות אלימה או הונאה. - שליחת הודעות או איסוף לידים בניגוד לחוקי הספאם והפרטיות, כולל חוק התקשורת ("חוק הספאם") ותקנות GDPR. ### שימוש לרעה בשירות או ברשתות - ניסיון לעקוף מגבלות, בדיקות או מנגנוני זיהוי של רשת. - סריקה אוטומטית (scraping), הנדסה לאחור או העמסה של שַׁגֵּר או של ממשקי הרשתות. - גישה למידע של לקוחות אחרים, או בדיקת האבטחה שלנו בלי לעבור דרך [תהליך הדיווח האחראי](/security). ## מה אנחנו מצפים במקום - **תוכן מקורי לכל חשבון.** כל חשבון צריך לקבל תוכן שמתאים לקהל שלו. הכלים של שַׁגֵּר (טקסט לכל רשת, תגובה ראשונה ומעקב לכל חשבון, שליחה מדורגת) נועדו לעזור בזה. השתמשו בהם. - **הרשאה אמיתית.** כל חשבון מחובר שייך לכם או ללקוח שהסמיך אתכם לנהל אותו. - **גילוי נאות.** סמנו תוכן שיווקי, ממומן או שנוצר בבינה מלאכותית כשהחוק או הרשת מחייבים. ## לכבד את הכללים של כל רשת כשאתם מפרסמים דרך שַׁגֵּר, אתם מתחייבים גם לכללים של כל רשת שאתם מפרסמים בה, כולל: - Meta: [תנאי השימוש של Meta](https://www.facebook.com/terms.php), [תנאי השימוש של אינסטגרם](https://help.instagram.com/581066165581870), [Meta Platform Terms](https://developers.facebook.com/terms/) וכללי הקהילה. - יוטיוב: [תנאי השימוש של יוטיוב](https://www.youtube.com/t/terms) והנחיות הקהילה. - טיקטוק (בקרוב): [תנאי השימוש של טיקטוק](https://www.tiktok.com/legal/terms-of-service), הנחיות הקהילה, מדיניות התוכן הממומן (Branded Content Policy) ואישור השימוש במוזיקה (Music Usage Confirmation). - לינקדאין (בקרוב): [הסכם המשתמש של לינקדאין](https://www.linkedin.com/legal/user-agreement) ומדיניות הקהילה המקצועית. אם הכללים של רשת מחמירים יותר מהמדיניות הזו, הכללים של הרשת גוברים. ## מה אנחנו רשאים לעשות אם נראה לנו שהמדיניות הופרה, אנחנו רשאים להוציא תוכן מהתור, לעצור פרסום, לנתק חשבונות, להשעות או לסגור את החשבון, וכשהחוק מחייב, לדווח לרשויות. כשאפשר, נודיע קודם וניתן הזדמנות לתקן. במקרים דחופים (למשל סיכון לרשתות, ללקוחות אחרים או לאנשים) אנחנו עשויים לפעול קודם ולהודיע אחר כך. ## דיווח על שימוש לרעה אם ראיתם תוכן שפורסם דרך שַׁגֵּר ומפר את המדיניות, כתבו לכתובת yaniv.presler@gmail.com עם קישור והסבר קצר. --- Source: https://shager.ai/acceptable-use # אבטחה סוכנויות מחברות לְשַׁגֵּר את חשבונות הרשת של הלקוחות שלהן. אנחנו מתייחסים לגישה הזו כדבר הרגיש ביותר שיש אצלנו. העמוד מתאר מה אנחנו עושים היום. הוא לא הסמכה. ## הצפנה - **בתעבורה:** כל חיבור, לאתר, לאפליקציה ולממשקי הרשתות, מוצפן בפרוטוקול TLS (HTTPS). התעודות מונפקות על ידי Let's Encrypt. - **במנוחה:** מפתחות הגישה לרשתות מוצפנים במסד הנתונים בתקן **AES-256-GCM**. סיסמאות נשמרות רק כגיבוב (hash) עם salt, אף פעם לא כטקסט גלוי. ## גישה לחשבונות הרשת - **הרשאה מינימלית:** אנחנו מבקשים רק את הרשאות OAuth שכל יכולת צריכה, ומסבירים אותן כשמחברים חשבון. - **השליטה אצלכם:** אפשר לנתק חשבון בְּשַׁגֵּר בכל רגע, ואז המפתחות שלו נמחקים מיד (ביוטיוב הם גם מבוטלים מול גוגל). אפשר גם לבטל את הגישה מתוך ההגדרות של הרשת עצמה. - **רק API רשמי:** שַׁגֵּר אף פעם לא מבקשת את הסיסמה שלכם לרשת, ולא משתמשת באוטומציה של דפדפן. ## אחסון - השרתים מאוחסנים אצל Hetzner Online GmbH — Helsinki, Finland (EU), באיחוד האירופי. - קבצי המדיה נשמרים בשרתים שלנו, לא אצל ספק אחסון חיצוני. - גיבוי של השרתים נעשה כל יום. מידע שנמחק נעלם מהגיבויים תוך 30 יום. - הגישה לשרתי הייצור מוגבלת למפעיל. הכניסה היא רק עם מפתחות SSH; כניסה עם סיסמה חסומה. - חומת אש מאפשרת רק תעבורת אינטרנט וגישת SSH, ועדכוני אבטחה של מערכת ההפעלה מותקנים אוטומטית. ## באפליקציה - המידע של כל סביבת עבודה מופרד מסביבות עבודה אחרות. - תפקידים בצוות (בעלים, מנהל, חבר צוות, ובכל סביבת עבודה מנהל, עורך או צופה) קובעים מי רואה כל לקוח ומי יכול לחבר חשבונות ולפרסם. - החיבורים לאפליקציה משתמשים בעוגיות מאובטחות מסוג HttpOnly. - קישורי אישור ללקוח כוללים קוד אקראי שאנחנו שומרים רק כגיבוב. כל קישור פג אחרי זמן, אפשר לבטל אותו, הוא פותח פוסט אחד בלבד, ואי אפשר להתחבר איתו למערכת. ## פרטיות כברירת מחדל - קליקים על קישורים מקוצרים נספרים בלי לשמור כתובות IP, עם קוד מבקר חד כיווני שמתחלף כל יום. - אין באתר כלי סטטיסטיקה, פרסום או מעקב של צד שלישי. - עוזר הכתיבה מקבל רק את הטקסט שבחרתם לשלוח אליו. ## מה איננו טוענים כרגע אין לנו SOC 2, ISO 27001 או הסמכת אבטחה אחרת. אם תהליך הרכש שלכם דורש מענה על שאלון אבטחה, כתבו לכתובת yaniv.presler@gmail.com. ## דיווח על חולשה אם נראה לכם שמצאתם בעיית אבטחה בְּשַׁגֵּר, כתבו לכתובת yaniv.presler@gmail.com עם הפרטים ואיך לשחזר אותה. אנחנו מבקשים: - לתת לנו זמן סביר לתקן לפני פרסום פומבי; - לא לגשת למידע שאינו שלכם, לא לשנות ולא למחוק אותו, ולעצור ברגע שנתקלתם בו; - לא להריץ בדיקות של מניעת שירות, ספאם או הנדסה חברתית נגדנו או נגד הלקוחות שלנו. נאשר שקיבלנו את הדיווח, נעדכן אתכם, ולא ננקוט צעדים משפטיים נגד מחקר בתום לב שעומד בכללים האלה. ## אם משהו משתבש אם אירוע אבטחה יפגע במידע שלכם, נודיע ללקוחות שנפגעו בלי עיכוב מיותר, ותוך 72 שעות כשהחוק או [הסכם עיבוד הנתונים](/dpa) מחייבים. --- Source: https://shager.ai/security