An AI assistant reads a customer email, finds a related meeting transcript and suggests a new task in the engineering board. That can be useful.
What happens when it reads the same email again an hour later?
If it creates a second ticket, notifies the wrong person or silently closes the first ticket after finding a merged pull request, the automation has become additional work instead of reducing it.
The core problem is not whether the model can summarize an email. It is whether the workflow can reliably translate uncertain source material into permitted, traceable actions.
A production AI workflow needs durable state, identity, idempotency and a clear boundary between proposing an action and executing it.
Retrieval and action are different privileges
Reading a message and creating a CRM opportunity are not the same operation.
An agent may be allowed to inspect authorized Slack conversations, Gmail threads, meeting transcripts or GitHub issues. That does not automatically authorize it to post a public reply, share an attachment, change financial records or modify a production configuration.
The system should therefore give each integration the minimum capability required for its purpose. Read tools can be broad enough to support useful discovery within the user's rights, while write tools should be scoped to explicit operations and identities.
It is a mistake to treat the conversational interface as the authorization system. A prompt saying "do not change anything unless approved" is useful guidance, but it is not a security boundary.
Decide when a task really exists
One customer request may appear in multiple places: a meeting, a follow-up email, a Slack conversation and an existing issue.
Without deduplication, the agent can create four tickets for one piece of work.
A task-ingestion process needs a stable identity for the underlying commitment. Useful evidence includes the message or meeting identifier, customer context, action owner, deadline and links to an existing work item.
The model can help identify whether two descriptions refer to the same obligation, but the workflow still needs rules for matching, review and upsert behavior. A guessed title is not a stable unique key.
The same principle applies when detecting completion: a merged pull request may resolve an implementation task, but it does not prove deployment, customer sign-off or acceptance of the operational result.
Model the workflow as states, not chat messages
A reliable process should represent actual state.
For example, a request might be classified as Needs Decision, then Todo, In Progress, Review, Done or Waiting / Blocked depending on what has been verified.
These labels are illustrative. Each team should use its real board states and completion definitions.
The important distinction is that finding a promising source is not equivalent to deciding to perform the work. Nor does a model's claim that an action succeeded mean the external application recorded that change.
Always read back important writes from the target system and record the returned identifier. If the write fails or times out, reconcile before retrying rather than creating another item blindly.
Idempotency makes scheduled automation safe
A scheduled agent often sees overlapping windows of activity. It can be restarted mid-run or retry after a network interruption.
Idempotency means repeating the same request does not create unintended additional effects.
For a ticket workflow, that can mean storing a source-event key and existing ticket ID, then updating the known record after verifying its state. For a notification, it can mean recording whether an exact message was already sent, to which destination and on which approved run.
Do not rely solely on a language model remembering what it did in another conversation. Durable state must live outside the model and be checked during execution.
Retries also need different treatment depending on the operation. A read can often be safely retried; a payment, email send or public post may need a more cautious reconciliation protocol.
Human approval is an execution boundary
Some actions are reversible and low risk: generating a draft, linking evidence to a ticket, or calculating an estimate.
Other actions can affect people or public systems: posting on a company account, sending customer commitments, changing permissions, terminating resources or approving spending.
Approval should bind to the exact payload: destination, action type, text or parameters, intended identity and scope. If a model changes the text after approval, it is a different request and requires review.
This is not about asking a human to perform every step. The system should automatically do the low-risk research, classification and drafting, and ask for review only where authorization matters.
An operational example: connected-source ticketing
Consider an agent that periodically checks meeting notes, email and an engineering board for new customer commitments.
A useful sequence would be:
- Fetch only data available to the service identity.
- Extract candidate commitments with source links.
- Check for existing tasks and contradictory updates.
- Record a proposal or place an uncertain item in Needs Decision.
- Obtain human approval when ownership, cost or external communication is not sufficiently established.
- Create or update the real work item and save its returned ID.
- Reconcile task state against later evidence, without marking external outcomes complete prematurely.
This is a reference design, not a claim that a particular customer system was deployed with all seven steps.
Evaluate the agent on business outcomes
A demo where the agent creates a ticket is not a production evaluation.
You need to measure duplicate creation, false-positive commitments, missed work, incorrectly closed tickets, approval latency, tool errors and the proportion of actions that are genuinely useful.
Include negative cases in the evaluation set: two similar emails about different projects, a deleted meeting, a reopened issue, a merged PR that was rolled back and a message that quotes an old action request without making a new commitment.
A good system should know when source evidence is insufficient and preserve that uncertainty.
The role of the AI model
The model can be valuable in interpreting unstructured text, comparing related evidence and drafting a clear action for review.
It should not replace transaction controls, identity permissions, state transitions or observability. Those are ordinary software engineering responsibilities. They also need to cover prompt injection through untrusted content and tools, not only accidental retries and duplicate writes.
For teams deciding where to introduce autonomous workflows, Big Bad Byte's AI automation engineering starts with the existing process and its failure conditions. We want an agent that does useful work, but we also want to prove what it did and stop it from doing the wrong thing twice.