seed1

A non-human account used by a service, connector, or agent to access customer systems under controlled permissions. Should follow least privilege.

The line an agent, service, or user cannot cross — enforced through access controls, tool scopes, policy, or runtime checks.

The access-control design that determines what users, agents, tools, and services can see or do in the deployment. Needs to be reviewed before enabling any write actions.

The set of APIs, data objects, credentials, events, permissions, and systems touched by an integration. FDEs try to minimize this for the first launch.

The plan for connecting systems, data, identity, tools, and workflows so the deployed capability works reliably — and keeps working after the FDE leaves.

A reusable architecture for a class of deployments: system boundaries, integrations, security patterns, and common variants. Built from a real deployment, not invented from scratch.

A deployment motion where hands-on FDE work is necessary because the customer environment, workflow, or value proposition is too complex for self-serve.

A deployment motion where the product is self-serve or template-driven enough that less field engineering is required per customer. What FDE teams push toward after proving a pattern.

The first narrow but valuable workflow that creates trust, proves value, and opens the door to broader deployment. Should be painful to the customer, easy to measure, and winnable.

A high-touch deployment where the field team provides extra hands-on support, customization, and coordination — usually for a strategic or complex customer.

An agentic workflow built for real users and real consequences: evals, guardrails, monitoring, permissions, and operational ownership all in place. Typically has fewer tools than the demo.

An agent that is evaluated, observable, permissioned, supportable, and integrated into a real workflow with clear human handoffs — not just a prompt that works most of the time.

An AI application hardened for real use — governed data access, evals, monitoring, support, permissions, and a clear workflow owner. Not the thing that impressed in the demo.

A durable record of what happened, who or what did it, what data was used, and when — required before any agent touches regulated records.

A UI control that triggers a real workflow step: approval, escalation, submission, write-back, or agent tool use.

An operation that changes data or state in a customer system — requires stricter permissions, validation, and audit logging than read actions. Always treated with extra scrutiny.

Writing an approved output, decision, or update from the deployed application back into a customer system of record. Usually gated behind human approval.

A pilot where the system can retrieve, reason, and recommend but cannot modify any customer systems. Lets users build trust before the agent takes actions.

A test execution that exercises the full workflow without committing production changes.

Running a new workflow, model, or agent in parallel with the current process without letting it take production actions. Used to compare outputs against human decisions before trusting the system with real consequences.