Documentation

Quickstart

This section walks through a minimal setup: turning information into a monthly email report for a client. Before DelegateZero, I had a Pipedream workflow that looked something like this (simplified a bit):

1. Pull website analytics data for client
2. Analyze and create email text
3. Save in my email draft folder
4. Notify me in Slack that the email draft is ready

Then I would be responsible for reviewing the email draft, updating it based on what I knew to be true about the client and the client's accounts, and then send manually. I did it this way because, like everyone, I didn't trust AI to put together and send an email without my intervention.

Now, with DZ, the workflow looks similar but I'm confident that the email being created is accurate and comparative to something I would actually send. So I let it go ahead and send the email.

1. Pull analytics data for client
2. Analyze analytics data
3. Create email text (DelegateZero's step)
4. Send email to client

Let's zoom in on each step.

Step 1: Identify a decision that needs to be made

Start with a real decision you already make frequently that you'd like to have DZ handle for you going forward. For example:

• Approving small expenses
• Responding to routine internal requests
• Deciding whether something needs escalation

For my sample workflow, that was verifying the accuracy and legitimacy of the client email. When you're first getting started, I would recommend avoiding high-risk or irreversible decisions until you get more comfortable.

Step 2: Create or add DelegateZero to an existing workflow

After identifying where a decision needs to be made, create a step and send a request to DZ. For my workflow, I needed DZ at the create email step. Here is what that request looked like:

          curl -X POST https://delegatezero.com/api/v1/decisions \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "request": "Create a monthly website analytics report for a client.",
    "context": {
      "entity": "ABC Company",
      "data": "[This would be a paste of the analysis data.]"
    },
    "instructions": {
      "confidence_threshold": 0.8,
      "format": "html"
    }
  }'

          import axios from "axios";

const decision = await axios.post(
  "https://delegatezero.com/api/v1/decisions",
  {
    request: "Create a monthly website analytics report for a client.",
    context: {
      entity: "ABC Company",
      data: "[This would be a paste of the analysis data.]",
    },
    instructions: {
      confidence_threshold: 0.8
      format: 'html'
    }
  },
  {
    headers: {
      Authorization: `Bearer ${process.env.API_KEY}`
    }
  }
);

console.log(decision.data);

          import requests
import os

response = requests.post(
  "https://delegatezero.com/api/v1/decisions",
  headers={
    "Authorization": "Bearer {os.environ['API_KEY']}",
    "Content-Type": "application/json"
  },
  json={
    "request": "Create a monthly website analytics report for a client.",
    "context": {
      "entity": "ABC Company",
      "data": "[This would be a paste of the analysis data.]",
    },
    "instructions": {
      "confidence_threshold": 0.8
      "format": "html"
    }
  }
)

print(response.json())

Other than the API key and the delegatezero.com URL, the only required field is the request field.

Including more information may be helpful or even necessary for better responses. Adding context helps to improve accuracy. Instructions allow you to overwrite default behavior set in your account for specific requests.

Learn more about

Step 3: Receive the outcome

DelegateZero returns a structured outcome. In this example, the decision is safe to execute, so DZ proceeds and includes a short explanation and an audit link.

{
  "id": "9f31c2",
  "decision": "execute",
  "confidence": 0.86,
  "reason": "Email content aligns with the provided analytics data and prior client report templates",
  "response": "<p>Hi there,</p><p>Here’s your monthly website analytics report for January.</p><p>Overall traffic increased by 12% month-over-month, driven primarily by organic search. Conversion rate remained steady at 2.4%, with top-performing pages being /pricing and /blog.</p><p>Notably, paid spend decreased by 8% while total leads increased by 5%.</p><p>Let me know if you’d like a deeper breakdown or have any questions.</p><p>Best,<br />Your Team</p>",
  "audit_url": "https://delegatezero.com/app/audit/9f31c2"
}

As you can see, the HTML string for the email was generated and the reasoning that DZ used to create the response was documented. With the audit URL provided (or accessed via your user dashboard), you can deep-dive into the decision to learn about how it was made and what you could add to improve the response.

Step 4: Review the audit log

In your DZ account, you can review past decisions and responses, including:

• What context was used (information, templates, entity data)
• Which rules applied ("if this client, do that")
• Why the outcome occurred (i.e. not enough data)
• The confidence level at the time of the decision

Performing regular audits of the decisions made in your DZ account and then making context improvements as outlined below will ensure accurate delegation and improved, efficient automated workflows.

Step 5: Improve with context

After reviewing past decisions, you can improve future outcomes by adding quality context. Some optimizations you can make include:

• Adding rules: alter responses based on platforms, data, people, etc.
• Add an example of a similar decision
• Add guidance for edge cases

Next steps

Great - so if you've followed along and added DelegateZero to one of your workflows, you're already on your way to a higher level of automation and a more efficient day-to-day. To get the most out of DZ, we recommend that you continue reading through the documentation below, particularly these sections:

1. Context: the different types of context and adding new context
2. Requests: how to submit decision requests
3. Settings: global settings, confidence thresholds, and safety

Adding context

You add context through the DelegateZero dashboard. The primary way to do this is by clicking on the + Add context button.

This interface is intentionally flexible - a blank canvas. You can paste text, describe a rule, upload a file, or add notes in plain language. DZ will analyze what you provide and catalog it appropriately.

You don't need to decide in advance whether something is a policy, precedent, or reference, although, the more specificity you can provide, the better. If you're unsure, just add it — DZ will classify and store it for you.

You can add context at any time and are encouraged to do so to improve the quality of your responses. New context is immediately available for future decisions.

Policies

Policies define explicit rules, limits, and boundaries that DelegateZero must respect. They are the strongest form of context. When a policy applies, it overrides most other signals.

Some examples of basic policies that you might add include:

• I generally don't approve new tools or subscriptions without first checking whether we already have something that does the same thing. If it's unclear, escalate.
• When replying to clients, keep the tone professional and concise. Avoid humor or casual language unless the client initiates it.
• Do not commit me to meetings outside of 9am–5pm unless it's already marked as urgent or pre-approved.
• Every time we communicate with ABC Company, address messaging to Melissa
• Sign off every email with "Thanks, -Tyler"

These policies are fine for basic ideas, but they should really be fleshed out a good deal more. Below are some better examples.

Client-specific communication policy:

For ABC Company:
-Always use a formal tone
-Do not mention internal tools or processes
-Avoid sharing raw metrics unless they have already been discussed
-If a request involves scope or pricing changes, acknowledge receipt and escalate instead of responding

This works better because: it is scoped to a specific entity, it covers tone, content, and escalation, and it prevents common mistakes.

Platform-specific response rules:

-In Slack, responses should be brief and task-oriented.
-In email, provide more context and complete explanations.
-Never send long explanations in Slack — if more detail is needed, suggest moving to email.

This is helpful because it differentiates communication by channel, improves response quality, and is easy to apply consistently.

Content approval and publishing policy:

Do not publish or send externally facing content unless:
-The information is already public or approved
-The tone matches previous communications
-No speculative claims are included
If content is informational but not time-sensitive, generate a draft and request review instead of sending.

This policy helps to protect against reputational risk, distinguishes draft vs execute, and applies across many content types.

Conservative default behavior:

When context is incomplete or conflicting, default to escalating instead of making assumptions.
If a decision would materially affect a client relationship, err on the side of asking.

This policy is pretty conservative, but it aligns with human risk tolerance, improves trust early on, and helps to reduce false positives.

Policies are best used for hard constraints and non-negotiable rules, but some other things you should keep in mind:

• Policies aren't just numeric thresholds
• They can be scoped by client, platform, or content
• They encode judgment, not just rules

Precedents

Precedents are examples of how you handled past situations. Unlike policies, they are not fixed, absolute rules. Instead, they help DelegateZero understand patterns in your decision-making.

A few examples of basic precedents include:

• I approved a late deliverable for a long-term client after they explained the delay and communicated early.
• I declined a last-minute request because it would have disrupted planned work for the week.
• I escalated a vendor contract question because I wasn't familiar with the terms and didn't want to guess.

Notice how those, in basic terms, address 3 things: the problem, the solution, and the condition or reasoning. They are a good place to start, but the following more comprehensive precedents are better.

Client-specific judgment:

For ABC Company, I approved a minor scope change without charging extra because the relationship is long-standing (longer than 3 years) and the request required minimal effort (less than 2 hours est.).
I would not have done this for a newer client.

This precedent is better because it ties behavior directly to relationship context, it explains (in detail) why the decision was made, and it just implies limits without turning into a rule.

Communication judgment under ambiguity:

When a customer complained about experiencing performance issues but the metrics didn't show an outage, I acknowledged their frustration, avoided blaming, and offered to investigate further instead of pushing back immediately.

There are times when you may want to respond more directly, but this precedent shows tone and intent for this specific situation and demonstrates restraint.

Platform-aware decision:

In Slack, I gave a short acknowledgment and said I'd follow up later. I sent the full explanation by email once I had more information.

This precedent could be fleshed out more, but it shows channel-specific behavior, demonstrates sequencing, and it's not easily captured by a policy.

Risk-aware exception:

I approved an exception even though it technically broke our guidelines because the downside was small and the upside was preserving trust with the client. I would not do this repeatedly.

Another good idea as to when a precedent makes sense, although I'd be sure to fully explain what was approved, how it technically broke guidelines, and specifically what the downside would be.

Entities

Entities represent people, companies, vendors, accounts, etc. that DelegateZero should recognize - specifically if the entity has its own set of facts, preferences, and special handling attached that might be utilized.

Some examples:

• ABC Company is a long-term client on an annual contract. They prefer clear, formal communication. They typically review reports monthly.
• Sam Reynolds is our engineering manager. He handles approvals related to infrastructure changes.
• Stripe is our payment processor. Any issues or changes involving billing should be escalated.

Here are some examples with better reasoning and more specificity:

Client with scoped behavior:

ABC Company
-Strategic client.
-Use a professional, direct tone
-Avoid mentioning internal tools or processes
-Do not speculate about future features or timelines
-Escalate requests involving scope or pricing changes

This is good because it specifies tone, content boundaries, and escalation rules, preventing common communication mistakes.

Internal decision-maker with context:

Jamie Lee is our Director of Operations.
-She approves vendor contracts and renewals
-She prefers concise summaries over long explanations
-Escalate anything time-sensitive or involving compliance to Jamie

This entity entry clarifies responsibility, includes preferences, not just role, and helps to route decisions correctly.

Vendor with risk considerations:

Acme Hosting
-Our infrastructure provider.
-Historically slow to respond to support requests
-Any outages or billing discrepancies should be escalated immediately to them
-Avoid committing to timelines with tasks including Acme without confirmation

This entry is aware of risk history, guides escalation behavior, and applies across many situations.

Playbooks

Playbooks describe how you typically think through a category of situations. They are written in plain language and can include reasoning steps, trade-offs, and tone guidance.

For example:

• When a request is vague or missing details, acknowledge it and ask a clarifying question instead of guessing.
• When declining a request, be respectful and brief. Explain the constraint and offer an alternative if possible.
• If multiple requests come in at once, prioritize anything blocking other people’s work.

Here are a few better examples offering enhanced reasoning:

Responding to unhappy customers:

When a customer is frustrated:
-Acknowledge the issue without being defensive
-Avoid assigning blame
-Explain next steps clearly
-If the issue isn’t fully understood yet, say so and commit to following up
The goal is to de-escalate first, then solve the problem.

Here we're trying to capture intent, not just actions, and help guide the tone and sequencing.

Evaluating exception requests:

When someone asks for an exception:
-Check whether this has been allowed before
-Consider the relationship and potential precedent
-If the downside is small and the upside is trust, lean toward flexibility
-If approving could create future expectations, escalate instead

This playbook helps to avoid potential slippery slopes and would be difficult to reduce to a single rule like a policy.

External communication clarity:

For external messages:
-Be clear about what is known vs unknown
-Avoid speculative language
-Do not overpromise timelines or outcomes
-If certainty is low, frame the response accordingly.

For any communication outside of the business, we want to prevent common communication failures and improve trust.

Handling sensitive internal issues:

For sensitive internal matters:
-Keep responses factual and neutral
-Avoid emotional language
-Do not make judgments about intent
-Escalate if there are legal or HR implications
When in doubt, keep communication minimal and ask for guidance.

We want to prioritize caution here and protect against missteps.

Templates

Templates are reusable response structures that DelegateZero can adapt. They help maintain consistent tone and formatting while allowing the content to vary based on context. Think of templates more like starting points for how to handle something, not hard and fast rules.

Templates might be used for instances such as:

• A standard approval response
• A polite decline message
• A recurring report email structure

Here are some examples:

Client-facing update email

When sending an analytics report via email to a client, use the template below.

Subject: {{client_name}} — {{reporting_period}} update

Hi {{client_contact}},

Here's a brief update on {{reporting_period}} performance. Overall trends are consistent with expectations, with {{key_metric}} being the primary driver.
Let me know if you'd like a deeper breakdown or have any questions.

Best,
-Tyler

Escalation response:

Whenever we need to escalate internal communication, respond with a message like this:

I'm looping this through for review before responding, as it involves {{reason_for_escalation}}.
I'll follow up once I have confirmation.

Polite refusal

When we need to refuse a request, respond with a concise but polite message such as:
I can't move forward with this as requested, but I'm happy to discuss alternatives.

A couple things to keep in mind regarding templates:

• Templates describe what the response should look like, not when it should be used (think playbooks).
• Templates may be used across various channels and adapted by DZ based on context and confidence. You can specify how you might want a certain message formatted for different channels.

Use templates to define how responses are structured. Use playbooks to define how decisions are made.

Sources

Sources are raw inputs such as emails, messages, documents, or notes, or live data via webpage or API. They are not treated as rules or decisions on their own - sources provide background, not direction. Instead, DelegateZero extracts relevant information and incorporates it into its understanding.

When adding a source, a short description or notes explaining what the source represents should be included. This helps DZ understand when and how to use the source.

You might add a source when:

• Pasting an email thread
• Uploading a document
• Providing background material

Here are some examples:

Email thread as behavioral evidence:

This email thread shows how the client responds over time to performance issues, what they focus on, and how much explanation they expect. Use this to calibrate tone and depth in future communications.

From: alex@abccompany.com
To: me@company.com
Subject: January performance concerns

Hey — we noticed traffic dipped in the second half of January and wanted to understand why.
Is this related to the changes we made earlier in the month?

Thanks,
Alex


From: me@company.com
To: alex@abccompany.com

Thanks for flagging. The dip aligns with when we paused paid campaigns mid-month.
Overall organic traffic remained stable, and we're seeing positive trends longer-term.


From: alex@abccompany.com
To: me@company.com

That makes sense. We're less concerned about week-to-week movement and more about whether the broader trend is healthy.
Appreciate the clarification.

Webpage as authoritative reference:

This webpage documents a public service outage. Use it as a factual reference when explaining incidents to customers.

https://status.vendorplatform.com/incidents/2026-01-12

Incident summary:
On January 12, VendorPlatform experienced elevated API error rates for approximately two hours.
The issue was resolved and no customer data was affected.

Internal analysis explaining trends:

This internal summary explains why paid traffic declined over time and how we've discussed it internally. Use it to inform explanations and avoid inconsistent narratives.

Paid traffic overview (Q1):

- Paid campaigns were gradually reduced starting mid-January due to declining ROI.
- Spend was intentionally reallocated toward content and SEO.
- Organic growth partially offset the decline, but total sessions were lower short-term.
- We expect stabilization by late Q2.

Internal consensus:
When explaining this externally, frame the change as a strategic shift rather than a performance issue.
Avoid over-emphasizing short-term dips.

Integration source:

This integration provides analytics data for ABC Company. Use only high-level metrics in client-facing communication.

Integration: Google Analytics
Property ID: UA-123456-7
Access: Read-only

Notes:
- Data stabilizes 48 hours after month end
- Do not reference raw events or experimental metrics externally

When adding a source, start by explaining what the source represents and how it should be used. Then add the content itself.

Best practices

DelegateZero works best when context is added intentionally. The goal is not to add everything, but to add the right information with clear explanations. Additionally:

• Add context incrementally — you don't need everything upfront
• Use policies for hard rules and precedents for patterns
• Write in plain language
• Correct decisions by adding context rather than editing past requests
• When unsure how to classify something, just add it

Choosing the right context type

If you're unsure where something belongs, use the questions below as a guide.

• Is this a hard rule or boundary? Use a policy.
• Is this how you handled a specific situation in the past? Use a precedent.
• Is this how you generally think through a type of situation? Use a playbook.
• Is this about a specific person, company, or system? Use an entity.
• Is this a reusable response shape? Use a template.
• Is this raw information or reference material? Use a source.

If something feels too detailed or nuanced to summarize cleanly, it likely belongs in sources. But keep in mind, your job isn't to catalog the right context in the right place - it's to provide clear and comprehensive context so that DZ can do that for you.

Start with sources, then distill

Many users begin by adding sources: emails, documents, data summaries, or internal notes.

Over time, patterns emerge. When you notice repeated behavior, you can distill that information into policies, precedents, or playbooks.

This approach preserves nuance early and adds structure later.

Write like you would explain to a trusted teammate

You don't need formal language or perfect structure. Write the way you would explain something to a capable colleague who understands the context but needs guidance. Plain language works best.

How context works together

DZ does not treat context types in isolation. Decisions are made by combining multiple signals. For example:

• A policy may define a hard limit
• A precedent may show how you handled similar cases
• An entity may modify tone or escalation behavior
• A playbook may guide reasoning under ambiguity
• A template may shape the response
• A source may provide factual grounding

Together, these form a more complete representation of your judgment.

DelegateZero improves as context accumulates. Start simple, add information as situations arise, and refine over time.

Request structure

A decision request is a JSON object sent to the DelegateZero API. The only required field is the request describing what needs to be decided. Additional context and instructions can be provided to improve accuracy or override defaults.

{
  "request": "ABC Company has asked us to give them a quote for a new project. Here are the details: [DETAILS]"
}

This is a valid request, but DZ may escalate if there is insufficient context to decide safely or based on what you've set in your policies.

Here is another request utilizing the context and instructions parameters:

{
  "request": "Create and send a monthly analytics update to the client",
  "context": {
    "source": "monthly_report_workflow",
    "entity": "ABC Company",
    "data": "January analytics summary"
  },
  "instructions": {
    "confidence_threshold": 0.8
  }
}

• request describes what DZ should decide or do.
• context provides request-specific information that complements stored context.
• instructions allow you to add or override default behavior for this request.

Response structure

Every decision request returns a structured response describing what DelegateZero decided and why. The response is designed to be both machine-readable and human-reviewable.

{
  "id": "dec_9f31c2",
  "decision": "execute",
  "confidence": 0.86,
  "reason": "Request aligns with prior reports and approved communication patterns",
  "response":  "<p>Hi there,</p><p>Here’s your monthly update...</p>",
  "audit_url": "https://app.delegatezero.com/audit/dec_9f31c2"
}

• decision indicates how DelegateZero handled the request (execute, draft, or escalate).
• confidence reflects how confident DelegateZero is that the decision matches your judgment.
• response contains the canonical output — what DelegateZero would have sent or done on your behalf.
• audit_url links to a detailed explanation of how the decision was made.

API documentation

The API is how you can interact with DelegateZero in your workflows. It allows you to submit decision requests, receive structured outcomes and even add context.

The API is synchronous by default and returns a decision, confidence score, and response payload. Webhooks can be used to receive asynchronous notifications.

All requests are made over HTTPS and use JSON request and response bodies.

Endpoints

All endpoints are called on the path https://delegatezero.com/api/v1. Here are the available endpoints:

Authentication

All API requests must be authenticated by passing your account's API key as a bearer token. Here's how you might use that in various API calls:

Authorization: Bearer YOUR_API_KEY

          curl -X POST https://delegatezero.com/api/v1/decisions \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "request": "Create a monthly website analytics report for a client.",
  }'

          import axios from "axios";

const decision = await axios.post(
  "https://delegatezero.com/api/v1/decisions",
  {
    request: "Create a monthly website analytics report for a client.",
  },
  {
    headers: {
      Authorization: `Bearer ${process.env.API_KEY}`
    }
  }
);

          import requests
import os

response = requests.post(
  "https://delegatezero.com/api/v1/decisions",
  headers={
    "Authorization": "Bearer {os.environ['API_KEY']}",
    "Content-Type": "application/json"
  },
  json={
    "request": "Create a monthly website analytics report for a client.",
  }
)

Keep your API key secret - requests made with your key are treated as actions taken on your behalf.

Request object

The only required field needed for an API request is the request field. In this field, you can actually make your full request, pass additional context, etc. and have it parsed by DZ's API.

However, additional properties can be added to the request for greater specificity, direction and clarity - context and instructions.

• request = the human-readable required intent
• context = evidence/facts for this specific request
• instructions = behavioral controls for the request

While request is a standard string field on the root level of the request, context and instructions are objects each containing their own list of optional properties. By default, DZ will use the information saved in your acccount's context to handle responses, however, that behavior can be overwritten based on what's passed in an individual request.

Context property

Here is a full list of the possible properties in the context object:

Instructions property

Here is a full list of the possible properties in the instructions object:

Examples

Below are some examples of API requests including a mix-and-match of various properties.

Structured output for downstream automation:

        curl -X POST https://delegatezero.com/api/v1/decisions \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "request": "Draft a client update about this month's analytics.",
    "context": {
      "entity": "ABC Company",
      "data": "Organic traffic up 12%, paid traffic down after campaign pause."
    },
    "instructions": {
      "format": "html",
      "response_fields": ["subject", "html", "text"]
    }
  }'

        import axios from "axios";

const decision = await axios.post(
  "https://delegatezero.com/api/v1/decisions",
  {
    request: "Draft a client update about this month's analytics.",
    context: {
      entity: "ABC Company",
      data: "Organic traffic up 12%, paid traffic down after campaign pause."
    },
    instructions: {
      format: "html",
      response_fields: ["subject", "html", "text"]
    }
  },
  {
    headers: {
      Authorization: `Bearer ${process.env.API_KEY}`
    }
  }
);

        import requests
import os

response = requests.post(
  "https://delegatezero.com/api/v1/decisions",
  headers={
    "Authorization": "Bearer {os.environ['API_KEY']}",
    "Content-Type": "application/json"
  },
  json={
    "request": "Draft a client update about this month's analytics.",
    "context": {
      "entity": "ABC Company",
      "data": "Organic traffic up 12%, paid traffic down after campaign pause."
    },
    "instructions": {
      "format": "html",
      "response_fields": ["subject", "html", "text"]
    }
  }
)

Responding to an internal message with confidence control:

        curl -X POST https://delegatezero.com/api/v1/decisions \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "request": "Respond to this internal Slack message.",
    "context": {
      "source": "slack",
      "data": "Can we commit to having this ready by Friday?"
    },
    "instructions": {
      "confidence_threshold": 0.85,
      "tone": "direct"
    }
  }'

        import axios from "axios";

const decision = await axios.post(
  "https://delegatezero.com/api/v1/decisions",
  {
    request: "Respond to this internal Slack message.",
    context: {
      source: "slack",
      data: "Can we commit to having this ready by Friday?"
    },
    instructions: {
      confidence_threshold: 0.85,
      tone: "direct"
    }
  },
  {
    headers: {
      Authorization: `Bearer ${process.env.API_KEY}`
    }
  }
);

        import requests
import os

response = requests.post(
  "https://delegatezero.com/api/v1/decisions",
  headers={
    "Authorization": "Bearer {os.environ['API_KEY']}",
    "Content-Type": "application/json"
  },
  json={
    "request": "Respond to this internal Slack message.",
    "context": {
      "source": "slack",
      "data": "Can we commit to having this ready by Friday?"
    },
    "instructions": {
      "confidence_threshold": 0.85,
      "tone": "direct"
    }
  }
)

Safe evaluation with dry run and strict mode:

        curl -X POST https://delegatezero.com/api/v1/decisions \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "request": "Approve this customer exception request.",
    "context": {
      "entity": "XYZ Startup",
      "data": "Asking for a one-time pricing exception."
    },
    "instructions": {
      "dry_run": true
    }
  }'

        import axios from "axios";

const decision = await axios.post(
  "https://delegatezero.com/api/v1/decisions",
  {
    request: "Approve this customer exception request.",
    context: {
      entity: "XYZ Startup",
      data: "Asking for a one-time pricing exception."
    },
    instructions: {
      dry_run: true
    }
  },
  {
    headers: {
      Authorization: `Bearer ${process.env.API_KEY}`
    }
  }
);

        import requests
import os

response = requests.post(
  "https://delegatezero.com/api/v1/decisions",
  headers={
    "Authorization": "Bearer {os.environ['API_KEY']}",
    "Content-Type": "application/json"
  },
  json={
    "request": "Approve this customer exception request.",
    "context": {
      "entity": "XYZ Startup",
      "data": "Asking for a one-time pricing exception."
    },
    "instructions": {
      "dry_run": true
    }
  }
)

Response object

Every decision request returns a structured response describing what DelegateZero decided, how confident it is, and what it produced as the canonical response.

The response object is designed to be both machine-readable (for automation) and human-reviewable (via the audit log).

Here is what a response looks like:

{
  "id": "9f31c2",
  "decision": "execute",
  "confidence": 0.86,
  "reason": "Email content aligns with the provided analytics data and prior client report templates",
  "response": "Here's your monthly website analytics report for January. Overall traffic increased by 12% month-over-month, driven primarily by organic search. Conversion rate remained steady at 2.4%, with top-performing pages being /pricing and /blog. Notably, paid spend decreased by 8% while total leads increased by 5%. Let me know if you'd like a deeper breakdown or have any questions. Best, Your Team",
  "audit_url": "https://delegatezero.com/app/audit/9f31c2"
}

If your request contained response_fields values (so that the response will be structured), they will be put in a property response_fields like this:

{
  "id": "9f31c2",
  "decision": "execute",
  "confidence": 0.86,
  "reason": "Email content aligns with the provided analytics data and prior client report templates",
  "response": "Here's your monthly website analytics report for January. Overall traffic increased by 12% month-over-month, driven primarily by organic search. Conversion rate remained steady at 2.4%, with top-performing pages being /pricing and /blog. Notably, paid spend decreased by 8% while total leads increased by 5%. Let me know if you'd like a deeper breakdown or have any questions. Best, Your Team",
  "response_fields": {
    "subject": "ABC Company - Monthly Analytics Update",
    "email": "jane@abccompany.com",
    "text": "Here's your monthly website analytics report for January. Overall traffic increased by 12% month-over-month, driven primarily by organic search. Conversion rate remained steady at 2.4%, with top-performing pages being /pricing and /blog. Notably, paid spend decreased by 8% while total leads increased by 5%. Let me know if you'd like a deeper breakdown or have any questions. Best, Your Team"
  }
  "audit_url": "https://delegatezero.com/app/audit/9f31c2"
}

Here is an explanation of each response property:

• id: A unique identifier for the decision. Use this to correlate requests, retrieve audit logs, or reference the decision in downstream systems.
• decision: Indicates how DelegateZero handled the request. Possible values are execute (action taken automatically), draft (output generated but not executed), or escalate (human review required).
• confidence: A number between 0 and 1 representing how confident DelegateZero is that the decision and response match your expected judgment.
• reason: A short, human-readable explanation describing why the decision was made. This is a summary, not a full reasoning trace.
• response: The canonical output produced by DelegateZero for this request. This represents what DelegateZero would send or do on your behalf.
• response_fields: An optional object containing a structured split of the response into named fields. Returned only when requested via instructions.response_fields.
• audit_url: A URL linking to the audit log for this decision, showing what context was used and how the outcome was determined.

Context API

The /context endpoint allows you to programmatically add context to DelegateZero.

This is the same type of information you would add through the dashboard. DZ will analyze, categorize, and store the content so it can be used in future decisions. Use this endpoint when you want to:

• Add information outside of a decision request
• Preload knowledge before automation runs
• Sync documents, notes, or data from other systems
• Gradually build DZ's understanding over time

This endpoint does not trigger a decision or return an outcome. Here is what it looks like:

          curl -X POST https://delegatezero.com/api/v1/context \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "context": "Here is a list of our client's including their contact information.",
    "files": "https://example.com/data.pdf"
  }'

          import axios from "axios";

const context = await axios.post(
  "https://delegatezero.com/api/v1/context",
  {
    context: "Here is a list of our client's including their contact information.",
    files: "https://example.com/data.pdf"
  },
  {
    headers: {
      Authorization: `Bearer ${process.env.API_KEY}`
    }
  }
);

          import requests
import os

response = requests.post(
  "https://delegatezero.com/api/v1/context",
  headers={
    "Authorization": "Bearer {os.environ['API_KEY']}",
    "Content-Type": "application/json"
  },
  json={
    "context": "Here is a list of our client's including their contact information.",
    "files": "https://example.com/data.pdf"
  }
)

The endpoint currently accepts two inputs: a context string and optional files.

The response is very simple and only returns a confirmation:

{
  "response": "Context added",
}

Webhooks

Webhooks let DelegateZero notify your systems when events occur. Here are the current webhook events that you can subscribe to:

Webhook payloads are JSON and include the full decision response object.

{
  "event": "decision.created",
  "created_at": "2026-01-26T14:12:09Z",
  "data": {
    "id": "dec_9f31c2",
    "decision": "execute",
    "confidence": 0.86,
    "reason": "Request aligns with stored policies and prior precedents",
    "response": "<p>Hi there,</p><p>Here's your monthly update...</p>",
    "audit_url": "https://app.delegatezero.com/audit/dec_9f31c2"
  }
}

The data object matches the standard decision response format described in the response object section.

Configure your webhook endpoint URL in the dashboard and DZ will send HTTP POST requests to that URL every time an action occurs your endpoint should respond with a 2xx status code to acknowledge receipt.

Audit logs

Every decision DelegateZero makes is recorded in an audit log. Audit logs are designed to help you understand what happened, why a decision was made, and what information was used — without exposing internal model reasoning - so that context and, therefore, decisions can be improved.

An audit log captures a snapshot of the decision at the time it was made.

• The original request
• The decision outcome
• The confidence score
• The primary reason for the decision
• The context that was considered
• The policies, precedents, or playbooks that influenced the outcome

The best way to make future improvements based on what you see in an audit log is to either edit the specific context in the dashboard or add new, comprehensive context.

You can access audit logs from:

• The audit_url returned with each decision
• The dashboard audit log view

API access to audit logs may be added in a future release.

Confidence & escalation

Confidence thresholds determine when DelegateZero is allowed to act automatically. Each decision is assigned a confidence score between 0 and 1. If the score meets or exceeds your configured threshold, the decision may be executed. Otherwise, it is escalated or returned as a draft. Lower thresholds increase autonomy. Higher thresholds increase safety.

You can override confidence thresholds on a per-request basis using instructions.confidence_threshold.

Policies & safety

Policies define non-negotiable rules and boundaries that DelegateZero must follow. They always take precedence over confidence, precedents, and playbooks.

If a request conflicts with a policy, DelegateZero will escalate instead of guessing or partially complying.

Use policies to encode rules such as approval limits, forbidden actions, compliance requirements, or escalation conditions.

Hard stops are conditions under which DZ must never act automatically. When a hard stop is triggered, the request is escalated regardless of confidence.

Examples include irreversible actions, legal or financial risk, or missing required context, and these can be configured through policies.

Risk levels

Risk levels allow you to categorize decisions by their potential impact. Higher-risk categories can require higher confidence thresholds, stricter policies, or mandatory escalation.

Risk levels are useful for gradually increasing autonomy as trust is established.

Assistant attribution

Assistant attribution controls how responses are framed when DZ communicates externally. You can choose whether responses appear to come directly from you or from an assistant acting on your behalf - a reasonable next-step on your path to feeling confident with DZ being able to handle your decision-making.

This setting affects tone and attribution only. It does not change the underlying decision logic.

You can override attribution for individual requests using instructions.attribution.

Support & reference

This section covers common questions, troubleshooting guidance, and reference information for operating DelegateZero safely and effectively.

FAQs

• Does DelegateZero replace human judgment?
  No. DelegateZero represents your judgment using the context you provide and escalates when confidence is low or boundaries are unclear.
• What happens if DelegateZero is unsure?
  The request is escalated instead of guessed. Escalation is the default safety behavior.
• Can I override behavior for a single request?
  Yes. Use request-level instructions to override defaults such as confidence thresholds or execution mode.
• Can I undo a decision?
  Audit logs are immutable, but you can correct future behavior by adding or updating context.

Debugging decisions

If a decision doesn't match your expectations, start with the audit log.

Review:

• The original request and context
• The confidence score
• The reason provided
• Which policies, precedents, and entities were applied

Most unexpected outcomes are caused by missing or ambiguous context, not incorrect logic.

Why something escalated

Escalation occurs when DelegateZero cannot safely act on your behalf. Common reasons include:

• Confidence below the required threshold
• Missing required context
• A policy or hard stop was triggered
• Conflicting signals from prior precedents
• High-risk or irreversible actions

Escalation is a feature, not a failure. It protects you from unintended actions.

Improving confidence

Confidence improves as DelegateZero better understands how you make decisions. To increase confidence:

• Add clear policies for hard boundaries
• Record precedents for recurring decisions
• Use playbooks for ambiguous or judgment-heavy situations
• Attach relevant sources and reference material
• Ensure important entities have up-to-date information

Start with low-risk decisions and expand autonomy gradually.

Security & privacy

Security and privacy are foundational to DelegateZero. Your data is used only to make decisions on your behalf and is never shared across accounts.

• All data is transmitted over HTTPS
• API access is authenticated using bearer tokens
• Context and audit logs are isolated per account
• Sensitive information should be added intentionally

See the Privacy Policy for details on data handling and retention.

Changelog

The changelog tracks notable updates to the DelegateZero platform.

Changes that affect API behavior, request or response formats, or safety guarantees will be documented here. Breaking changes will be announced in advance whenever possible.

v1.0.0 — Initial release

The initial public release of DelegateZero focuses on safe, explainable decision delegation.

• Decision API for requesting judgments and actions on your behalf
• Flexible request object with request, context, and instructions
• Structured response object with confidence scoring and audit links
• Confidence-based execution, drafting, and escalation
• Context ingestion via dashboard and /context API endpoint
• Support for policies, precedents, entities, playbooks, templates, and sources
• Immutable audit logs for every decision
• Webhook notifications for decision creation and escalation
• Dashboard-based configuration for safety and attribution
• Chat interface for request/response testing

Future releases may expand execution capabilities, integrations, and observability.