What Are System Skills? The Foundation of an Axon AI Workforce

System Skills are Axon's built-in executable capabilities for turning repetitive, manual, time-consuming, and error-prone office work into steps that can be inspected. Many users first understand an AI workforce as a better chat assistant. The Axon getting-started tutorial shows a different model: a user confirms a business goal, lets AI Build fill an Agent form, runs the Agent manually, checks a PDF file card and an email confirmation card, and only then considers scheduled execution.

This guide is based on the completed Axon beginner tutorial. The tutorial creates an Agent named Public Research Report Delivery. The Agent takes a public research topic, generates a Markdown research report, renders that report as a PDF, and sends the PDF as an email attachment after confirmation. The example is intentionally small, but it demonstrates the whole operating model: executable capabilities, structured outputs, human review for external actions, and a path toward automation.

If the Agent form itself is still unclear, start with How to Use AI Assistant and AI Build to Assemble Your First Agent. If you want to inspect the full execution chain, this article pairs naturally with How Research, PDF, and Email Become a Reviewable AI Workforce Workflow.

The key distinction is simple: if an AI tool only answers questions, it is still a chat tool. When it can call bounded capabilities, produce files, and pause for review, it starts to behave like a reviewable digital worker.

Why the Tutorial Starts with the Capability Layer

The website category is AI Workforce, but the first tutorial does not begin with a broad product tour. It begins with a concrete workflow:

1. Use the AI Assistant tab to confirm the business goal.
2. Use AI Build to convert that goal into an Agent form.
3. Run the Agent manually and inspect the research result, PDF card, and email confirmation card.
4. Consider Trust Mode or scheduled execution only after the manual run passes review.

This order matters. A new user does not need to understand every capability on day one. The user needs to understand what the platform can do, how an Agent sequences those capabilities, and where human review belongs.

How System Skills Differ from Prompts

A prompt usually describes one answer. It is hard to reuse, hard to validate, and hard to connect to a file or external action. System Skills have a Skill ID, an Action, parameters, permissions, and an expected output. In the tutorial, the chain looks like this:

Tutorial Step	Skill	Action	Main Output	Boundary
Generate public research	std-internet-research	deep-research-flash	Markdown research report	Automatic, but sources need review
Export a PDF	std-office-pdf	generate	PDF file card	Automatic, but format needs review
Send an email	std-internet-email	send_email	Confirmation card and send result	Confirm permission

That table is the skeleton of the AI workforce experience. Each step has inputs, outputs, and a permission boundary. The user can see progress and inspect the result instead of trusting a single final message.

Why User Skills Are Not the First Lesson

Axon also supports User Skills: business-specific workflows built by the user. The first tutorial does not start there because a new user needs to see stable platform capabilities before packaging a custom process. It is easier to learn the model by running Research -> PDF -> Email first, then later packaging a weekly report format, invoice review checklist, or legal summary template as a User Skill.

The lesson sequence is pragmatic. First, prove that a platform capability can produce a useful output. Then package your own business rules. Finally, orchestrate the stable pieces as an Agent.

Breaking Down the Tutorial Workflow

Step 1: Research Produces Markdown

The tutorial uses std-internet-research.deep-research-flash. This action is designed for explicit deep research requests, not for casual search. The user provides a public topic, such as AI office automation trends for white-collar teams. The expected output is a Markdown research report that can be passed to the PDF step.

A good research step should be checked against three questions:

• Does the result stay on the user-provided topic?
• Does it make source limitations visible?
• Does it avoid describing roadmap capabilities as fully available product features?

If the research step is weak, the PDF and email steps only make the weak result easier to distribute. That is why the tutorial asks the user to inspect the research output during the manual run.

Step 2: PDF Converts Markdown into a File

The second step uses std-office-pdf.generate. The action accepts Markdown and a filename, then produces a PDF file card. This matters because the workflow leaves the chat surface and creates a business artifact that can be previewed, attached, and reviewed.

A practical parameter shape is:

md: Markdown from the Research step
filename: ai-office-automation-report
template: research_report or default

The PDF step is useful after research reports, weekly updates, meeting notes, and internal briefings. It turns intermediate AI output into a document that a team can inspect.

Step 3: Email Keeps a Confirmation Boundary

The third step uses std-internet-email.send_email. This action has confirm permission, so the manual run should show a confirmation card before the email is sent. The user checks the recipient, subject, body summary, and attachment before approval.

That boundary is not a minor UI detail. Sending email is an external action. It should not be treated like generating a paragraph. The permission model tells the user which actions can run automatically and which actions must pause.

How to Design Your First Capability Chain

If you are evaluating Axon, do not start by asking for a fully autonomous worker that handles everything. Start with a short, public, reviewable chain:

1. Choose a low-risk topic or input.
2. Select a capability that produces intermediate content, such as Research or Markdown.
3. Select a capability that creates a business artifact, such as PDF, HTML, Word, or Excel.
4. Keep Trust Mode off if an external action is involved.
5. Run the workflow manually and inspect every step.
6. Only then decide whether scheduled execution is appropriate.

The following instruction mirrors the tutorial:

Build a Public Research Report Delivery Agent.
It should generate a Markdown report from a research topic, export the report as a PDF, and send the PDF as an attachment to a specified email address.
Before sending, pause for confirmation so the recipient, subject, body, and attachment can be reviewed.
Do not read private files, delete data, or send to unverified recipients.

This instruction gives the AI Assistant enough context to confirm the goal before AI Build fills the form.

Review Checklist for a Stable Foundation

Check Whether Inputs Are Clear

The tutorial keeps Source Data fields focused: research_topic, report_filename, email_to, email_subject, and output_language. These fields cover the topic, file name, recipient, email subject, and language. They are enough for the first workflow without overwhelming the user.

Check Whether Outputs Are Reviewable

A stable AI workflow should produce evidence. The tutorial has three review points:

• Markdown research content.
• A PDF file card and built-in preview.
• An email confirmation card, send result, and inbox receipt.

Those review points are what make the workflow operational. The user is not just told that the task finished; the user sees the artifacts.

Check Whether High-Risk Actions Pause

If the email step does not show a confirmation card, review the Agent configuration. Make sure the action is send_email and that Trust Mode was not turned on before the manual test. External sending, deleting, moving, and publishing should be treated as high-risk actions.

Common Mistakes

Mistake 1: Treating the Agent as a Bigger Chat Box

An Agent is not just a longer prompt. It has a role, task, instruction, fixed steps, Source Data fields, and a run policy. The tutorial emphasizes this by asking the user to inspect the Agent form before running it.

Mistake 2: Adding Too Many Steps to the First Workflow

It is tempting to add private file ingestion, customer email, publishing, and monitoring at once. The tutorial deliberately starts with three steps. A short chain is easier to debug and easier to trust.

Mistake 3: Turning on Automation Before Manual Review

Scheduled execution should not be the first test. It should be the trigger for a workflow that has already passed manual review. The tutorial makes the manual run the gate before scheduling.

FAQ

Q1: Are System Skills the same as unattended actions?

No. They are executable capabilities, but each action still has a permission boundary. In the tutorial, Research and PDF can run automatically, while Email sending requires confirmation.

Q2: Why does the first tutorial not start with User Skills?

Because new users need to understand the platform's built-in capabilities before packaging custom business rules. Once the foundation is clear, User Skills become easier to design.

Q3: How is this different from a chat assistant?

A chat assistant usually produces a one-time answer. Axon combines System Skills, Agents, Trust Mode, scheduled tasks, and file artifacts into a workflow that can be inspected and repeated.

Next Step

To get started, run the Research -> PDF -> Email flow manually and inspect each output. Then read How Trust Mode Protects Email Boundaries in an AI Workforce and Why a Scheduled Agent Must Pass Manual Review First before enabling automation.