Discovery before implementation
Establish the business baseline, accountable owner, cost of failure, and acceptance contract before choosing models or automation patterns.
For FDEs
Build agents that are ready for production
The Hast FDE community brings together field engineers who understand business, can consult, build with AI, and own deployment and operations. The platform supplies reusable agents, workflows, and governance; FDEs turn field judgment and production evidence into shared practice.
See the enterprise engagement modelProfessional standard
Measure an FDE by verified business outcomes
Mature field engineers preserve accountability across discovery, design, implementation, launch, and operations. They start with the simplest reliable solution and introduce agent autonomy only when the job genuinely requires open-ended judgment.
Evidence before narrative
Use representative samples, fixed evaluations, operational measures, and user behavior. A smooth demo alone cannot prove production reliability.
Maintainability is delivery
Design identity, access, audit, rollback, runbooks, change control, and enterprise takeover before launch.
Capability model
Strong FDEs work across six contexts at once
FDEs can use the wider team to fill specialist gaps. They must recognize those gaps, bring the right owners together, and keep cross-boundary decisions explicit.
Technical capability architecture
Six layers keep an agent system from becoming an ungovernable black box
Each layer answers a different question and produces a reviewable artifact. The model is one component; business semantics, action boundaries, identity governance, and continuous feedback determine production results together.
01
Business workflow and acceptance criteria
Why does the work exist, and what counts as done?
Define triggers, inputs, outputs, owners, deadlines, baselines, success measures, exclusions, zero-tolerance failures, and human decisions. Without this layer, optimization has no direction and evaluation becomes opinion.
Required output
Workflow brief, baseline, responsibility matrix, acceptance and stop conditions
02
Enterprise context and semantics
How does the agent understand the organization's objects, relationships, and rules?
Map customers, contracts, orders, events, metrics, and permissions into shared semantics. An ontology or graph links data, logic, action, and security to support explainable, executable business decisions.
Required output
Domain model, data lineage, knowledge sources, rules, and freshness constraints
03
Agent and workflow runtime
Which steps are fixed, and which permit autonomous judgment?
Prefer composable, observable workflows. Use agents only when steps cannot be predetermined and the model has meaningful feedback. Define routing, parallelism, handoffs, manager agents, state, termination, retries, and budgets.
Required output
Orchestration graph, state model, context strategy, termination and degradation rules
04
Tools, actions, and integration
What may the agent do, and what happens when a system fails?
Define typed inputs, outputs, preconditions, idempotency, timeouts, retries, and compensation for MCP, APIs, Skills, and Plugins. Grade read versus write actions; require preview, approval, limits, or dual control for irreversible operations.
Required output
Tool interfaces, system ownership, error taxonomy, compensation, and test fixtures
05
Identity, access, and governance
Who acted under which identity, against which resource?
Give every user, agent, and service a traceable identity with least privilege; separate development, test, and production. Record provenance, calls, approvals, results, and versions, with explicit policy for sensitive data and high-risk writes.
Required output
Identity model, access matrix, approval policy, audit, and retention rules
06
Evaluation, observability, and operations
How do we know the system remains correct and valuable?
Offline evaluations cover representative, edge, and deliberately difficult cases. Online telemetry joins business outcomes, task quality, tool reliability, safety, latency, and cost. Production failures become regression cases before controlled re-release.
Required output
Frozen evaluation set, traces and metrics, alerts, runbook, change, and review records
Platform support
Hast gives recurring infrastructure to the platform and preserves field judgment for the FDE
The platform provides shared task execution, connectivity, access, and operations so projects avoid rebuilding them. FDEs still own customer discovery and field judgment, and every component follows the project's agreement and enterprise boundary.
Build and orchestrate
Hast Agent, Task Agent API, Agent Server, schedules, events, webhooks, manager agents, and multi-agent coordination compose short tasks and long-running workflows.
Connect and extend
MCP, Skills, Plugins, browsers, code, and enterprise APIs connect data and actions. The FDE still defines tool contracts, ownership, and failure compensation.
Control production
Workspace isolation, identity, access, approvals, audit, secret boundaries, runtime traces, rollback, and human takeover create executable controls for risky actions.
Improve continuously
Link evaluations, online events, cost, and user feedback to versions. Turn recurring field problems into maintained platform capabilities.
Delivery standard
A maintainable project leaves at least seven asset classes
Code is only one. Without any of these, a new engineer, enterprise team, or on-call operator cannot take over safely.
Workflow brief
Objective, main path, exceptions, baseline, measures, exclusions, and stop conditions.
Architecture decision records
Key choices, alternatives, tradeoffs, assumptions, owners, and reevaluation triggers.
Data and access map
Lineage, sensitivity, identity, least privilege, retention, approval, and environment boundaries.
Tool and failure contracts
Inputs, outputs, timeout, retries, idempotency, compensation, irreversible actions, and takeover.
Fixed evaluation set
Representative, edge, and failure cases; scoring method, thresholds, and version.
Runbooks and incident record
Telemetry, alerts, diagnosis, escalation, rollback, recovery, reviews, and known limits.
Sanitized reusable assets
Patterns, connectors, fixtures, and lessons within customer permission and IP boundaries—never raw customer data.
Community development
Contributor levels follow verified responsibility
Progress is based on sustained contribution, review quality, delivery evidence, and help to others. Technical skill, customer trust, and community stewardship all matter.
01
Member
Entry evidence
Completes foundation training and safety standards; can explain the FDE method and join case discussions.
Responsibility
Protect customer boundaries, ask contextual questions, and complete a Good First Field Issue.
02
Contributor
Entry evidence
Has an accepted evaluation, connector, runbook, pattern, or sanitized field lesson.
Responsibility
Maintain the contribution, answer reviews, and document applicability and known limits.
03
Reviewer
Entry evidence
Consistently reviews business contracts, architecture, access, evaluation, and operational risk with actionable feedback.
Responsibility
Guard quality, mentor contributors, and prevent unsupported technical preference from becoming standard.
04
Field Lead
Entry evidence
Has led at least one controlled production engagement validated by the enterprise owner and technical review.
Responsibility
Own scope, delivery quality, customer communication, launch, and incident response.
05
Maintainer
Entry evidence
Sustains a shared capability area, handles cross-project feedback, and grows new Reviewers and Field Leads.
Responsibility
Maintain roadmap and standards; resolve design disputes; coordinate releases, security response, and governance.
Working mechanisms
Turn field experience into reviewable, teachable, reusable capability
The community protects customer secrets and records failures as carefully as successes. A precisely described failure mode, repeatable evaluation, or runbook that prevents the next incident can be highly valuable.
Architecture Clinic
Small-group review of the business contract, state ownership, semantics, orchestration, access, and failure isolation; conclusions enter ADRs.
Case & Incident Review
Review delivery and incidents through timelines, evidence, and system conditions; improve mechanisms instead of assigning blame.
Good First Field Issue
Bounded entry tasks for documentation gaps, fixtures, evaluation cases, small connectors, and runbook improvements.
Shadow Delivery
Members observe discovery, solution review, acceptance, and operations with a Field Lead before taking independent customer ownership.
Office Hours & Maintainer Rotation
Regular help for blockers; rotating maintainers track recurring feedback, stale assets, and capabilities ready for the platform.
Customer trust
Do not share customer material by default; reuse requires permission, sanitization, and boundary review
Community learning must not create customer risk. Raw data, credentials, contracts, internal architecture, private metrics, and identifiable incident details never belong in public material or personal devices.
Never enter community assets
- Raw customer data, prompts, access tokens, secrets, or production logs
- Private customer names, contracts, pricing, metrics, vulnerabilities, or incident details
- Samples, screenshots, or topology that can identify a person, company, or system
- Code, models, documents, or third-party IP copied beyond project authorization
Required before reuse
- Confirm customer permission, contract limits, IP ownership, and applicable license
- Remove identifiers, business fingerprints, credentials, real values, and private topology
- Reproduce with synthetic or public data and have a second person review sanitization
- Document applicability, failure boundaries, maintainer, and expiration review date
FDE community FAQ
Who should join, what counts as contribution, and how customer work relates to the platform.
Who is a good fit for Hast FDE?
People willing to work with both business ambiguity and engineering detail: observe real work, communicate across roles, build and integrate quickly, and stay accountable to evaluation, safety, rollout, and operations. Nobody needs every specialty on day one, but they must identify gaps honestly and seek review.
Must a contribution be a large open-source codebase?
Valuable contributions include failure cases, evaluation sets, architecture patterns, connectors, tool notes, fixtures, runbooks, training, and sanitized incident reviews. Every contribution states applicability, limitations, maintenance owner, and validation evidence.
Will the community turn every project into one template?
No. Productization is for capabilities that recur across projects with stable boundaries. Customer semantics, organizational ownership, and critical workflows remain project-specific. Premature abstraction hides real differences; copying project code creates permanent forks.
Does community membership grant customer production access?
Community membership includes no customer production access. Every project and customer separately approves access by least privilege, duration, environment, and audit requirement; access is revoked when the role or engagement ends.
Bring a real problem—and leave the practice more reusable
If you will own business discovery, engineering delivery, production safety, and long-term operations together, tell us about your domain, one complex delivery, and the capability you want to maintain for the community.