Finance & Payments

Building a Reviewable Agent Skill Library for a Payments Platform

A proposed versioned library of tested, guardrailed instructions that teach coding agents to complete real payment workflows correctly end to end, with every tool call's risk tier fixed before any agent runs.

August 21, 2026

OUTLINE

ENGAGEMENT SNAPSHOT

CS-035_AI_Agent_Skills_Payments_Platform image 1

Figure 1 - Key figures from this engagement, at a glance.

EXECUTIVE SUMMARY

Our client's payments platform already exposed an API and MCP surface that told coding agents what they could do, but not which of dozens of tools to reach for, in what order, what to verify between calls, or when to stop. Every agent was re-deriving that judgment from scratch on every request - workable most of the time, but on a payments platform, most of the time is the problem.

Pfactorial Technologies proposed building a reusable Agent Skill library on top of the client's existing API and MCP surface: a versioned set of instructions, reviewed and tested like code, that teaches coding agents - Claude Code, Codex, Cursor - how to complete real payment workflows correctly. Each skill declares exactly which tools it may call, what it must verify, and which actions require a human, so autonomy becomes a decision made once at authoring time rather than one the model re-makes on every request.

The proposed library is built by a repeatable pipeline that mines high-value, multi-call workflows - not one skill per API endpoint - from the client's own documentation, integration code, and support patterns, with every tool assigned a risk tier at inventory time that determines whether an agent may act alone.

Why this engagement is representative This engagement demonstrates Pfactorial's approach to safe agentic automation on regulated infrastructure: treating agent instructions as reviewed, tested, versioned artifacts with a fixed risk tier per tool, rather than trusting a model's in-the-moment judgment to decide what it may do.

THE CHALLENGE

The client's MCP server already exposed dozens of tools, but exposing a tool is not the same as teaching an agent how to use it correctly on a payments platform. Three problems shaped the proposed design.

1. Tools describe capability, not correct procedure

An MCP server tells an agent what it can do, but not which of forty tools to reach for, in what order, what to verify between calls, or when to stop - so every agent re-derives that judgment from scratch on every request.

2. One skill per endpoint leaves the agent no better off

The most common failure in this kind of work is writing a skill per API endpoint, which does not capture the multi-call jobs - activating a merchant, explaining a decline, reconciling a payout - that actually span several calls and real judgment points.

3. Autonomy needs to be a decision, not an accident

Without a declared, bounded scope of tools and required human checkpoints per skill, whether an agent acts alone on a sensitive payment action ends up depending on the model's confidence in the moment rather than a decision made deliberately in advance.

The real brief Not "write better prompts" but "build a reviewable, testable skill library that tells agents how payment workflows actually get done correctly - with autonomy bounded before the agent ever runs."

THE SOLUTION

Pfactorial proposed building the library through a repeatable pipeline rather than writing prose against a documentation site, mining high-value, multi-call workflows from the client's own quickstarts, integration code, and support patterns.

CS-035_AI_Agent_Skills_Payments_Platform image 2

Figure 1 - The proposed authoring pipeline: mine workflows, author the skill, evaluate against a sandbox, and feed results back into authoring.

Architectural principles

Mine workflows, not endpoints - high-value skills are identified by reading the workflows the client's own documentation leads with, the call sequences that appear in real integration code, and the questions support teams answer repeatedly - ranked by frequency multiplied by friction.
Every skill is a reviewed, tested artifact - skills live in Git and go through the same review as a change to the underlying API itself, ship with evaluation cases that run against a sandbox account, and declare exactly which tools they may call.
The risk tier is fixed before the agent runs - every tool in the platform's surface is assigned a risk tier at inventory time, and that tier - not the model's confidence - decides whether an agent may act alone on it.
Verify, don't assume - a write is always followed by a read, so a skill proceeds on what the platform actually returned rather than what the call was merely supposed to do.

CAPABILITIES DELIVERED

The proposed skill library's capabilities span authoring, guardrails, evaluation, and safe execution on real payment workflows.

CAPABILITY	WHAT IT DOES
Versioned, Reviewable Skills	Each skill lives in Git with a name, description, scope, procedure, guardrails, and a worked example - reviewed like any other code change.
Declared Tool Contracts	Every skill states exactly which API and MCP tools it may call and at what risk tier, rather than leaving tool selection to runtime judgment.
Guardrails & Failure-Mode Handling	Each skill specifies what it must confirm, must never do, and must escalate, plus the known ways it can go wrong and the recovery for each.
Sandbox-First, Dry-Run Execution	Skills default to test mode, and destructive or bulk workflows produce the exact set of intended calls for approval before anything is sent.
Evaluation in CI	Each skill ships with pytest-based evaluation cases run against a sandbox account in GitHub Actions, so a regression surfaces in CI rather than in a merchant's ledger.
Full Execution Tracing	Every run logs which skill fired, which tools it called, where it stopped for confirmation, and what a human changed - a repeated override is treated as a specification defect to fix in the file.

CS-035_AI_Agent_Skills_Payments_Platform image 3

Figure 2 - How a tool's risk tier, fixed at inventory time, determines whether an agent may act alone.

Design note This is a proposal: the two flagship skills - onboarding and activating a merchant, and diagnosing a failed payment - are specified here as worked examples against generic capability names, with the real versions to be written against the client's actual tool names and error vocabulary once documentation is available.

ENGINEERING FOR SCALE AND RELIABILITY

Several design decisions in the proposal are aimed specifically at keeping agent autonomy safe on a payments platform rather than trusting a model's judgment case by case.

Markdown plus YAML frontmatter, not a bespoke format

the skill format was selected specifically because it is readable by the model and diffable in a pull request - a JSON DSL or a prompt database would be legible to neither reviewers nor the model equally well.

One authored source, packaged per agent

the library is written once and packaged into each target agent's own discovery convention - Claude Code, Codex, and Cursor - rather than rewritten three separate times for three platforms.

No proxy layer between skills and tools

skills call the client's existing MCP server directly, with no proxy or gateway in between and no second place for credentials to live.

Evaluation is the lowest-ceremony option that still works

Python and pytest running against the client's sandbox in GitHub Actions was selected as the lowest-ceremony way to assert what an agent actually did, run on every skill change.

Sensitive fields are redacted by policy, not by convention

the failed-payment diagnosis skill is specified as read-only throughout, with card numbers and personal data redacted in every output, and a retry or refund only ever proposed, never performed, by that skill.

A repeated override is treated as a specification defect

the tracing design specifically calls out that a skill overridden by a human in the same place repeatedly is a signal the skill itself is wrong, to be fixed in the file rather than tolerated as routine human correction.

DELIVERY APPROACH

The proposed engagement is scoped at four weeks and ninety hours across nine workstreams, with the two flagship skills built first end to end so there is something real to react to in week two.

1. Doc audit and workflow shortlist (15 hrs) - catalogue every endpoint and MCP tool, assign a risk tier to each, and produce a ranked shortlist of candidate workflows.

2. Two flagship skills, end to end (30 hrs) - build merchant onboarding and failed-payment diagnosis as complete, tested skills - a coding agent running them unattended against the sandbox, with guardrails firing.

3. Library expansion and guardrail policy (25 hrs) - cover the remaining priority workflows identified in the shortlist, and apply the tier policy consistently across the full tool surface.

4. Evaluation harness and handover (20 hrs) - stand up the evaluation suite running in CI, deliver the authoring guide, and walk the client's team through the library.

RESULTS AND IMPACT

CS-035_AI_Agent_Skills_Payments_Platform image 4

Figure - Key outcomes from this engagement.

As a proposal, the source material does not report delivered accuracy or adoption figures, and none are represented here as such. What the proposal establishes is a concrete four-week, ninety-hour delivery plan across nine workstreams, with two fully specified flagship skills - merchant onboarding and failed-payment diagnosis - as worked examples of the guardrail and verification pattern.

The design's risk-tiering approach - fixed at tool inventory time rather than judged by the model at runtime - gives the client a specific, evaluable answer to the core question a payments platform has to get right: which actions an agent may take alone, and which always require a human, decided once rather than re-derived on every call.

What it enabled commercially

If built as proposed, the skill library is intended to let coding agents complete real payment workflows correctly and consistently, with every action bounded by a declared risk tier and every regression caught in CI - reducing the operational risk of agent-driven automation on a payments platform without slowing down the agents that behave correctly.

WHY PFACTORIAL

This engagement draws on Pfactorial's AI product engineering capability: building reviewable, testable agent instruction libraries for regulated infrastructure, with autonomy bounded by a declared risk tier rather than left to a model's confidence in the moment.

CS-035_AI_Agent_Skills_Payments_Platform image 5

Figure - Service lines this engagement draws on.

Engagement enquiries Pfactorial Technologies works with platform teams evaluating whether coding agents can be trusted with real operational workflows. If you are scoping a project where agent autonomy needs to be bounded and auditable from day one, we are happy to give you an honest read on scope, cost, and risk before anyone commits to anything. · pfactorial.ai

APPENDIX A - TECHNOLOGY STACK

The technology stack underpinning the system, grouped by the layer it serves.