> ## Documentation Index
> Fetch the complete documentation index at: https://docs.gradial.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Ask Grady

> Grady is Gradial's AI agent. Talk to it in plain language to get content work done — no special syntax required.

Grady is the AI agent at the center of Gradial. You talk to it like you'd brief a colleague: describe what you need, point it to the right page or asset, and it takes care of the rest. There's no prompt template to follow and no special syntax to learn.

That said, a bit of clarity goes a long way. The guidance below isn't about learning a prompt format — it's about the same habits that make any good brief effective: say what you want, be specific about sources, and know when to break a big job into smaller ones.

***

## How Ask Grady works

You interact with Grady through the task interface. You can:

* **Describe what you need** in plain language — "Update the hero headline on this page to say X"
* **Attach the brief.** Drag in the Word doc, deck, PDF or spreadsheet you were already sent, and ask Grady to work from it. You don't need to retype a brief into a prompt — attachments are usually the fastest way to start.
* **Use @ to point at things.** Type **@** anywhere to reference a teammate, a workspace, another task, or a connected integration. Grady receives that reference as structured context, so "build this like @Spring Campaign Landing Page" is more precise than describing it. See [Mentions](/docs/platform/mentions).
* **Ask questions** — "What components are on this page?" or "Why did you put the content there?"
* **Iterate** — If the first result isn't right, follow up. "The CTA button is missing — can you add it back?" Grady treats every task as a conversation, not a one-shot instruction.
* **Ask for a plan first** — For complex work, ask Grady to outline its approach before executing. It's easier to correct a plan than a finished deliverable.

<Tip>
  Two things worth knowing early: the [Customer Use Cases](/docs/gradial-prompt-library/customer-use-cases) library has real examples across every stage of the marketing lifecycle, each with a prompt you can copy and adapt. And if you find yourself typing the same request every week, save it as a **Prompt Template** — or put the whole task on a schedule with [Scheduled Tasks](/docs/workflow-management/scheduled-tasks) so it just runs.
</Tip>

***

## Ask Grady about your own Gradial data

Grady can answer questions about the work your team has already done in Gradial. Previously it could do the work but couldn't see its own record of it — anything spanning more than one task ("what's waiting on my team?", "who changed this page?") meant opening tasks one at a time.

Now you just ask, and Grady answers in the conversation, drawing on your tasks, artifacts, comments, activity history, and connected systems.

<Info>
  **Access:** Must be enabled for your organization. Contact your Gradial team to get access.
</Info>

### What you can ask

| Kind of question | Example |
| - | - |
| **Status of work in flight** | "What's waiting for approval?" · "What's been sitting longest?" · "What's assigned to me this week?" |
| **Tracing what happened** | "Which task changed this page, and who ran it?" · "Did anything fail on that migration?" |
| **Across your team** | "What has my team shipped since Monday?" · "Which tasks are blocked and on what?" |

Grady can also act on what it finds rather than just reporting it — for example, locating an environment that already has your CMS configured and switching to it so the work can continue.

### What it can and can't see

* **Reads only.** Answering a question about your data never changes it. Grady queries your record of work; it doesn't edit it.
* **Your permissions apply.** Answers only ever include what everyone in that task can already see. Two people asking the same question can correctly get different answers, because they can see different things.

<Tip>
  Be specific about the window and the scope you mean. "What's stuck?" is answerable, but "which tasks in this workspace have been waiting on approval more than three days?" gets you something you can act on directly.
</Tip>

***

### When you want a view, not an answer

If you find yourself asking the same question repeatedly, or you want something a team can look at rather than a reply in a thread, ask Grady to build you a **custom app** — a dashboard, report, or intake form built on the same live data, including the systems Gradial is integrated with.

See [Custom Apps](/docs/insights/custom-apps).

***

## Five habits that get better results

These apply whether you're asking Grady to swap an image or migrate a hundred pages.

### 1. State the objective and success criteria up front

Start with a single sentence: *what* you want and *how you'll know it's right*. "Update the pricing page" is a task title. "Change the monthly price from \$99 to \$89 and add '24/7 support' to the feature list" is something Grady can deliver against.

### 2. Point to exact sources

Name your sources explicitly. The more precise the source, the less Grady has to infer — and most of the time your source is a file or a link you already have.

Any of these work as a source:

* **A document** — attach the campaign brief, copy deck, product one-pager, or the spreadsheet of changes
* **A live URL** — "build this page from `https://www.example.com/products/premium-tier`"
* **A Figma file** — paste the frame link and Grady reads the design
* **A reference page** — "match the structure of our Standard Tier page"
* **An @ mention** — a workspace, another task, or a teammate whose work you want carried forward

```
Build a new product page for Premium Tier.

Source: the attached one-pager (Premium-Tier-Brief.docx)
Reference: match the layout of https://www.example.com/products/standard-tier
Assets: use the hero from the Spring 2026 campaign folder in the DAM
```

If your team works with CMS paths directly, those work too — a content path or DAM path is just as valid a source as a URL.

### 3. Break complex tasks into steps

For multi-stage work, ask for a plan before execution. This surfaces ambiguities early and keeps you aligned before the work starts.

### 4. Specify output format and constraints

Tell Grady how you want the output structured — and what it must and must not contain.

```
Hero section: Premium Product Launch
- Background image: use the approved hero from the Spring 2026 campaign folder
- Headline in title case, under 60 characters
- CTA button text: "Get Started"
- Include the standard pricing disclaimer
```

This applies to deliverables as well as pages. "Give me this as a Word doc I can send to legal", "put the results in a spreadsheet with one row per page", or "build me a slide for the Monday readout" all shape what you get back.

### 5. Use examples and reference pages

Grady is good at pattern matching. Pointing to a reference page that shows the right approach is often more effective than describing it in words.

***

## Where to provide standing instructions

Beyond the task itself, Gradial lets you embed guidance at multiple levels so Grady applies it automatically.

| Level | Use it for |
| - | - |
| **Skills** (organization or workspace) | Reusable expertise — how your team does its best work: proven workflows, process patterns, institutional know-how. This is where most standing guidance belongs. See [Managing Skills](/docs/marketing-brain/managing-skills) |
| **Foundational Guidelines** | Standards every output must meet — brand voice, legal disclaimers, accessibility criteria — kept in one governed, versioned library. See [Foundational Guidelines](/docs/marketing-brain/foundational-guidelines) |
| **Workspace** | Guidance that applies to a set of related work — preferred styles, available patterns, standard steps for that brand, region or team |
| **Task** | Details unique to one piece of work — the specific page, the specific change |

Alongside these, **[Memory](/docs/marketing-brain/memory)** carries decisions and context forward from completed work automatically, so your team doesn't restate the same things in every request.

**General principle:** start specific at the task level. As you notice yourself repeating guidance, promote it — to the workspace, then to a Skill or a Foundational Guideline.

<Note>
  Organizations that have been using Gradial for a while may still have **Rules** in place. Existing rules remain active; new standing guidance should go into Skills and Foundational Guidelines. See [Managing Rules (Legacy)](/docs/marketing-brain/managing-rules-legacy).
</Note>

***

## When results aren't right

Grady can often debug itself. A direct follow-up question is usually the fastest path.

**Ask Grady directly:**

* "Why did you place that content in that component?"
* "The hero isn't showing in the preview but I can see it in the CMS editor. Can you debug and tell me what's wrong?"
* "Compare this page to \[reference page] and identify the gaps."

**Use Gradial's visibility tools:**

* **Diff viewer** — Compare before and after states to see exactly what changed
* **Workspace context** — View any additional context being passed in from the workspace
* **Skills panel** — See which organization and workspace Skills and guidelines are active on this run
* **Pattern list** — Each run shows which patterns Grady used, including pattern IDs

**Common edge cases:**

* **Secondary navigation not updating:** "Please fix the secondary sticky nav so it corresponds to the page content."
* **Inherited components not updating:** Some CMS components inherit from a blueprint and won't update until inheritance is broken. Try: "Break inheritance on \[component name]."
* **Ghost components:** Placeholder components after a list edit typically disappear once changes are promoted to production.

***

## Avoid context overload

There's a balance to how much instruction you provide. Too much context — or a very long task thread — can reduce output quality, because all previous output becomes input for each new run.

**Keep instructions focused.** If you find yourself writing a wall of text, break the work into multiple tasks instead.

***

## Getting help

When submitting a support request, include:

* **A clear title** describing the issue type and symptom (e.g., "Migration: Hero not showing" or "Content Update: Eyebrow text not replaced")
* **A short description** of the issue and any debugging steps you've already tried
* **A link to the task** in Gradial
* **Screenshots** from your CMS editor if relevant, since support may not have direct access to your environment


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.