How we build a go-to-market AI employee: code for the rules, a model for the judgment

How does one AI employee get the reliability of code and the judgment of a model?

By splitting the job in two and holding the line between the halves. Code holds the rules, the evidence each stage change requires, and the record of what happened. The model reads each incoming message, works out what it means for the case in front of it, which work item it belongs to and what is now owed, and proposes the next step inside the limits code sets. Rules set boundaries. They do not read a message that asks for a brochure and a new meeting time in one line, and that reading is what the model is for. When the employee cannot proceed within its authority, it opens a ticket to a named person, pauses that action, and continues the independent work it is still permitted to do. What it learns from the answer stays scoped to that case, and a change of permission takes effect only once the business owner accepts it.

In practice that means treating the employee 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 in September 2026 in our internal guide, Building AI Employees on Kylon. It gives a reason for each rule and reports no measurements. This post reports none either. Kylon is the orchestration platform we build on, and we hold the pattern to be independent of it.

definitionAI employee

An AI employee is a business process made explicit in an application, given controlled tools, and proven to complete work and recover from exceptions. Code enforces the rules, requires evidence for every state change and keeps the record. A model interprets the inputs and proposes work inside those rules. A person is asked, through a tracked ticket, whenever the employee cannot proceed. It learns through accepted changes, a change of permission takes effect only once the business owner accepts it, and it cannot promote itself.

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 loop feeds itself. 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". It creates two linked obligations. Delivering the brochure does not complete the scheduling request, and the employee 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 model interprets language, reasons about the case, and creates useful work inside those boundaries. That split is the whole design, and every section below places one responsibility on one side of it.

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.

Our test for a rule is whether it is concrete enough to check. "A calendar booking ID is required to mark a meeting scheduled" is testable. "Be careful and keep the CRM accurate" is insufficient as an execution rule. Writing a rule into the employee's instructions describes the process. Only a check in code enforces it. We require both.

Where does each responsibility live?

In six blocks, and the split from the opening runs through them. In the figure below, the model lives in one block, agent and workflow execution. The agent may propose, and it holds no permission to override the application's limits. The code side is the three blocks the build adds: the controlled operations that hold authority and the entry and exit rules, the records that hold state and evidence, and the adapters that hold the allowed effects and the verified receipts. Every protected change passes through the controlled operations, whether a person or the agent asked for it, so a toggle in the user interface is not the only barrier to an external send. We also define each block by what it must not stand in for. The shared operating room, where the humans and the agents in a process coordinate, must not become the queue of record or the only place an obligation is written down. The workflow runtime runs and recovers work, and a completed run is not proof that the business result occurred. The persistent records are the digital workflow twin: a maintained software representation of the 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 twin is what makes the employee's work inspectable by a person.

Kylon supplies the environment: rooms where the humans and agents in a process coordinate, 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. Moving where the employee is hosted does not by itself add evidence checks, recovery or durable next actions. An existing CRM can remain the authoritative record 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 we require 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. Where practical, the state change and its event record are written as one, 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.

The rule under the table is that "provider accepted", "delivered" and "business outcome achieved" stay three separate facts and must not collapse into a single success flag. Where a provider can confirm only part of that chain, the record says only what was confirmed.

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 the event that triggered the escalation.
• A concise question, with the known facts, the uncertainty, the evidence and the source versions.
• The employee's recommendation and the alternatives it is permitted to take.
• The actions already taken and the actions now blocked.
• A named recipient, a backup recipient, a response deadline, a severity and a fallback behavior.
• The condition for resuming work and the scope of the human's eventual decision.

Creation, delivery, acknowledgment, resolution and resumption are tracked separately. 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 the independent work it is still permitted to do. 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. When a human resolves the ticket, the employee refreshes state before resuming, because the person may have replied or the calendar may have changed in the meantime.

How does it improve without gaining authority?

By separating two decisions. A person resolves the case. Then the question is whether the case holds 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, the employee's stored procedure for that situation, and is tested against other cases.
• A change of permission goes into enforced policy, and only 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. A regression case then verifies that this exception cannot authorize the next out-of-hours booking. A one-off exception does not become general authority. That is how the employee improves: a lesson lands in a record, a source, a skill, a policy or a test, and what it is allowed to do changes only when a person changes it.

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 made-up test data, provider sandboxes where available, and internal test destinations, so that prospects, employees, journalists and customers do not become accidental test recipients.

Before Phase 1, the prototype passes our smoke test.

• Create or replay one authorized input in the prototype environment and verify its event identity.
• Confirm the right work item, its owner, its history and the current configuration are loaded.
• Generate a proposal and see it on 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 write a false production update.
• Test the external adapter and its receipt handling separately, against a designated test destination.
• Simulate an interruption and confirm recovery preserves the next action.

Phase 1 runs the employee in internal mode on authorized live or replayed inputs. It produces drafts, proposed actions, stage changes and exceptions on a labeled review surface, where humans check what it understood, proposed and missed. No external execution is permitted: no publishing, no real meeting invitations, no ad launches, no spending, and no production record advanced to a stage it has not earned. 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.

Our planning defaults for the observation window before Phase 2 are seven days and at least 30 representative reviewed cases, with replayed cases added when volume is low. These are defaults, not a guarantee or a universal minimum, and rare critical conditions still require their own tests. Clean runs and high average content scores are not release evidence on their own. A single unresolved failure of a critical stop rule, routing rule or mode check can block the work it affects, even when most drafts are excellent.

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 switch to external mode, where real sends and real bookings happen, as a versioned change. The employee cannot promote itself.

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 the questions its sources support, books through verified operations and follows up. Unknown terms, concessions beyond its authority, ambiguous ownership and uncertain sends escalate. A won or closed state comes only from the process's defined evidence. For an executive assistant the work item is a request or a commitment, 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.

Why both code and a model?

Because each one does what the other cannot. The message "send the brochure and move our meeting" creates two obligations, and reading that is the model's job. Whether the meeting moved is a fact in the calendar, and recording it is code's job. A scheduling link that was sent does not count, and neither does a draft that was never delivered. A model can write excellent prose around a wrong business action, so the application validates every stage change, and a person reached through a tracked ticket decides the exceptions. What that person decides lands in one case record, one source, one skill, one test or one policy. Only the policy change widens what the employee may do, and only once the business owner accepts it. An AI employee you can trust is a business process made explicit, with code that enforces its rules, evidence that proves its work, a model that reasons inside the limits, and a person one ticket away. Build that first, and the persona becomes configuration.

What do we do with customers?

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