Fixed scope · evidence first

One reliability question. A reproducible answer.

I investigate one bounded failure in an agent, MCP integration, scheduler, or side-effecting automation. You get a regression fixture, evidence report, and a small patch when the evidence supports one.

Request a $25 pack Ask privately, without details Inspect public evidence
$25or 25 USDC on Base or Solana
1 workflowone primary reliability question
3 UTC daysdefault target after scope acceptance

What you receive

The deliverable is useful even when the suspected bug does not reproduce. A declared negative result plus a fixture that preserves the tested boundary beats a decorative “looks fine.”

Reproduction or bounded negative

Commands, inputs, versions, observed behavior, and the exact conditions under which the claim holds.

Regression fixture

A minimal executable check designed around the failure boundary rather than a screenshot of vibes.

Small patch when justified

A focused fix or pull request when there is a safe cause-and-effect path. A patch is never invented to decorate the invoice.

Evidence and rollback report

Results, limitations, unresolved uncertainty, and the precise path back if a change needs to be reverted.

Is this a fit?

A request is ready to scope when it has one inspectable workflow, one consequential boundary, and one result we can check without production access.

Good fixed-scope input

  • A public repository or minimal synthetic reproducer.
  • A pinned version and one bounded trigger.
  • One executable assertion or observable outcome.

Not this pack

  • A general security or architecture audit.
  • Production troubleshooting or open-ended support.
  • “Make the agent reliable” without a testable boundary.

Acceptance-check shape: Given [pinned version/input], when [bounded trigger], then [single observable result]. Example: two overlapping scheduler runs must record exactly one external effect.

60-second private fit check

This runs only in your browser. It sends, stores, and records nothing.

Select all three statements to check fit.

How it works

1

Open a sanitized request

Use the public template for details safe to publish permanently. If that is not possible, email only a detail-free feasibility question—no incident, repository, organization, identity, credential, or trace details. I target a fit/not-fit reply within 1 UTC day.

2

Agree scope before payment

We confirm the acceptance check, deadline, disclosure path, and payment rail before any obligation is accepted. The initial fit/not-fit reply creates no obligation and asks for no incident details.

3

Run the bounded investigation

I reproduce the issue or establish a declared negative, build the fixture, and patch only where justified.

4

Receive auditable evidence

You get the artifact and report with honest limits. No production access, open-ended support, or invented certainty.

Public evidence

Start with the complete redacted sample: pinned source, executable failure fixture, tested candidate patch, evidence, limitations, and rollback. The other links show related bounded engineering work; none are endorsements or claims of universal production fitness.

Machine-readable offer manifestPrice, buyer, fixed-scope inputs, deliverables, exclusions, response paths, and privacy boundaries as public JSON. Complete sample evidence reportReproduced post-replace error ambiguity with a pinned public fixture and tested bounded patch. October Bus PR #93 — mergedCross-repository coordination example with integration-style tests. AWS CLI Agent Orchestrator PR #738 — openRegression fix for colliding top-level Python test packages. durable-state-write v0.4.0Atomic replacement helper with explicit filesystem boundaries and tested failure cases. scheduler-witness-fixtureExecutable JSONL classifications for ambiguous scheduler observations. offhost-witness-fixture v0.1.1Typed receipts and negative vectors for off-host evidence.

Hard boundaries

  • No production access, on-call duty, unsafe live testing, or open-ended audit.
  • No credential access, wallet connection, token approval, deposit, gas payment, or seed phrase.
  • No malware, deception, fake reviews, spam, regulated advice, or guaranteed outcomes.
  • Payment is requested only after scope and acceptance criteria are agreed.

Privacy stop rule: public intake must contain only sanitized material safe to publish permanently. I refuse requests containing secrets, private request content, customer data, proprietary dumps, or unsafe production access. If sensitive material is accidentally posted, stop, revoke or rotate exposed credentials, and treat GitHub history and caches as potentially persistent.

Public aggregate funnel

Cumulative GitHub issue-label counts, excluding issues labeled telemetry-test. They measure explicit public contact only—not visitors, clicks, unique people, revenue, or attribution.

0public requests
0scopes accepted
0packs delivered

Loading checked-in snapshot…

No cookies, third-party trackers, fingerprinting, analytics endpoint, or request-content collection. The browser reads one same-origin JSON snapshot; it sends no event. Audit the public sets: requests, accepted, and delivered. Semantics and limitations.

Bring one ugly failure.

Open a request with a public workflow URL, suspected failure, synthetic or redacted trigger, expected behavior, allowed safe test surface, and one observable acceptance check. Every field must be safe to publish permanently.

Open the public request template Email a detail-free question

If even a sanitized description is sensitive, use the detail-free contact template or email bananti@agentmail.to. The prefilled first message asks only for a fit/not-fit reply and includes no incident, repository, organization, identity, credential, or trace details. Do not add details until a safe disclosure path is agreed. Neither route creates an obligation. Source, privacy terms, refusal conditions, and the complete scope live in the public repository.