AI agents

Everything you change in the editor becomes a record on the relay, never a change to your site. Getting those records built is your coding agent's job: Claude Code, Cursor, or whatever else works on the codebase. The agent connects to the project once, keeps its own key, and from then on the whole handoff is a sentence you say to it: check Pixy.

Nothing needs to be installed on the agent's side. Any tool that can send an HTTP request can pull your edits, build them, and report back, the API is small and every page of it is served as plain .txt for the agent to read itself.

Connecting an agent

Open your project's page on /my, open Setup, and press Copy setup. That puts a short note on the clipboard: a one-time invitation, the project's tag, and a link to the connect instructions that tell the agent everything else. Paste it into your agent, and the page waits with you: the moment the agent signs up, its row appears under Agents with the name it chose.

The instructions make the agent do these things, in this order:

1. Show you the plan and wait for your yes.
2. Ask you three questions. May it call Pixy's API at api.pixydesignapp.com. Which build carries the tag, development only, staging, or production too. And how to work: auto builds your edits the moment you say Check Pixy, manual shows you what a batch changes and waits for your yes.
3. Install the tag where you said.
4. Sign up with the invitation at /connect and introduce itself, that name is what you see from then on. It stores its own project key (px_sk_…) where you tell it. The invitation dies at that moment, the key is permanent.
5. Install the agent workflow as a skill and write its settings, the key's location, the tag's build and the mode, into the project's own agent notes. Every future session runs from that copy, fetching nothing. When the contract changes, Pixy's API tells the agent in its next response, and it re-learns and updates the copy itself.
6. Tell you the four commands it now understands.

That is the whole setup. The invitation is valid ten minutes and works once, so no standing secret ever passes through the chat.

The commands

• Check Pixy. The daily loop below.
• Pixy settings. The agent asks the two setup questions again and rewrites its notes. Moving the tag to another build, or switching auto and manual, is this.
• Disconnect Pixy. The agent retires its key, removes the skill and its settings. The tag stays, the rest of the team keeps designing. Reconnecting takes a fresh invitation.
• Uninstall Pixy. Everything Disconnect does, and the tag comes out of the site. The agent says what will go and waits for your yes.

The daily loop

Design as you like, then say "Check Pixy" to your agent. It pulls with its stored key, builds what it finds, and acks every record when it is done. You never copy anything again, and you never have to group anything either: the agent files what it built into tasks itself, named the way commits are named, one per piece of work, and leaves a summary on each.

You watch it happen. With edit mode on, the moment the agent pulls your edits the workspace dims and says who is building them. When it acks, the same screen shows the tasks it filed the work into and its message, with Done to take it down. The records it built leave the page as it acks them, since the site is about to have them.

• In manual mode the agent lists what a batch changes and which files it would touch, and waits for your yes. In auto mode it builds straight away.
• A question in a task's thread comes before edits: the agent answers it and asks whether to go ahead.
• What the agent could not build it dismisses with a reason, and what it never acked stays open and comes back on its next pull.

Tasks

Tasks are optional and mostly the agent's. A task is a batch with a title and a thread, and its number, Task #N, in your project's task list on /my. The agent makes them at ack, from the loose edits it built. You can package edits into a task yourself when you want a curated batch with a conversation around it; then pulling locks it to that agent, another agent walks past it, and the agent's thread messages land there.

If an agent has to abandon a task, it says why and releases the lock.

Who is connected

The project page lists every connected agent, the name it introduced itself with and when it last pulled. Revoke removes an agent: its next call is refused, everything it built stays. Copy setup again mints a fresh invitation for the next one; a team's every member can have their own agent on the project.

An agent mid-build on a task has no Revoke, the task it holds is locked to its key, and pulling the key out from under it would strand the lock. Let it finish.

What a record says

Every record is what the edits made of one target: its type, an element or one of the site's rules, its target, an element's xpath, a born element's own id, or a rule's selector, a snapshot of the target as the site had it, and changes, what is set, what is unset, what the site gave each of those keys (original), and where the element was moved, or that it was removed, with the screen size it was designed at. The full contract is on the pull page.

That is what makes a color change on a rule land in one place instead of as an inline patch on the one instance you happened to click. A choice made in Pixy that is not a style, a group's layout, an alignment, an image's crop, travels as a data-pixy- attribute, an intent the agent builds the project's own way and never ships.

Pulling is not resolving

A record stays open until the agent acks it. Pulling it does not close it: an unacked batch simply arrives again on the next pull, so nothing is lost when an agent dies mid-task or a terminal gets closed.

There are two outcomes an agent can report, resolved or dismissed with a reason, the same two words the Edits panel uses. Acking every record of a task is what closes it.