Agents Need More Than Prompts. They Need Skills.

Prompts can tell an agent what to do, but they do not give it a reliable way to do the work. As AI agents move into real applications, teams need reusable capabilities for generating files, querying data, creating reports, running calculations, scheduling tasks, and calling business workflows.

In ZGI, we call these capabilities Skills.

Skills give agents a consistent, reusable way to perform actions without rebuilding the same logic inside every prompt or workflow. This article explains why we are building a Skills layer in ZGI, how it fits alongside models, tools, workflows, memory, and knowledge, and why we are making the ZGI runtime available for developers to inspect, run, and improve.

There is a point in almost every agent project where prompts stop being enough.

At first, the agent answers questions.

Then someone asks it to create a spreadsheet.

Or generate a report.

Or query a database.

Or calculate a metric.

Or run the same task every Monday morning.

At that point, the agent is no longer just producing text. It is expected to do work.

That change sounds small, but it creates a different engineering problem.

A prompt can describe an action. It cannot guarantee that the action is implemented consistently, safely, or in a way that another agent can reuse.

This is where Skills come in.

What We Mean by a Skill

A Skill is a reusable capability that an agent can call while completing a task.

It might:

• generate a file;

• create a chart;

• query an approved database;

• calculate a result;

• schedule an action;

• call an internal API;

• invoke another workflow;

• transform structured data;

• produce a report in a defined format.

The important word here is reusable.

Without a Skills layer, teams often recreate the same behavior in several places.

One workflow contains custom code for generating a PDF.

Another agent uses a long prompt to produce a similar document.

A third application calls a separate script maintained by someone else.

All three are trying to perform the same basic task, but the implementation, permissions, output format, and error handling are different.

That may be acceptable for a prototype.

It becomes difficult to maintain once several teams and applications depend on it.

A Skill turns that repeated behavior into a named capability with a clear interface.

The agent decides when it needs the capability. The runtime handles how it is executed.

Skills Are Not Just Longer Prompts

It is tempting to treat every agent capability as a prompt-engineering problem.

Need a report? Add more instructions.

Need structured output? Add a JSON schema.

Need calculations? Ask the model to reason more carefully.

Need to query a database? Put the schema in the context.

Sometimes that works.

Sometimes it produces a convincing answer that happens to be wrong.

The issue is not that prompts are useless. Prompts are essential for defining intent, constraints, and expected behavior.

But prompts should not be responsible for everything.

A reliable agent needs a separation between:

• reasoning, handled by the model;

• knowledge, provided through retrieval and memory;

• actions, provided by tools and Skills;

• process, coordinated by workflows;

• control, enforced by the runtime.

Skills sit in the action layer.

They give the agent a bounded way to do something beyond generating text.

Skills, Tools, and Workflows Are Related—but Different

The terminology around agents is still messy, so it is worth being explicit about how we think about these concepts.

A tool is an interface to an action

A tool may expose an API, a database query, a code function, or a service.

It answers the question:

What action is available?

A Skill packages capability for reuse

A Skill may use one or more tools, along with instructions, validation rules, execution logic, and output handling.

It answers:

How should this capability be performed consistently?

A workflow coordinates multiple steps

A workflow combines retrieval, model calls, Skills, conditions, loops, approvals, and notifications.

It answers:

In what order should the work happen?

For example, “create a weekly sales report” might involve:

1. querying a database;

2. validating the returned data;

3. calculating changes from the previous week;

4. generating a chart;

5. writing a summary;

6. creating a document;

7. sending the result to a team channel.

The database query and chart generator may be tools.

The reusable “report generation” capability may be a Skill.

The complete seven-step process is a workflow.

Keeping those layers separate makes the system easier to understand and maintain.

Why Skills Matter More as Agent Usage Grows

When one developer builds one agent, duplication is easy to ignore.

When ten teams build dozens of agents, duplication becomes infrastructure debt.

You start seeing the same problems:

• different teams implement the same capability in different ways;

• file generation works in one agent but fails in another;

• database access rules are copied into prompts;

• business logic is hidden inside long workflow nodes;

• nobody knows which version of a capability is current;

• changes require editing several agents manually;

• permissions are difficult to audit;

• execution logs are spread across different services.

Skills provide a place to consolidate that logic.

A team can improve a Skill once and allow approved agents to reuse the updated capability.

That does not remove the need for application-specific logic. It removes the need to rebuild common infrastructure every time.

Skills Should Belong to the Organization

There is another reason we care about reusable Skills: ownership.

A surprising amount of AI application knowledge currently lives in personal accounts.

A developer writes a useful prompt.

An operations manager builds a workflow.

A data analyst creates a database query.

A product manager works out the correct steps for generating a report.

The result may be valuable, but it often remains attached to the person who created it.

When that person moves teams or leaves the company, the organization may lose both the configuration and the reasoning behind it.

We think Skills, prompts, workflows, agents, and knowledge connections should be manageable as organizational assets.

That means teams should be able to:

• assign ownership;

• control who can view or use a Skill;

• update it without editing every agent;

• inspect where it is being used;

• review execution records;

• transfer responsibility between members;

• keep sensitive capabilities inside an approved workspace.

The goal is not to make development more bureaucratic.

It is to make useful work survive beyond the person who first built it.

A Skill Needs a Runtime

A folder of scripts is not a Skills system.

For a Skill to be dependable, the runtime needs to handle more than execution.

It also needs to think about:

• input and output contracts;

• credentials;

• access permissions;

• sandboxing;

• timeouts;

• retries;

• logs;

• usage records;

• model context;

• workspace boundaries;

• failure handling.

This is one reason we describe ZGI as an Agent Runtime workspace rather than only an agent builder.

The visual interface matters, but the runtime underneath it matters more.

The runtime is what connects the agent to approved knowledge, database tables, workflows, models, memory, and Skills while keeping the execution path visible.

What Skills Look Like in ZGI

In ZGI, Skills are intended to be reusable capabilities that agents can call while working on a task.

Examples include:

• creating documents and files;

• generating charts;

• producing structured reports;

• running calculations;

• scheduling future actions;

• accessing approved databases;

• calling existing workflows;

• interacting with internal services.

An agent can combine these capabilities with knowledge retrieval, memory, model reasoning, and workflow execution.

Consider a procurement assistant.

A user might ask:

Compare the latest supplier quotations and prepare a recommendation.

The agent may need to:

• retrieve supplier policies from the knowledge base;

• query quotation data from a database;

• calculate price differences;

• check delivery dates;

• apply a comparison rule;

• generate a chart;

• write a recommendation;

• export the result as a document.

This should not depend on one enormous prompt.

Each reliable action should come from a reusable capability with an observable execution record.

Skills Also Need Boundaries

Giving agents more capabilities creates more responsibility for the platform.

Not every agent should be able to call every Skill.

A customer-service agent may be allowed to query order status but not modify financial data.

A reporting agent may generate spreadsheets but not send external emails.

A finance workflow may access a restricted database that other workspaces cannot see.

This means Skills need to work with permissions, not around them.

Access should be determined by the workspace, role, agent configuration, data visibility, and runtime policy.

The same is true for model access.

Some Skills may require a high-capability model. Others may work perfectly well with a faster, lower-cost model.

A production runtime should make those choices manageable instead of hiding them in code.

Why We Are Opening This Work

We recently made the ZGI source code available because we want developers to be able to inspect how these pieces fit together.

There are many opinions about how agent runtimes should work.

We do not expect to get every abstraction right on the first attempt.

Skills are a good example.

Questions we are still thinking about include:

• How small should a Skill be?

• When should a capability be a Skill rather than a workflow?

• How should Skills declare permissions?

• How should inputs and outputs be versioned?

• How should teams share Skills between workspaces?

• What should run inside a sandbox?

• How much control should the agent have when selecting a Skill?

• How should failed execution affect the rest of the task?

These are easier to solve when the architecture is visible and developers can challenge it.

Open development also forces us to be clearer.

If a Skill only makes sense after a private explanation from our team, the abstraction is not ready.

If the runtime behavior cannot be understood from the code and logs, the observability is not good enough.

If the extension path requires changing internal modules, the interface needs more work.

That pressure is useful.

What We Hope Developers Will Build

We are interested in Skills that solve ordinary, recurring work.

Not only impressive demos.

Things like:

• turning structured data into a weekly report;

• checking a contract against an internal policy;

• generating a presentation from approved content;

• processing a folder of invoices;

• preparing onboarding materials;

• monitoring an operational metric;

• creating files in a required company format;

• calling an internal approval workflow;

• producing charts with consistent definitions.

These tasks may not look dramatic in a demo video.

But they are the kind of tasks that determine whether an agent becomes useful to a team.

Where We Go From Here

Our direction for ZGI is straightforward.

We want agents to have access to reusable, governable capabilities without forcing every team to rebuild the same execution layer.

That means continuing to improve:

• the Skills runtime;

• visual Agent and workflow orchestration;

• model routing;

• enterprise RAG;

• database access;

• memory;

• sandboxed execution;

• runtime logs;

• permissions and governance;

• self-hosted deployment.

There is still a lot to do.

The project is available on GitHub, and we welcome issues, discussions, pull requests, and direct feedback.

Not every suggestion will fit the project.

But every serious use case helps us understand whether the abstractions hold up outside our own environment.

That is the point of making the work visible.

Closing

Prompts tell an agent what you want.

Skills give it a reliable way to act.

Workflows coordinate the steps.

The runtime keeps the whole process observable and under control.

That is the layer we are building with ZGI.

And now that the source is available, we would rather build it in conversation with developers than behind a closed door.