About the Agent Integration Playbook

Updated 2026-08-19

The Agent Integration Playbook is a free reference on giving AI agents access to real systems — mailboxes, chat workspaces, repositories, document stores, databases, and tool servers — without handing over more than the job needs. 18 guides, split acrossConnect, Govern, andFail. No gate, no signup, no email capture.

This page exists because the library asks you to act on specific strings. A guide tells you which OAuth scope to request, which error means a token was revoked, and which quota you are about to exhaust. A wrong literal costs you an incident, so you are owed the answer to who writes this, what the writing is held to, what a machine checks before it ships, and what to do when you find something wrong.

The standard every guide is held to

Four rules. Every guide clears all four before it merges.

A second reviewer fact-checks it against primary sources. Not a proofread. The reviewer opens the cited page and reads the sentence being cited, because the common failure is a draft that widens its own source. One did exactly that here: the vendor's page said an exemption applied to brand verification, and the draft said it applied to verification. Both sentences read fine. Only one of them is true. A claim in a guide may not be broader than the page it cites.

Literals are verified, not recalled. Scope strings, endpoint paths, header names, error codes, and quota numbers are read off the vendor's current documentation while the guide is being written. Recalling a scope name that appears in a hundred blog posts is how a guide inherits a value the vendor changed two years ago, and secondary sources do not get corrected when it happens. Anything numeric comes from the vendor's own quota or limits page.

Published code is executed, not just compiled. Compiling proves syntax. Running proves behaviour, and running the pieces composed in the order they are published proves something neither of the other two do. A sample here once passed review with an error-sanitising wrapper and a retry layer that had each been verified alone; composed as published, the retry sat inside and returned before the sanitiser ever saw the exception, so the secret it was written to hide went straight to the model. A control is tested in the position it ships in, against a payload where the thing that should not escape is unmistakable if it does.

What could not be sourced is disclaimed in place. When a response shape or an error code is real behaviour that no vendor page documents, the guide says so in the sentence that uses it and branches its example on something that is documented. The claim is not quietly dropped, and it is not softened into a sentence that sounds sourced. You get to see the seam.

What the build refuses to ship

Those four rules need a person. The rules below do not — npm run verify runs on every change and fails on any one of them:

• Frontmatter that breaks the schema. A title over 60 characters, a meta description outside 140 to 160 characters inclusive, fewer than two keywords, fewer than three related guides, or an updated value that is not a quotedYYYY-MM-DD string.
• An internal link that does not resolve. Every relative link to a page on every built page — an asset like /rss.xml is not one — is checked against the routes the build actually generated, not against a list someone maintains by hand.
• A page nothing links to. An orphan fails, and so does any page carrying fewer than three distinct internal links — including this one.
• A code sample that has drifted. Every Python file underexamples/ is compiled, and every one whose imports resolve is then imported in its own subprocess, which catches a sample calling a name a sibling file stopped exporting. CI installs the samples' declared dependencies so the coupled ones are covered rather than passed over. What still cannot be imported is skipped by name with a reason, and the skips are counted in the run output — today that is the samples using the published Agentic Fabriq SDK, which does not yet expose the modules they import, plus two standalone scripts that read a credential at module scope. So coverage is a number you can read rather than one you assume. Every import in every sample is also read statically and checked against a declared allowlist, so a sample cannot depend on a package nobody agreed to, and anything touching the Agentic Fabriq SDK is checked against the published surface, so it cannot call a method that does not exist.
• An SEO invariant broken on any built page. The suite parses every generated HTML file and asserts a unique title of at most 60 characters, a unique meta description of 140 to 160, an absolute canonical URL, Open Graph and Twitter tags, parseable JSON-LD, exactly one h1, and no client-side JavaScript.

The review bar is written down in CONTRIBUTING.md and the checks themselves are in the repository. Read them rather than taking this page's word for it.

What goes stale first

Everything here has a shelf life and some of it is short. The most perishable material, in roughly the order it moves:

• Protocol revisions. MCP serversdescribes a protocol that is versioned by date and revised on its own schedule. Transport and authorization are the parts that have moved.
• Pinned framework versions.Agent frameworks names specific releases, and agent frameworks rename a decorator or move a module in a minor version.
• Vendor scope strings and quota numbers. Slack, Google, and GitHub all split scopes, rename them, and revise rate limits. That reachesleast privilege and every provider guide under Connect.
• Error codes and revocation behaviour. What a provider returns when a grant is withdrawn is the literal most likely to be described from memory anywhere on the internet, which is exactly why it is worth re-reading.

Every guide carries an Updated date under its title, and that same date is in the page'sArticle structured data as dateModified. Read it as the date the guide's literals were last checked against a vendor page.

If a literal here disagrees with the vendor's current documentation, the vendor is right and this page is wrong. Use their value, then tell us — a guide that is confidently wrong about a scope string is worse than one that never covered the provider.

Who publishes this

The library is published by Agentic Fabriq, which sells a control layer for agent identity, permissions, credential vaulting, and audit. That is a commercial interest in the subject matter, so here is how it is kept out of the way.

The body of every guide is vendor-neutral and teaches the do-it-yourself path in full, including what that path costs to build and operate. Agentic Fabriq gets one clearly-labelled section per guide — always the eighth, always titled "Doing this at scale" — and is kept out of the TL;DR entirely, so a summary can never carry a pitch. Two to four links to the product per guide, total; where one appears outside that section it is because the sentence it sits in needed it. Strip the labelled section out and the guide still answers the question you arrived with. That is the test each one is written to pass, and it is the test to hold this page to.

Reporting an error

Open an issue on the repository's issue tracker. The most useful report names the page, quotes the literal, and links the vendor page that contradicts it; with those three things a correction takes minutes. Corrections are the most valuable contribution this project receives, ahead of new guides.

Fixes are made in the open. The site is built from a public repository, so every correction is a commit with a message and a diff, and you can read what a page used to say and when it changed. Nothing is edited silently. When a claim turns out to be wrong, the fix is applied everywhere it was restated — the TL;DR, the checklist, and the FAQ entries included — because a corrected body with a stale checklist twenty lines below it will have a reader reimplement the bug the correction just removed.

Licensing

Prose is licensed CC BY 4.0: use it, adapt it, republish it commercially, with credit to Agentic Fabriq and a link back to this site. Code — everything under examples/, the site source, and the check scripts — is Apache-2.0, so you can lift a sample into a product without asking. Both licences are in the repository. The external documentation each guide links is the vendor's, under whatever terms the vendor sets.