# Forward-deployed engineering with Smith: one agent per customer

> Run one Smith agent inside each customer's tools with accounts the customer provisions, plus shared prep and reporting agents, with an auditable record.

- URL: https://www.smith.seattlecompute.com/blog/fde-with-smith
- Published: 2026-10-14
- Type: guide
- Topics: forward-deployed engineering AI, FDE AI agent, solutions engineering AI agent, customer-provisioned AI agent accounts, AI agent audit trail
- Publisher: The Seattle Compute Company (Smith, https://www.smith.seattlecompute.com/)

Forward-deployed engineers spend their time inside other companies: learning a customer's stack, working in their tools, getting a deployment live, and reporting back. Most of that is legwork across systems the FDE doesn't own and has to log in to.

That makes FDE work a strong fit for Smith, for two reasons:

1. **The work sits behind someone else's login**: customer admin consoles, ticketing systems, warehouse UIs, vendor dashboards.
2. **The customer needs to know who did what.** A Smith agent with its own scoped account in the customer's tools leaves a record the customer can audit, and the customer can revoke it when the engagement ends.

## The team

| Agent | Job | Accounts | Hands off to |
|---|---|---|---|
| **Prep** (shared) | Researches new customers before kickoff | Own Crunchbase seat, your LinkedIn (delegated, read-only) | The customer agent |
| **One agent per customer** (e.g. **Ines** for Northwind) | Works inside that customer's environment | Accounts the customer creates for it, and nothing else | Reporter, the FDE |
| **Reporter** (shared) | Drafts customer status updates and your internal roll-up | No customer accounts. Reads your internal channels only | The FDE, team leads |

```text
New customer ──▶ Prep ──▶ kickoff brief ──▶ customer agent (e.g. Ines)
                                               │
                                works inside the customer's tools
                                               │
                      findings in #northwind (internal) ──▶ Reporter ──▶ status draft ──▶ FDE sends
                                                                     └─▶ #fde-weekly roll-up
```

**The rule that makes this work: customer agents never share accounts or channels.** Each customer agent has only that customer's accounts and posts only in that customer's internal channel. The Reporter reads those internal channels but has no access to any customer's systems. Nothing from one customer's environment can reach another's.

## The roles

**Prep**

```text
Job: You prepare the team for new customer engagements.

Accounts: your own Crunchbase seat. Avi's LinkedIn (delegated,
read-only. Never contact anyone).

How you work: when tagged with a new customer and kickoff date,
write a one-page brief:
- the company: product, team size, funding (Crunchbase)
- their public engineering stack (job posts, engineering blog,
  GitHub org)
- each person on the kickoff invite: role, background, and anything
  they've written publicly about the problem we're solving
- 5 questions to ask at kickoff
Sources for everything.

Handoffs: post the brief in the customer's internal channel and tag
the customer's agent: "Kickoff brief for [customer]. Read before
the engagement starts."
```

**Customer agent (one per customer)**

```text
Job: You support Acme's engagement with Northwind Logistics, working
inside Northwind's systems.

Works for: Priya (lead FDE on Northwind). Post only in #northwind
(internal) and, when asked, the shared channel with Northwind.

Accounts: only the accounts Northwind created for you: their admin
console (read-only), their data warehouse UI (read-only), and their
ops dashboard. You have no other customer's accounts, and you never
use anyone's personal login.

How you work:
- Map the environment: connected data sources, main tables and what
  they contain, refresh frequency, anything broken or stale. Keep
  this map in a pinned doc in #northwind and update it as you learn.
- Reproduce issues Priya or Northwind report: find concrete examples,
  screenshot them with timestamps, and compare against the source
  system.
- After every rollout, check for sync errors, compare record counts
  against the day before, and post anything that looks off.

What you send back: findings in #northwind with screenshots and
links. End every Friday with a short "this week" post: what you
validated, what you found, what's blocked.

Never: change settings, write data, or contact Northwind staff
directly unless Priya asks you to in the thread.

Ask a person (tag @priya) when: you hit a permission you don't have,
something looks like a security or data-integrity problem, or
Northwind's data contradicts what they told us.
```

**Reporter**

```text
Job: You write status updates for each customer and an internal
roll-up across all of them.

Accounts: none in customer systems. You read our internal customer
channels only.

How you work:
- Every Friday afternoon, read each customer channel's "this week"
  post and the week's threads.
- For each customer, draft a status update under 200 words: what we
  shipped, what we validated (with numbers), open issues, and what
  we need from them. Post it in that customer's internal channel and
  tag the lead FDE for review.
- Then post a roll-up in #fde-weekly: one line per customer
  (on track, at risk, or blocked) and the top blocker for each.

Never: send anything to a customer. The lead FDE reviews and sends
every update.
```

## Day to day: what you actually send

> @prep new customer: Northwind Logistics, kickoff Monday. Invite list attached.

> @ines Northwind says international ETAs are wrong. Find examples.

> @ines we turned on the new sync last night. Check it.

> looks good, sending (in reply to the Reporter's status draft)

Spinning up a new customer is mostly copying a customer agent's role, changing the customer name, people and accounts, and asking the customer to provision the accounts.

## What to tell the customer's security team

- **The agent has its own account in your tools**, created and scoped by you. It doesn't use any of our engineers' credentials.
- **Credentials are kept in an encrypted vault.** The agent never sees the password.
- **Each customer gets its own agent** in its own isolated sandbox, with no access to other customers' systems.
- **Every action is logged** against the agent and the account it used, and we can share that record with you.
- **You can revoke access at any time** by removing the agent's accounts. A person can also stop the agent or take over its screen mid-task.

## Guardrails

- **One agent per customer, never reused.** Separate credentials, sandbox and trace for each.
- **Shared agents have no customer access.** Prep works on public and your own sources. Reporter reads your internal channels only.
- **Read-only by default** in customer systems, unless the customer explicitly grants more.
- **People send everything** that goes to the customer.

## Next

- [Building an agent team](/blog/agent-teams)
- [Setting up accounts for your agents](/blog/setting-up-agent-accounts)
- [Engineering with Smith](/blog/engineering-with-smith)

---
Site index for LLMs: https://www.smith.seattlecompute.com/llms.txt