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.
- 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.
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.Access: Must be enabled for your organization. Contact your Gradial team to get access.
What you can ask
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.
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.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
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.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.
Alongside these, 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.
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).
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.”
- 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
- 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