Finance wants invoice exceptions resolved and the month-end close prepared. Sales operations wants the CRM kept current and deals reviewed faster. HR wants payroll changes checked before the run. Legal wants a first-pass redline against the firm's playbook. Different departments, but a familiar kind of work: a procedure, carried out by someone who knows the steps, the exceptions and what good looks like.

A procedure can become reusable instructions, templates and checks in the ChatGPT, Claude, Copilot or Gemini your team already uses. The AI prepares the work to an agreed standard. Your people review, decide and act. Start with a useful job in your existing workspace; the implementation depends on its features, plan and permissions.

We call these programmatic AI workflows. This guide explains what they contain, the shapes the work takes, examples across departments, and the engineering behind a package a team can run and maintain. Our research into more than 7,000 catalogued public skill definitions informs the approach; your own context determines what gets built.

A prompt, a procedure and a package.

A prompt is a request. In a one-off conversation, one person asks and judges the answer. Unless the team saves and shares the method, the next person starts again. A good prompt is a useful start. A workflow makes the method available for the next person and the next run.

A programmatic AI workflow is a procedure built for repeated use. Its trigger, inputs, steps, templates, checks, exception rules and output are specified in advance. The person running it brings this week's export or today's order; the instructions are already there. The output tells the reviewer what could not be assessed and needs attention. “Programmatic” describes the specified procedure; some workflows need scripts, while others use written instructions and supporting material.

Your team receives a package: working instructions, templates, reference material, exception rules, test inputs and expected outcomes, and a record of performance on those tests. Handover notes explain what the workflow does, where it stops and who owns changes. For a workflow delivered as an Agent Skill, the instruction file is its entry point. Evaluation material belongs with the maintained release; expected answers stay outside the tested workflow's access.

The installed portion and its setup depend on the workspace. Technical formats such as skills and plugins are ways to deliver parts of that package; they are not interchangeable names for every implementation. We handle those choices around the work your team needs to do.

The business gets a capability: something its team can now do using a shared method and standard. One capability may contain several workflows. For example, a closed-deal handoff might prepare an onboarding checklist, a billing setup draft and a missing-information list through three related procedures.

The principle holding it together is the one on our home page: AI prepares. People decide.

Five shapes of business work.

We use five patterns to make the work easier to recognize and scope. They overlap: one procedure may match records, prepare a review and route an exception. The pattern gives us a starting point for the inputs, failure cases and checks.

Match
Compare records that should agree and report where they do not: an invoice against a purchase order and receipt, a remittance against open invoices, or payroll changes against the HR record. The critical check is whether the evidence supports a match; uncertain candidates stay unresolved.
Route
Classify an incoming item and propose the right person or queue: a support escalation, IT ticket, contract request or inbound demo request. Ambiguous cases need an explicit review path, rather than a confident destination with no basis.
Prepare
Assemble what someone needs before a decision or meeting: the deal brief for Monday's forecast call, a case summary for engineering, a redline against a playbook or an onboarding checklist. Missing evidence should become a visible question.
Extract and track
Pull relevant terms from documents into a list the business can act on: renewal dates, notice periods, insurance expirations or missing supplier forms. Keep a reference to the source and distinguish a term that is absent from one the workflow could not read.
Orchestrate
Coordinate a procedure's steps and handoffs: month-end close preparation, supplier onboarding, joiners and leavers, order exceptions or a shipment disruption. Start with a prepared plan and an owner for each action. Connected execution adds permissions, approval and recovery requirements.

A matching workflow can pair records on weak evidence. A routing workflow can assign an ambiguous case to the wrong team. A preparation workflow can invent the detail it should have flagged as missing. Naming those failures before building gives testing a useful target.

The work, department by department.

These illustrative briefs show how to scope the job: what starts a run, what the workflow prepares and what stays with a person. Each can begin with approved files and exports. The examples describe candidate workflows to build and test; they are not reports of client results. Live connections are a separately scoped step.

Finance

  • AP exceptions. Start with the invoice, purchase order and receiving record for an exception. The workflow sets them side by side, identifies discrepancies and proposes a resolution with its evidence. The AP lead confirms the cause and approves the next action; uncertain matches stay open.
  • Month-end close. Start with approved account exports and the close checklist. The workflow prepares reconciliation drafts, proposed accruals, intercompany differences and an open-item list by owner. The controller reviews the evidence, posts entries and signs off.
  • Cash application and collections. Start with remittance advice and open invoices. The workflow proposes matches, lists unmatched cash with possible candidates and drafts reminders by aging bucket. The collections lead confirms the matches and decides which reminders go out.

Sales operations

  • CRM data and rep admin. Start with approved call notes, correspondence and a CRM export. The workflow drafts stage, next-step and close-date updates, pointing to the evidence for each. The rep accepts, edits or rejects every proposed change.
  • Deal desk approvals. Start with a discount or non-standard pricing request. The workflow prepares the approval packet against policy: proposed terms, margin calculations where inputs support them, comparable approved deals and missing information. The approver decides; out-of-policy requests escalate.
  • Forecast call preparation. Start with the deals in the forecast period and their latest records. The workflow assembles stage changes, next steps, supporting notes and missing fields in the team's meeting format. Reps resolve the gaps; the manager runs the call.

HR

  • Payroll changes. Before a payroll run, compare approved exports from recruiting, HR and payroll systems. The workflow identifies new hires, pay changes and departures that disagree across records. The payroll lead investigates and corrects them; the workflow prepares the exception list.
  • Employee inquiries. Start with the question and the approved policy version. The workflow drafts an answer, cites the relevant section and flags missing or ambiguous guidance. HR confirms the response and handles cases requiring judgment.
  • Onboarding. Start with an accepted offer and a role-specific checklist. The workflow prepares equipment, account and administrative requests and tracks missing information. The HR owner releases requests; the responsible teams complete them and the manager confirms readiness.
  • Contract redlines. Start with the contract and an approved review playbook. The workflow prepares proposed edits and explains departures from the standard, citing the relevant clauses. The lawyer reviews the draft; questions outside the playbook go to counsel.
  • Contract intake. Start with the request. The workflow identifies the requester, contract type, proposed template and reviewer, then lists missing information. Legal operations assigns the work; the lawyer takes it from there.
  • Contract obligations. Start with approved signed contracts. The workflow extracts renewal dates, notice periods and other specified obligations into a source-linked register. The business owner and counsel check the interpretation and decide what to renew, renegotiate or let lapse.

Operations

  • Disruption management. Start with a shipment delay or supplier issue and the affected order records. The workflow identifies customer commitments, prepares options and drafts notices. The operations lead chooses the response and approves communication.
  • Order exceptions. Start with held orders: credit holds, incomplete addresses or unavailable inventory. The workflow lists each exception, its supporting evidence and the available next steps. The order desk clears or escalates each one.

Procurement

  • Supplier onboarding. Start with the supplier's submitted documents and your requirements. The workflow checks for required forms, insurance information and screening evidence, then lists missing or conflicting items. Procurement approves the supplier; finance independently verifies and approves banking details through its established process.
  • Three-way match. Start with invoices, purchase orders and receiving documents. The workflow flags possible duplicate invoices, prices above the order and quantity mismatches with their evidence. AP decides what to pay, dispute or return.

IT

  • Joiners, movers and leavers. Start with approved employment changes and access rules by role. The workflow drafts provisioning, change and removal requests in the ticketing format, with the relevant dates. IT checks and approves requests; the authorized systems perform access changes.
  • Ticket routing. Start with incoming tickets and the team's routing rules. The workflow proposes a category, team and priority, explains the basis and flags ambiguous cases. The dispatcher confirms or overrides the suggestion.

Marketing

  • Speed to lead. Start with an inbound inquiry and approved customer criteria. Using available, permitted information, the workflow prepares the qualification summary, proposed owner and first-message draft. The rep owns follow-up; marketing operations owns routing rules and response targets.
  • Media reconciliation. Start with invoices, insertion orders and delivery reports. The workflow compares what was ordered, billed and recorded as delivered, then lists discrepancies with amounts and sources. The media lead investigates and seeks credits, disputes charges or approves payment.

Customer operations

  • Escalation routing. Start with the customer case and escalation criteria. The workflow proposes the receiving team and gathers the evidence that team needs. The support lead checks the destination and releases the handoff.
  • Case summaries. Start with the approved case record. The workflow assembles the timeline, environment, reproduction steps and open questions. The support engineer verifies the summary and submits it to engineering.

For every checking job, distinguish what was examined, what was excluded and what could not be assessed. “Nothing found” and “could not check” should never look alike. The human responsibilities above are part of the design. Any later transfer of authority needs its own decision, controls and evidence.

When you are building something new.

A startup or growing business may need a capability before it has a settled procedure or an expert team. The starting point is the job and its owner. Select suitable general methods, adapt them to the business, agree useful outputs and improve the method through the first runs.

For example, a founder establishing marketing could begin with related workflows for a customer-research brief, an offer outline and an outreach draft. Shared context keeps the audience and proposition consistent. The founder supplies business facts, reviews the work and decides what to use. The package gives that emerging function a method it can maintain.

These are our two paths: capture what works through Fully Powered Studio, or build what's missing from reusable workflow foundations. The second uses appropriately reusable methods and templates, never another client's private operating knowledge.

Built to run means it can keep growing.

A specified procedure gives later automation something concrete to execute and test. Choose among three operating modes to suit the job. Moving between them may require additional implementation; a workflow can remain on request for as long as that serves the team.

  1. On request. A person starts the run, brings the approved inputs and reviews the output. This is a useful first implementation and may remain the right design. Real use reveals which instructions, exceptions and checks need work.
  2. On a schedule, with review. A configured scheduler starts the job when inputs are ready or at an agreed time. The prepared output waits for a person. Define what happens if an export is late, a run fails or the same work is triggered twice. Scheduling does not itself authorize business actions.
  3. Called by your systems. An application or integration invokes the procedure as part of a larger process. Specify permitted actions, approvals, logging, exception handling and recovery. Any decision to automate an action should consider its consequences, the test record and ongoing monitoring.

Broad system access cannot substitute for an agreed procedure. Before enabling it for live work, define the expected output and run tests that record attempted and completed actions. Use a successful demonstration as the starting point for those tests.

The procedure is a durable asset: its rules, examples and acceptance criteria can inform an implementation in another workspace. Moving to ChatGPT, Claude, Copilot or Gemini still requires checking the destination's features, packaging and permissions, then retesting. The operating knowledge can travel; each implementation needs its own checks.

What to settle before connecting business systems.

Letting AI read business records or act through connected tools is an engineering decision as well as a productivity one. Settle these responsibilities while the workflow is being designed. The security guide develops the controls and tests in more detail.

  • Access. Begin with approved files and exports where they serve the job. A live connection should reach only the records and operations the procedure requires. Configure those limits in the application, server and source system, with an owner who can disable the connection and revoke credentials. Read-only access still requires care about where information can be sent.
  • Approved information. Someone in the business decides which information may enter the AI workspace, including client records, employee information and material covered by contractual obligations. A subscription alone does not settle that choice. Apply your existing approval process to the intended use.
  • Instructions inside documents. An invoice, email, contract or tool response can contain text that tries to redirect the AI. Treat that content as material to examine. Combine clear instruction boundaries with restricted tools, enforced approvals and tests of attempted actions. A sentence asking the AI to be careful is insufficient protection.
  • Silent omissions. Require the output to report coverage, exclusions and items it could not assess. Use counts where they help a reviewer reconcile the input set with the result. Test unreadable pages, missing records and partial inputs explicitly.
  • Drift. Models, application features, connections and your procedures change. Record the versions and conditions tested. Rerun relevant cases after changes and monitor actual use; an earlier test result describes the earlier configuration.
  • Ownership. Name who agrees the method, approves changes, investigates failures and can pause the work. Keep a version history and identify which release produced each output.

These decisions make the capability inspectable and maintainable. Our introductory sprints start with files and exports in the client's workspace. Live integrations and unattended operation are separately scoped around the controls the work requires.

Couldn't we just do this ourselves?

Yes. A capable internal team can build and maintain this. A saved prompt or an existing product feature may already serve a simple job. The useful question is what the team needs beyond a first draft.

  • An agreed standard. Define what a useful result contains, what it excludes and which cases require a person. Resolve differences between experts before encoding them as instructions.
  • Exception rules. Capture what experienced people do when the ordinary case does not apply. A demonstration of an awkward job can reveal more than a polished SOP.
  • Held-back tests and reference outcomes. Include ordinary work, unusual formats, missing inputs, conflicting records and requests that should not start the workflow. Keep expected answers unavailable to the tested system.
  • Independent judgment. Separate building from grading. Use checks appropriate to the task and have the responsible person judge the result. An AI's opinion of its own answer is not sufficient validation.
  • Tests for how the work fails. Check false matches, misrouted exceptions, invented details and omitted records. The five patterns help identify where to look; actual testing shows how this implementation behaves.
  • The surrounding engineering. Configure access and approval, record coverage and actions, version the package and retest changes.
  • A package the next person can run. Give the next person the templates, references, evaluation record, operating notes and a named owner they need to carry on the work.

Building also takes the team's time. The expert who can define the work may already be the bottleneck. Fully Powered AI brings its technology and a builder alongside that person, focusing their time on the method, exceptions and judgments that need their expertise. We agree the scope and the time they need to contribute before starting.

Fully Powered Studio supports capturing existing work. Reusable workflow foundations support establishing new capabilities. We adapt, implement, test and refine the result with the team, with continuing work available as needs change. Clients can start with a focused sprint, a new capability or a broader implementation.

Your information and know-how remain yours. The agreement sets out rights to use and adapt the deliverables and included technology. Our aim is useful work in the AI your team already uses, supported by a method the business can inspect and maintain.

What the AI providers say.

The providers' documentation describes ways to give AI reusable guidance. Packaging, availability and controls vary by product and workspace.

ChatGPT

“Skills are reusable workflows made from instructions and supporting resources.”

OpenAI's Skill controls documentation distinguishes ChatGPT workspace Skills from local filesystem skills and plugins, each with its own access controls.

Claude

“Skills teach Claude how to complete specific tasks in a repeatable way”

Anthropic's What are skills? describes task-specific folders of instructions, scripts and resources that Claude loads when relevant.

Copilot

“Instructions and constraints that apply consistently across conversations.”

Microsoft lists this as a reason to configure a declarative agent for Microsoft 365 Copilot. The quotation describes that configuration; it does not establish support for an arbitrary SKILL.md package.

Gemini

“Skills are reusable instructions that customize how Gemini works for you.”

Google's Gemini Apps documentation describes reusable instructions for recurring tasks. Its 13 October 2026 rollout update says the Gemini app rollout had begun, while skills in Workspace were delayed. Check availability in the account that will run the work.

Where to start.

Choose one recurring job for an initial proof. Weigh how often it happens, the expert attention it consumes, the consequences of a miss and the teams that depend on its handoff. Finance, sales operations, HR, procurement, legal or marketing may supply the right first job; the business's actual workload should determine the order. A larger implementation can use that first job to establish the method while other work is scoped.

Then check six things: who runs it and who sets the standard; what starts the job and what should come back; what it needs each run; where judgment belongs; how the result will be assessed; and whether the workspace and information use are approved. Prepare for your first workflow walks through those questions.

Before adding unattended execution, ask the builder:

  • Who agreed the standard, and how does it reflect our work?
  • Which cases informed the build, and which were held back?
  • How were omissions, missing information and unusual inputs tested?
  • What can it read, what can it do, and who can revoke that access?
  • Who graded the results, and can we inspect the misses?
  • What will we measure in use, and who owns changes?

Use the answers and test records to decide what is ready, what needs improving and what should remain with a person.

A note on the words.

You will encounter skills, plugins, agents, digital workers and copilots. Those labels describe different things across products. We start with three words: a workflow is one procedure, built to run; a capability is what your business can do, which may take several workflows; a package is what your team receives to run, check and maintain the work.

Technical names matter when choosing the implementation and handing it over. Start with the work; the terminology can follow.

Bring one job to a fit call. We'll help define the workflow, what it needs and whether it's ready to build.

About our reference collection.

Our industry and function research draws on 7,194 retained entries in a catalogue of public skill definitions, using a 14 October 2026 snapshot. We reviewed descriptions and methods to understand the work they address. This was a review of the material, not a record of running and testing every skill. Duplicate and rejected entries were tracked separately.

The collection shows what people have written methods for; it does not establish market demand or client results. The five patterns in this guide are our editorial framework for recognizing and scoping work, not an exhaustive statistical classification of the collection.

This research informs how we capture existing know-how and select reusable foundations for new capabilities. We adapt suitable public and general methods to the business; another client's private workflows are never stock for that work.