How we build an AI employee for go-to-market work

How do you build an AI employee you can trust with go-to-market work?

By treating it as a business process made explicit in an application, given controlled tools, and proven to complete work and recover from exceptions. That sentence is the whole method; the persona, the prompt and the model sit inside it. What follows is the standard we hold our builds to, written down as version 1.0 on September 5, 2026, in our internal team guide, Building AI Employees on Kylon. It makes design claims with a reason for each and reports no measurements, so this post makes design claims too and says so. The specific example throughout is Kylon, the orchestration platform we build on.

definitionDigital workflow twin

A digital workflow twin is a maintained software representation of one business process: the work items that exist, the state each one is in, the evidence behind that state, what is owed next, who owns it, and which actions are permitted. The AI employee operates that process through defined tools, and the twin is what makes its work inspectable by a person.

What do you model first, the work or the employee?

The work. A role such as marketing manager is too broad to execute as a single instruction, so we break it into processes: intake a brief, clarify its purpose, select the channel, prepare assets, validate claims and destinations, publish within authority, inspect results, and decide what happens next. Each incoming event is triaged for what changed, which work item it belongs to, which step now applies, what remains owed, and whether there is enough evidence and authority to act. Routing then selects the playbook, tool, queue or human.

The pattern is recursive. A reply to a sales message is a new event. Feedback on a creative asset is a new event. A calendar cancellation, a failed publication and a human resolution are new events, and each re-enters the process with updated state. Our standing example is the message "send the brochure and move our meeting", which creates two linked obligations; delivering the brochure does not complete the scheduling request, and the routing model has to hold both.

Workflow, as we use the word, includes branches, waiting states, parallel obligations, revisions and exceptions. Code controls the boundaries and the required evidence; the agent interprets language, reasons about the case, and creates useful work inside those boundaries.

What do you write before the prompt?

The operating contract. A builder and a business owner should be able to read one document and agree on what success looks like for an ordinary case and for an exception. Our operating contract has seven items.

1. The business outcome and how it will be verified, such as a confirmed appointment or a published asset at the correct destination.
2. The work item and its boundary, such as an opportunity, an application, a campaign or a press inquiry.
3. The authoritative sources, the owner of each important fact, and what happens when a source is stale, missing or contradictory.
4. Stages, with entry and exit evidence, allowed and prohibited actions, timing, and spending or volume limits.
5. The next action or waiting condition at each stage, including obligations created by promises.
6. The business owner, the operational escalation recipient, a backup recipient, and the technical owner.
7. The starting scope for autonomous execution and the conditions that require escalation.

The guide's test for a rule is whether it is concrete enough to check. Its example is that "A calendar booking ID is required to mark a meeting scheduled" is testable, while "Be careful and keep the CRM accurate" is insufficient as an execution rule. We also hold that writing a condition into a skill describes the process; only implementing the check in application operations enforces it, and both are required.

Where does each responsibility live?

In the six blocks of the architecture, and we define each one partly by what it must not substitute for. The shared room must not become the authoritative queue or the only record of an obligation. The agent may propose, and it holds no permission to override application limits. Both the human interface and the agent tools go through the controlled operations for protected changes, so a UI toggle alone is not the only barrier to an external send. The workflow runtime runs and recovers work, and it is no proof that the intended business result occurred. The persistent records are the digital workflow twin: the work that exists, the state of each item, the evidence behind it, what is owed next, who owns it, and which actions are permitted.

We are specific about what Kylon does and what it does not do. Kylon provides the environment in which the team coordinates the employee and its workflows: rooms for the humans and agents in a process, apps for a coherent business process, workflows that wake part of the process on a schedule or an event, skills for recurring procedures, and connectors to named systems. The application and its integrations must enforce the business rules that make execution dependable. Hosting the whole thing in Kylon is an implementation choice, a move of hosting does not itself add evidence checks, recovery or durable next actions, and an existing CRM can remain authoritative if its API and access controls support the contract. We hold the pattern to be independent of Kylon for a plain reason: it asks nothing of the platform beyond a place for the team to coordinate, an application the employee can reach, and workflows it can trigger, and the guide requires no specific database, host or model vendor.

What counts as done?

A stage change requires the evidence that makes the new state true. The agent can propose the transition; the application validates it, and where practical the state change and its event record commit together so the application cannot report a change without its audit record. We also keep the business stage and the action status in different fields, because an opportunity can remain qualified while its next response awaits clarification, and an action can be submitted to a provider while delivery is still unknown.

Underneath the table sits our rule that "provider accepted", "delivered" and "business outcome achieved" must not collapse into a single success flag, and that where a provider exposes only part of that chain, the application preserves the limitation.

What happens when the employee cannot proceed?

It escalates, and we treat escalation as a tool rather than a chat message. The escalation operation creates a persistent ticket with six fields: the affected work item and triggering event; a concise question with known facts, uncertainty, evidence and source versions; the employee's recommendation and permitted alternatives; actions already taken and the actions now blocked; a named recipient, a backup recipient, a response deadline, severity and fallback behavior; and the condition for resuming work and the scope of the human's eventual decision. Creation, delivery, acknowledgment, resolution and resumption are tracked separately, and an internal post with no recipient and no owner is not a completed handoff.

While it waits, the employee pauses the affected action and continues independent eligible work. Our rule is that "elapsed time never becomes permission": at the deadline the employee uses the defined backup, defers, cancels, or leaves the action visibly blocked, and when a human resolves the ticket it refreshes state before resuming, because the person may have replied or the calendar may have changed in the meantime.

A resolution then passes through two separate decisions: resolve the case, then ask whether it contains a reusable lesson and where that lesson belongs. A decision for one case stays in that work item's record with its exact scope and expiry; a verified fact goes to the authoritative source; a recurring method goes into a skill and is tested against other cases; a change of permission goes into enforced policy once the business owner accepts it; a discovered failure becomes a regression test and a code fix. Our worked example is an executive assistant asked to book outside the executive's permitted hours: the human permits that one appointment, the assistant records a case-specific exception and books through the controlled tool, and a regression case verifies that this exception cannot authorize the next out-of-hours booking. A one-off exception does not become general authority.

How does it go live?

In three steps, each gated by evidence. The prototype is one narrow, complete path from an incoming event to a verified outcome and a recorded next action, with exception handling built in from the start. Prototype testing uses synthetic fixtures, provider sandboxes where available, and designated internal test destinations, so that prospects, employees, journalists and customers do not become accidental test recipients.

Phase 1 runs the employee on authorized live or replayed inputs and produces drafts, proposed actions, stage changes and exceptions on a labeled review surface, where humans review what it understood, proposed and missed. No external execution is permitted: no publishing, no real meeting invitations, no ad launches, no spending, and no false advance of production state. Reviewers evaluate the whole workflow, including whether the employee noticed a promise and whether the stage update would be truthful, on our principle that good prose cannot compensate for an incorrect business action.

Phase 2 executes authorized work autonomously, without a routine approval queue, and escalates the defined exceptions. It begins with a limited cohort, action type, channel or business scope, and expansion is a release decision based on outcomes and coverage. Passing tests establishes readiness; the named business owner authorizes the versioned change to external mode, and the employee cannot promote itself.

The guide's planning defaults for the observation window before Phase 2 are seven days and at least 30 representative reviewed cases, supplemented with replayed cases when volume is low. It frames these as planning defaults rather than a guarantee or a universal minimum, and rare critical conditions still require explicit tests. Successful runs and high average content scores are insufficient release evidence on their own, because a single unresolved failure of a critical stop, routing or mode control can block the affected scope even when most drafts are excellent.

Before Phase 1, the prototype passes the guide's smoke test checklist, eight items.

• Create or replay one authorized input in the prototype environment and verify its event identity.
• Confirm the correct work item, owner, relevant history, and active configuration are loaded.
• Generate a proposal and see it in the human review surface.
• Verify an invalid transition and a prohibited action are rejected by the application.
• Exercise an escalation, record an internal resolution, and confirm safe resumption.
• Verify internal mode cannot reach any real external side effect or false production update.
• At a designated test destination, verify the external adapter and its receipt handling separately.
• Simulate an interruption and confirm recovery preserves the next action.

Does one build serve sales, assistants, marketing, social, PR and hiring?

Yes, with a shared core and a role-specific configuration. Event intake, knowledge loading, controlled execution, scheduling and recovery, escalation, evaluation and releases are the shared mechanism; each role supplies its own inbox, sources, allowed actions, limits, service hours and escalation recipients. In sales the work item is an opportunity. The employee qualifies, answers supported questions, books through verified operations and follows up; unknown terms, concessions beyond authority, ambiguous ownership and uncertain sends escalate, and a won or closed state must come from the process's defined evidence. For an executive assistant the work item is a request or commitment; preferences and authority define what can be scheduled, delegated or changed, and calendar acceptance and task completion require evidence from the owning system. Hiring, marketing operations, social media and public relations get the same core with a different work item, different authority and different evidence.

What do we do with clients?

We build these as custom go-to-market projects. The operating contract, the authoritative sources, the authority limits and the escalation recipients are co-defined with the client's team, because we require a named business owner for each of them and that owner sits on the client's side. We then hand the employee over running, in the client's own environment.

Disclosure: GrowthMasters is a paying Kylon customer, and we have proposed a partnership under which we would run Kylon's paid media and content in exchange for platform credits. That proposal was open when this was written.

An AI employee you can trust is a business process made explicit, with tools that enforce its rules and evidence that proves its work. Build that first, and the persona becomes configuration.