Skip to main content
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 the change you want in plain language — “Update the hero headline on this page to say X”
  • 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.
The Customer Use Cases page has real examples across every workflow area — a good place to see the range of what you can ask.

​
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 pages, paths, and assets explicitly. The more precise your sources, the less Grady has to infer. 
SOURCE_PAGE: https://www.example.com/products/premium-tier

TARGET_FOLDER: /content/site/en-us/products/

REFERENCE_PAGE: https://author.example.com/content/site/en-us/products/standard-tier

​
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, especially when working with specific components. 
Hero: Premium Product Launch
- Use this background image:
  /content/dam/site/images/heroes/premium-launch-hero.jpg
- Headline should be title case
- Include the CTA "Get Started"

​
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.
LevelUse it for
Rules (global)Standards every output must meet — brand voice, legal disclaimers, accessibility criteria
Skills (global)Reusable expertise — proven workflows, process patterns, institutional know-how
Folders (project-level)Guidance that applies to a set of related tasks — preferred styles, available patterns, standard steps
Tasks (specific)Details unique to one piece of work — the specific page, the specific change
General principle: Start specific at the task level. As you notice patterns, promote them to folder-level, rules, or skills.

​
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 see it in the studio. 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
  • Folder context — View any additional context being passed from the folder level
  • Rules & Skills panel — See which global and workspace rules and skills are active
  • 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