Corey James- 24agent tools on the Graph API
- 24 hoursMessenger response window the inbox works inside
A module built on the Graph API
In FAFOHive, agents managing a business Page needed to publish every kind of media, answer comments and messages inside Meta's rules, read insights, and undo anything they created. The social-publishing provider I had covered posting and little else, so I built an in-house module directly on Meta's Graph API and held it to my tool standard.
A rate budget in every result
Every result carries the Graph usage headers for the business use case, the app and the Page, so an agent can see how much of its rate budget remains before it hits a throttle. The inbound poller skips a run when usage is high.
Guarded writes
A local ledger lists everything the app created. It can refuse a delete but never authorise one on its own; Graph's own answer to which app created an object remains the authority. That keeps objects created before the ledger existed deletable and stops a stale ledger row from authorising a mistake.
What testing against Graph taught
Graph's actual semantics came from tests against the real platform, and each finding became a fix with a test.
Webhooks and the acceptance bar
Inbound webhooks are checked with an HMAC over the raw body and rejected on any mismatch, and events flow into the same signed event feed as the other social modules.
I set one acceptance bar for it: manage any post entirely through the agent tools. The acceptance test did exactly that, against an unpublished page, while a guard counted every HTTP request made outside a tool body.
The gateway these tools sit behind is in Agents with real tools and no keys. This is client and adapter engineering on Meta's platform; the Graph API and its rules are Meta's.
I learn a platform's real behaviour by exercising it end to end.