Dooap Shepherd

Dooap Shepherd is the AI assistant built into Studio. It knows how Actions, Steps, Triggers, Inputs, Tools, and Runs work, and it can see the tenant you are working in. Ask it a question in plain language and it answers with guidance that matches your workspace — or goes further and designs, creates, and runs Actions for you.

You do not need to be a developer to use Shepherd. It is made for business users who want to automate invoice processing and related Action Flows.

Where to Find Shepherd

There are two ways to open Shepherd:

• The Shepherd button in the top bar. Available on every Studio page, it opens Shepherd as a side panel next to your current work. Shepherd sees what you are looking at — an Action, a Step, or a Run — and tailors its help to it.
• The full-page Shepherd view. Open the side panel and select the full-screen icon for an immersive chat, useful for longer design sessions.

When opened next to an Action, Shepherd shows starter prompts that fit the current context, so you can begin with one click.

Shepherd is available when the tenant has the Shepherd feature enabled. Your conversations are saved per tenant — use the history icon to return to an earlier session, or the new-session icon to start fresh.

What Shepherd Can Do

Answer questions about Studio and Dooap

Shepherd can explain how Studio works and search the user documentation for you:

• how Actions, Steps, and Triggers fit together,
• which step type fits a task (Agent, OCR, Switch, Loop Over, Tool Call, Metadata, Trigger Action, Code),
• which inputs and tools are available in your tenant,
• how invoice automation concepts like OCR, classification, and approval routing map to Actions.

Design and create Actions

Describe the outcome you want and Shepherd designs the Action for you. It checks the step types, models, inputs, and tools that actually exist in your tenant, validates the design, and presents an Action Preview with the proposed steps and flow diagram.

Nothing is created until you approve. The preview lists the assumptions Shepherd made and warns about anything that needs attention — for example a missing input type or an unavailable trigger. Select Click to enlarge to inspect the proposed flow in detail.

When you select Approve and Create Action, Shepherd creates the Action in Studio and gives you a direct link to open it.

Build an Action automatically (auto-build mode)

When you want Shepherd to take a requirement all the way to a working Action without designing and testing it by hand each time, use auto-build mode. There are two ways to start it:

• From the Shepherd header — select the auto-build icon, then describe what the Action Flow should do, give a sample input to test with, and set how many iterations to allow.
• Straight from the chat — just ask Shepherd to build (or fix) an Action and keep testing it until it works. It agrees a representative sample input with you in the conversation, then shows a Start auto-build card you confirm with one click.

Once started, Shepherd runs a loop on its own:

1. Design — it makes the needed changes to the Action Flow,
2. Test — it runs a dry-run with your sample input (a dry-run validates the flow without performing real external actions),
3. Check — it reviews the run result against your goal, and if it is not right yet, it returns to step 1 and refines the design.

Because each cycle changes and tests your Action, Shepherd asks for your approval between cycles. You can:

• Approve once — let Shepherd run the next single cycle, then ask again, or
• Approve for this action this session — let Shepherd keep refining this Action on its own for the rest of the session without asking again.

You can Stop at any time. The loop ends when the dry-run satisfies your goal, when it reaches the maximum number of iterations you set, or when you stop it. Auto-build works the same whether you are creating a new Action or improving an existing one — open the Action first to refine it, or start with none to create one from scratch.

Improve existing Actions and prompts

Open an Action and ask Shepherd to review it. It can:

• suggest a better step flow and present the change as a preview,
• improve an Agent Step prompt,
• help define structured output fields for extraction or classification,
• help think through branching logic with Switch steps.

Design and test Apps, inputs, and tools

Shepherd can build the connectors an Action needs, not just the Action itself. When you want to integrate with an external HTTP or REST service, describe the API and Shepherd designs an App for it — including the input types that fetch data and the tools that call out to the service. It can create a brand-new App or add to and modify an existing one, and you can point it at an OpenAPI specification to turn the endpoints into ready-to-use inputs and tools. As with Actions, the proposed App, its inputs, and its tools are shown as a preview that you approve before anything is created.

Shepherd can also test an input type or a tool by itself, the same way you would with the Test button while building one — it runs the input's or tool's real configured call and reads the live response. This lets Shepherd verify that a connector actually works and fix problems (a wrong URL, missing parameters, or an authentication issue) before presenting it as ready, instead of leaving you to test each one by hand.

Because a test makes a real call to the external service, Shepherd asks for your permission first. When it wants to test a tool or input, it shows a request card where you can:

• Run once — let Shepherd run this single test, or
• Allow testing this tool this session — let Shepherd test that tool or input on its own for the rest of the session without asking again.

After the test runs, the live result (or the error) is shown in the chat and handed back to Shepherd, so it can confirm the connector works or adjust it and try again.

Run Actions

Shepherd can prepare an execution preview with suggested input values, show you exactly what would run, and execute the Action after you approve.

Troubleshoot failed Runs

Open a failed Run and ask Shepherd what went wrong. It inspects the run details and explains the likely root cause — a missing input, a prompt that did not receive the expected data, a tool failure — and suggests how to fix it.

How Shepherd Works

Shepherd does not guess about your tenant. While answering, it calls Studio itself — listing step types, fetching tool schemas, validating designs — and shows its progress in a Tool Activity panel above the answer, so you can see what it checked.

Two safeguards keep you in control:

• Previews and permission before changes. Anything that would create or modify something in Studio — a new Action, a design change, an App and its inputs and tools, or an execution — is always presented as a preview that you explicitly approve or ignore. Testing a tool or input type makes a real call to an external service, so it also runs only with your permission, once or for the session.
• Previews expire. A preview restored from chat history is read-only. Ask Shepherd for a fresh preview before applying it, so you never apply a stale change.

How Shepherd Remembers

When your tenant has Shepherd's memory feature enabled, Shepherd learns from your conversations and carries that knowledge into future sessions — so you do not have to re-explain your conventions, your preferences, or an Action's history every time you return.

Shepherd keeps memory in three layers:

• Tenant memory — knowledge shared by everyone in the tenant: naming conventions, recurring patterns, domain facts, and how your organization builds and operates Actions.
• Personal memory — your individual preferences, such as the language and tone you prefer and the goals you keep returning to. One user's preferences are never mixed into another's.
• Action memory — distilled learnings about a specific Action: the intent behind it, designs that did not work and why, and recurring run errors and their fixes.

This memory is provided to Shepherd at the start of every conversation, so it begins each chat already aware of what it has learned. Memory is stored transparently as Data Files in a .shepherd/ folder, so it can be inspected — and corrected — rather than being a hidden black box.

When memory is captured

Shepherd does not write to memory in the middle of a conversation. A short while after a chat session goes quiet — by default about fifteen minutes of inactivity — a background process treats the session as finished and distills any durable, reusable learnings into the relevant memory layers. Each session is processed only once.

Routine back-and-forth that holds nothing worth keeping leaves memory untouched; only lasting facts are stored, and corrected mistakes are recorded as forward-looking guidance ("X does not work because Y, do Z instead") rather than as a log of what happened.

The nightly Dream cycle

Once a day, Shepherd runs a consolidation pass called the Dream cycle. Where the per-session capture adds new learnings, the Dream cycle steps back and tidies the whole picture:

• It merges and deduplicates scattered notes, compresses each memory file toward a size budget, and drops anything that has become stale or was shown to be wrong.
• For Action memory, it folds in recent failed runs and version history, so Shepherd's understanding of an Action reflects how it has actually been behaving.
• It cleans up after itself, removing memory for users who have left the tenant and for Actions that have been deleted.

The result is a compact, current memory that keeps improving with use while staying small enough to inform every conversation.

Prompts to Try

General help:

What can you help me with in Studio?

What is the difference between an Agent Step and a Tool Call Step?

Designing a new Action:

Design a new action that reads an incoming invoice PDF, extracts the vendor
name, invoice number, and total amount, and classifies it as PO or non-PO.
Show me a preview first.

Suggest the best new action flow for routing invoices over 10,000 EUR to
manual approval. Validate it before presenting the preview.

Building an integration (App, inputs, and tools):

Create an OpenAPI app and a tool that gets currency rates from
https://cdn.jsdelivr.net/npm/@fawazahmed0/currency-api@latest/v1/currencies/eur.json,
then test the tool to confirm it works.

Building automatically (auto-build mode):

Build an action that reads an incoming invoice webhook, stores the invoice
to the Invoices data table, and keep testing it until the dry run works.

Improving an existing Action (open the Action first):

Design this action using the available step types, tenant tools, and tenant
inputs. Show me a preview first.

How could I improve this step prompt?

Troubleshooting (open the Run first):

Help me troubleshoot this error.

Explain the likely root cause of this failure.

Best Practices

• Describe the business outcome, not the steps. "Classify incoming invoices as PO or non-PO and store the result" gives Shepherd more to work with than a list of step types.
• Ask for a preview first. Reviewing the proposed flow and its warnings before approving catches missing inputs and wrong triggers early.
• Read the assumptions and warnings. They tell you what Shepherd could not verify in your tenant and what to confirm before relying on the Action.
• Use it next to your work. Opening Shepherd as a side panel on an Action or a Run gives it context automatically, so you can ask short follow-up questions.
• Stay on topic. Shepherd focuses on Dooap products and politely declines unrelated questions.

---