What you need before you start
- A Pinksheep account
- Access to the apps the workflow will need
- A short description of the job you want the agent to do
No code is required for the core builder flow. The main job is being specific enough that the generated plan is easy to review.
Step 1: Describe the workflow
Open the builder and describe the workflow in plain English. Start with one bounded job rather than a whole department process.
A strong first prompt says what the agent should read, what decision it should make, and whether it should ask before writing. Keep the first version narrow so the plan is easy to inspect.
Step 2: Review the plan
The builder turns your prompt into an execution plan. Review the planned steps, the permissions involved, the trigger or schedule, and the estimated credits per run.
If the plan looks too broad, tighten the prompt and regenerate. It is faster to fix the plan before launch than to clean up a workflow that started with the wrong scope.
Step 3: Connect missing apps
If the workflow has auth gaps, connect the required apps before deployment. The builder and integrations screen are the current source of truth for what still needs to be connected.
After the connect flow finishes, verify the app is ready before you continue. Do not deploy a workflow that still depends on missing connections.
Step 4: Validate and keep approvals on
Run validation before the first live deployment. This is the quickest way to catch obvious policy, schema, or connection issues before the workflow goes live.
For any workflow that writes to another system, keep approvals on. The safe operating model is that the agent shows what it wants to do before it does it.
- Does the plan still match the workflow you intended?
- Are the right apps connected?
- Do the permissions look sensible for the job?
- Should any write step wait for approval?
Step 5: Launch and learn
Deploy the workflow once the plan, connections, and validation look right. Then watch the first live runs instead of immediately widening scope.
After launch, tighten the workflow using the real signals you now have: run history, approvals, spend caps, reconnect notices, and the exact places where the plan still feels too broad.
Good first agents
| Agent | Stack | Launch shape | What it does |
|---|---|---|---|
| Lead review agent | CRM | Bounded launch | Reviews new leads, proposes routing or qualification updates, and waits for approval before writing. |
| Ticket triage agent | Help desk | Bounded launch | Reads new support tickets, proposes categories or assignments, and keeps a human in the loop for live changes. |
| Follow-up drafting agent | Finance or ops system | Bounded launch | Drafts follow-up actions from business data and routes the final decision through approval. |
| Status summary agent | Collaboration tools | Bounded launch | Reads team updates and produces summaries without needing a risky live write on day one. |
Frequently asked questions
Do I need to know how to code to build AI agents with Pinksheep?
No. The safe public claim is that you describe the workflow in plain English, review the generated plan, connect the apps it needs, and launch without writing code.
How long does it take to build a first agent?
Use the approved claim boundary here: from idea to running agent in minutes. The exact speed depends on how clear the workflow is and whether the required apps are already connected.
What tools can I connect to my agents?
The approved public proof is that Pinksheep connects to 500+ business apps your team already uses. The builder will also show you when a workflow has auth gaps and needs an app connected before launch.
What are approval gates and do I need them?
Approval gates are the review step before a write continues. For a first live launch, keep approvals on for sensitive or external write actions so the agent shows what it wants to do before it does it.
What should I do after the first launch?
Review the first live runs, check pending approvals, tighten the prompt if the plan is too broad, and set a spend cap or notifications if the workflow needs stronger operating boundaries.