AI forward deployed engineer for integrations

Your product, joined to their code.

Attune plans the integration with your team and your customer's team. It builds the change in a sandbox and checks it. Their owner authorizes each release.

Scroll to begin, or choose a step.

Access

You request access. Their owner grants it.

Your customer decides which repository files Attune can use. Their code stays under their control.

One integration

Each owner keeps their part.

Attune brings your product knowledge and the customer's requirements into one implementation brief. Both teams review the plan before work starts.

Brief and review

Both teams review one brief.

1 · Draft v1

Review the requirements, affected files, proposed changes and acceptance checks before implementation.

2 · Discussion

Ask Attune about technical decisions. Discuss the impact with both teams.

3 · Proposed change

Review amendments and confirm the updated brief before implementation continues.

Sandbox

Attune builds the change in a private copy.

Attune implements the agreed change in an isolated workspace. Your team can review the code and test results before release.

Checks

Acceptance checks run on one exact revision.

See which requirements passed, which failed, and what still needs attention. Each result identifies the code revision and environment that were tested.

Release

Your customer controls what reaches production.

Review the proposed release, its test evidence and the target environment. The customer's authorized owner decides whether to proceed.

Acme Studiosyour product

Attuneshared brief and sandbox

Fernhill Labstheir code and release

Fernhill Labsrelease

Product docsAcme approves what Attune reads

POST /v2/assets
asset.rendered

catalog-serviceTheir repository

upload.py
webhooks.py
invoices.py

AccessTheir owner grants, per file BriefBoth teams confirm SandboxA private copy ChecksC1 to C4, set in the brief ReleaseTheir owner authorizes

Acme Studios approves what Attune learns.

Only their owner grants code access, file by file.

Attune builds in a private sandbox and runs the acceptance checks.

Their environment owner authorizes each release.

Integrations Fernhill Labs Assets sync

Maya R. · Acme Studios

Access

Current operation: read and model processing for the Assets sync brief.

fernhill/catalog-service at 4c1e9a7

Local repository in this preview. The GitHub connection is built; its live test is pending.

catalog/assets/upload.pySends product images to AcmeWithheld
catalog/assets/webhooks.pyReceives finished renditionsWithheld
billing/invoices.pyInvoice records, not neededWithheld

Select files, then request access. Only the Fernhill Labs owner can grant it.

Who controls this code

Fernhill Labs owner: Grants or withdraws access, per file, for this brief.
Acme Studios (you): Requests access. Cannot grant it.
Attune: Reads only granted files, at one commit.

Assets sync brief v1

v1 confirmed by both teams.

Requirements

R1 Upload each new product image to Acme Studios.
R2 Store the rendition when Acme's webhook arrives.
R3 A retried upload never makes a second rendition.

Scope

Changes upload.py, webhooks.py and a new acme_client.py in catalog/assets/. Out of scope: billing/.

Tasks

T1 Add the Acme Studios client, acme_client.py.
T2 Send each upload with a new idempotency key.Use one idempotency key per upload attempt. Store it before the call.
T3 Verify the webhook signature.

Acceptance checks · set before work

C1 Upload returns 201
C2 Duplicate webhook is ignored
C3 A retry makes one rendition
C4 A bad signature is rejected

Rough estimate

5 to 8 engineering hours for T1 to T3 · Attune's estimate, not a commitment. It assumes Acme's documented retry rules.

Confirmations

Fernhill Labs confirmed requirements · v1
Acme Studios confirmed feasibility · v1
v1 confirmed by both teams

Integrations Fernhill Labs Assets sync

Maya R. · Acme Studios

Sandbox

Private copy of fernhill/catalog-service at 4c1e9a7. Built against brief v1.

Attempts

Changed files · attempt 2

May change granted files, new files in catalog/assets/

May not change billing/, deploy settings, secrets. No network.

catalog/assets/upload.pyAttempt 2 · 9f3c2e1 · changed lines only

1def on_new_image(image):2-    queue_for_later(image)3+    key = uuid.uuid4().hex  # T2 v1: a new key on each send4+    result = acme_client.send_upload(image, key)5+    store.save_asset_id(image.id, result["asset_id"])

T2 v1: a new key on each send. A retry after a timeout sends a second key. C3 shows the effect.

No grant for upload.py and webhooks.py in this session: this shows the work a grant makes possible. Preview: scripted code, and +/− counts the lines shown. Nothing runs on a real repository.

Integrations Fernhill Labs Assets sync

Maya R. · Acme Studios

Checks

Revision 9f3c2e1 · attempt 2 · brief v1

Acceptance checks · set in the brief before work, unchanged

Check	Result on `9f3c2e1`	Evidence
C1 Upload returns 201	Not run
C2 Duplicate webhook is ignored	Not run
C3 A retry makes one rendition	Not run
C4 A bad signature is rejected	Not run

Not run on 9f3c2e1. Results from 5e81c0a do not apply to it.

Preview: a scripted result. No test runs here.

Repair attempts

Attempt 1 · 5e81c0aC2 failed. Attune sent it back for repair.
Attempt 2 · 9f3c2e1Current revision. The same four acceptance checks apply.

Integrations Fernhill Labs Assets sync

Maya R. · Acme Studios

Release

Target: fernhill/catalog-service to staging · revision 9f3c2e1

Change Attempt 2, brief v1: 3 files, +28 −2 lines shown · Inspect the change

Evidence Acceptance checks have not run on 9f3c2e1. Open the checks

1 · Access grantDana K., Fernhill Labs repository owner

Not granted in this session. Go to Access
2 · Brief confirmation · v1Each team confirms the same version

Fernhill Labs confirmed v1
Acme Studios confirmed v1
3 · Release authorizationBy their environment owner

Customer owner view · Dana K.
4 · Customer acceptanceA separate decision by Fernhill Labs

Customer view · Sam O. · after step 3

Authorization waits for the owner's grant of upload.py and webhooks.py; a run of the acceptance checks on 9f3c2e1.

Acme Studios cannot grant or authorize, and Attune cannot approve its own work. Preview: nothing deploys or contacts GitHub.

Where Attune fits

One method for many integration types.

Each story shows what their owner grants, one acceptance check set in the brief, and who authorizes the release.

Illustrations of integration types. Today Attune runs on Python services in local repositories, with synthetic companies and data.

Payments in their billing app

Illustration

InvoiceAmount (USD)Status

INV-1042$630.00Paid

INV-1043$84.20Open

POST /v1/payments Idempotency-Key inv-1042-a1

201 succeeded · invoice marked paid

Second click · same key · no second payment

Their owner grants: billing/payments.py · read
Acceptance check: A double submit makes one payment.
Release authorized by: Their environment owner

Telemetry from their services

Illustration

orders-apisending

checkout-websending

http.server.duration http.server.requests

p95 latency · orders-api412 ms

Test alert fired and cleared · readback checked

Their owner grants: services/*/otel.yaml · read
Acceptance check: Each named service sends the agreed metrics.
Release authorized by: Their platform owner

Calls that update their CRM

Illustration

Call summary

Customer asks for a quote by Friday.

Action create_follow_up_task

TaskDueOwner

Send quoteFriJ. Ruiz

Fields mapped as their CRM admin approved

Their owner grants: crm_sync/tasks.py · read
Acceptance check: One call makes one task with the agreed fields.
Release authorized by: Their CRM admin

Order status between two systems

Illustration

OrderTheir system

ord_77Packed

PUT /v1/orders/ord_77 status packed

Your dashboard shows Packed

Retry after a timeout · one update, not two

Their owner grants: orders/events.py · read
Acceptance check: A status change reaches your API once.
Release authorized by: Their environment owner

Only owner-granted files reach Attune or a model.
Verified in local runs
Acceptance checks are set before any code is written.
Verified in local runs
Acceptance checks run in isolated containers with restricted network access.
Verified in local runs (local development sandbox)
Confirmations bind to one exact brief version.
Verified in local runs
A person authorizes each exact release.
Verified in local runs (synthetic release target)
Approved text goes to Anthropic's Claude. Your own model key is planned.
Planned (your own model key)

Read Security and access for every statement and its limits.

Your integration

Bring one integration your customers struggle to ship.

Talk through your product, your customers' systems and the engineering work between them.

A good first integration

Each new customer needs code in its own systems before your product works.
Your engineers repeat discovery and planning for each customer.
Your customers need control over access to their code.
A named owner on each side can review and approve.

Attune Let's talk

30-minute introductory call

Start with your integration.

Choose a time to discuss where Attune could fit and what the next step should be.

Your product and your customer's requirements
The systems, constraints and access boundaries
The technical fit and next steps

Choose a time

Scheduling with Calendly.

Your product, joined to their code.

You request access. Their owner grants it.

Each owner keeps their part.

Both teams review one brief.

Attune builds the change in a private copy.

Acceptance checks run on one exact revision.

Your customer controls what reaches production.

Access

Who controls this code

Acme Studios asks for access

Assets sync brief v1

Requirements

Scope

Tasks

Acceptance checks · set before work

Rough estimate

Confirmations

Sandbox

Checks

Release

One method for many integration types.

Bring one integration your customers struggle to ship.

A good first integration

Start with your integration.