AI news ·
How skills and agents work together in AWS Quick
AWS Quick now lets you encode repeatable tasks into reusable instructions called skills, so you stop re-explaining the same weekly status update or ticket-creation process.

AWS Quick now lets you encode repeatable business tasks into reusable instructions called skills, which AI agents then execute against your connected data and applications. For professionals in customer support, education, hospitality, IT, management, operations, product development, and sales, this means you can stop explaining the same weekly status update, release note, or ticket-creation process more than once.
How agents and skills work together
An agent in AWS Quick is a configurable AI with its own instructions, knowledge sources, and connectors. The default agent, called Quick, has no fixed scope and can draw on any resource you can access. A custom agent is one you configure for a specific job - an HR onboarding assistant that answers new-hire questions from the HR team's space, for example. You give it instructions and limit it to the spaces, connectors, and skills your use case requires.
A skill is a reusable set of instructions that teaches an agent how to do a specific task. It follows the open Agent Skills specification, which Anthropic originally developed. Each skill is a folder with a Markdown file at its root, plus optional scripts or reference files. The file's frontmatter holds the name and description - the two most important attributes for triggering the skill. Quick uses progressive disclosure: the agent reads only each skill's name and description until a request calls for that skill, at which point it loads the full instructions.
Agents ground their answers in your data. A space is a curated collection of documents and resources. A knowledge base is an indexed collection optimized for retrieval and question answering, synced from sources like Google Drive, Confluence, or Amazon S3. Connectors link Quick to external applications - Outlook, Slack, Jira, Salesforce - so agents can read data and take action on your behalf.
Building and sharing a skill
You can create a skill directly from a chat conversation. Describe your task to Quick using a template like: "Every [day/week], I have to grab data from [sources] and do [task]. Once I am finished, I have to create a report and send to [stakeholders] using [connector]. Create a skill from this requirement."
After you are satisfied with the result, publish and share it. Choose Customize, then Skills, find your draft, and open its detail panel. Publishing and sharing are separate steps - publishing alone doesn't give anyone access. The people you share it with add it from Add to Quick under Shared with me, and their version stays in sync each time you publish again.
Best practices for production skills
"It works on my machine" is a common pitfall. Skill instructions can query data sources or invoke connectors that others might not have access to. Document prerequisites, or share the agent alongside the sources it connects to. Plan for failures by giving agents concrete fallback instructions. If a step says "Send the report over email," add what to do when that fails: "If sending fails, stop and tell the user the report wasn't sent and why."
Test every change using the environment your downstream users will use. Keep hardcoded values out of the steps and declare them as inputs. Record when the skill changed and where each reference file came from. The AI Productivity Courses available through training platforms can help teams adopt these engineering practices for their skill-building workflows.
The AWS Quick official catalog provides pre-built skills that follow these practices. One is the Skill Architect skill, which applies engineering best practices for you. Install it from the catalog under Customize, Skills, Browse all, and then Official.
Why this matters for operations and IT professionals
When you configure a custom agent, you choose the spaces it reads from, the connectors it can use, and the skills it can load. An agent works best when bounded to a particular use case. But when you share that agent, it runs with the access of the person using it - the same request can return incomplete answers if it needs a source only you can access. Tying agents, skills, and spaces together requires testing the full environment, not just the skill in isolation. The Skill Architect skill and the official catalog reduce the guesswork by providing tested, versioned resources that account for these dependencies before you share them with a team.