DEV Community: Calvin Lin

How to Handle Goal Loops in Business Operations with AI Agents

Calvin Lin — Sun, 23 Aug 2026 18:13:53 +0000

Originally published by Manor AI: https://manorai.xyz/blogs/blog-handle-goal-loops-business-ai-agents.html

Business work rarely ends after one output. A customer replies. A lead goes quiet. A support issue changes priority. A creator launches a new offer. A founder decides retention matters more than outbound this week. A finance review finds an exception. A workflow that looked correct at 10:00 can be wrong by 10:17.

That is why the useful unit of AI business software is the goal loop.

The agent still matters. The workflow still matters. But neither is enough if the business cannot preserve state around the work: what goal is active, what context is trusted, what action is being proposed, what has already been approved, what changed since approval, and what outcome should be measured after action.

The goal loop model

A goal loop is a recurring business objective with enough structure to be run, reviewed, improved, and run again. The simple version looks like this:

goal -> context -> proposal -> approval -> action -> log -> measurement -> re-evaluate

This model is useful because it matches how operators actually work. A founder does not close a customer by sending one message. A support team does not improve customer experience by summarizing one ticket. A creator does not help students build a business by giving one prompt. The work advances through repeated passes over changing context.

Tasks have outputs. Goal loops have state.

A task can be completed in isolation. A goal loop cannot.

Task: draft a follow-up email.
Goal loop: recover stale sales opportunities without messaging someone who already replied, already booked, or should be excluded.
Task: summarize a support ticket.
Goal loop: reduce unresolved customer issues while keeping refunds, pricing exceptions, and public commitments behind review.
Task: generate a weekly report.
Goal loop: review progress, detect blockers, decide the next operating priority, and leave evidence for the next review.

The difference is state. A goal loop needs to know what happened before, what changed, what is allowed, who owns the decision, and what outcome matters now.

Separate the strategist loop from the proposal loop

Useful business AI usually contains two different loops that should not be collapsed into one black box.

The strategist loop decides what should happen next based on current business state. It asks which goal matters, what changed since the last review, which constraint matters most, what should stop, and what should be escalated.

The proposal loop turns that direction into a concrete action that can be reviewed, approved, executed, and logged. It asks which records are affected, which sources were used, what exactly will be sent or changed, which tools are required, what approval boundary applies, and what should be logged after execution.

When these two loops are mixed together, review becomes vague. A human sees an agent's conclusion, but not the operating state, evidence, tool scope, approval rule, or exact side effect. That is not enough for real business execution.

A concrete example: customer retention

Imagine a small SaaS company with 300 customers. The strategist loop reviews current business state and decides that retention should be prioritized this week because expansion pipeline slowed and several customers have unresolved issues.

That is not an action yet. It is direction.

The proposal loop turns the direction into reviewable work:

Review customers with open support issues older than seven days.
Exclude customers who replied in the last 24 hours.
Pull billing status, plan level, support history, and the last human note.
Draft a specific follow-up for each account.
Pause before sending anything that mentions refunds, credits, pricing, or commitments.
Log which sources were used and what the reviewer approved.
Re-check state immediately before sending.

This is where an AI business workspace becomes valuable. The workspace carries the goal, current context, reusable skills, approval rules, evidence, and measurement around the agent. The agent is not asked to rebuild the operating system every time.

Stale approvals are a real failure mode

Approval is not only a button. Approval is a decision made against a specific business state.

If the state changes, the approval may no longer be valid.

Common examples:

A customer replies after a draft was approved.
Pricing changes before a renewal email is sent.
Inventory changes before a fulfillment message goes out.
Another workflow already handled the same account.
A support issue escalates after the proposal was reviewed.
A goal is reprioritized by the owner or team.

In those cases, the agent should not blindly continue. Before any external side effect, the workspace should re-check whether the goal is still active, whether approval is still fresh, whether source data changed, whether another workflow touched the same record, and whether the action is still inside the approved scope.

This is why goal loops need state, not just memory. Memory can recall history. State decides whether the current action is still valid.

Where workflow automation fits

Workflow automation tools are strong when the path is deterministic:

form submitted -> create record -> notify team -> schedule task

That should be reliable and inspectable. Tools such as n8n, Zapier, and Make are strong for this kind of structured handoff.

AI agents are useful when the work starts in messy business context: inbox threads, support tickets, customer histories, documents, calls, notes, policies, and changing priorities.

The practical stack is both. Workflow automation handles structured handoffs. The workspace layer handles context-heavy loops where a person may need to review the proposal before the business takes action.

What to measure

The wrong metric is "how much AI ran." The better metric is whether the goal loop moved.

For a retention loop, measure unresolved accounts reviewed, qualified follow-ups prepared, risky messages caught before sending, customer replies recovered, churn-risk accounts escalated, cost per reviewed account, and time saved per weekly review.

For a sales loop, measure stale leads recovered, follow-ups prepared, duplicates avoided, human review time, conversion lift, and cost per qualified reply.

For an operations loop, measure exceptions detected, reports completed, handoffs created, blocked tasks surfaced, approvals completed, and rework avoided.

The goal loop should make business progress easier to see. If it only creates more agent activity, it is not working.

A checklist before giving agents tool access

Before an agent can act on a business workflow, define these pieces:

The goal: what business outcome should move?
The trigger: what starts the loop?
The trusted context: which records, emails, docs, notes, and policies can the agent use?
The skill: what repeatable job is the agent performing?
The proposal: what exact action is being suggested?
The approval boundary: which actions can run automatically, and which must pause?
The state re-check: what must still be true immediately before execution?
The log: what evidence should be saved?
The measurement: how will the team know the loop worked?
The stop rule: when should the agent stop or escalate?

This is the difference between using AI for isolated output and using AI for business execution.

How Manor AI thinks about goal loops

Manor AI is designed as a workspace for turning repeated business work into reviewable operating loops.

The design goal is not to let agents do everything. The design goal is to let businesses define goals, business context, reusable skills, agent roles, workflow paths, approval rules, evidence logs, measurement, and re-evaluation in one place.

The workspace matters because agents need somewhere to inherit current state before they propose action. The approval boundary matters because some actions should be prepared by AI but decided by a person. The log matters because the next loop should not start from zero.

That is the operating model:

business context -> strategist -> proposal -> approval -> action -> evidence log -> measurement -> next loop

This is how AI becomes business infrastructure instead of another disconnected tool.

Why We Built an Independent, Goal-Driven AI Workspace

Calvin Lin — Sat, 22 Aug 2026 05:14:59 +0000

Most AI products begin with a chat box.

That is useful for answering a question, drafting a document, or calling a tool. But it becomes harder to use when the work lasts longer than one conversation or involves several people and Agents.

The problem is not only memory. The work also needs a clear goal, an owner, a current state, decision rules, review points, and a result that somebody can verify.

That led us to a different model: an independent, goal-driven AI Workspace.

What we mean by a Workspace

A Workspace is not a folder containing several chats. It is an operating unit built around a measurable goal.

For example, instead of asking an Agent to “help with product research,” a Workspace can define:

the outcome it is expected to produce
the people and Agents responsible for the work
the Tasks and Plans currently in progress
the Knowledge and documents that belong to this goal
the Tools and Rules that apply
the actions that require human approval
the artifact that proves the work is complete

Each Workspace keeps this context and execution state separate from unrelated work. A customer project should not inherit the documents, permissions, or unfinished Tasks of another customer. An internal research Workspace should not behave like a support Workspace.

The goal provides direction; the boundary provides control.

Why goal-driven matters

Without a goal, an Agent can keep producing plausible activity without getting closer to a useful outcome.

Inside a goal-driven Workspace, each proposed Task or action can be tested against a simple question: does this move the Workspace toward its goal?

This creates a visible path:

Goal → Plan → Tasks → Execution → Approval → Artifact

The final unit of value is not a prompt or an answer. It is a completed outcome with enough history for a person to review what happened.

Why independence matters

Long-running AI work accumulates state. It gathers documents, decisions, intermediate outputs, failed attempts, permissions, and assumptions.

If all of that lives in one global conversation, the system becomes difficult to understand and risky to operate. Independent Workspaces give each goal its own:

Context
Team and Agents
Knowledge
Tasks and Plans
Rules and approval boundaries
Activity history and artifacts

This also makes collaboration clearer. A person can see what is active, what is blocked, what needs approval, and what has actually been delivered.

What we built

Manor AI is our self-hosted implementation of this idea.

It connects Workspace conversations with Goals, Tasks, Plans, Agents, Skills, Knowledge, approvals, Flows, Automations, and resulting artifacts. The intention is to keep context, execution, review, and results together instead of scattering them across chat windows and separate tools.

A small first workflow looks like this:

Create a Workspace with a clear outcome.
Add the relevant Knowledge and an Agent with a defined responsibility.
Create a Task with acceptance criteria.
Review the Plan and respond to approval requests.
Verify the resulting artifact.
Turn a process that works repeatedly into a Flow or Automation.

We have published the self-hosted source on GitHub under the Manor Sustainable Use License 1.0. It is source-available rather than OSI-approved open source, and we want to be explicit about that distinction.

Repository: https://github.com/manor-os/manor-ai

What we want to learn

We are still testing where the Workspace boundary should sit and what information must remain visible to users.

If you build or operate Agents, we would appreciate your view on three questions:

What should be isolated between Workspaces?
Which actions should always require human approval?
What evidence do you need before trusting an Agent's “completed” result?

Those answers are more useful to us than a generic launch reaction.

MCP went stateless. Your agent workflow did not.

Calvin Lin — Mon, 03 Aug 2026 16:51:49 +0000

MCP 2026-07-28 is now the stable Model Context Protocol revision. Its biggest architectural change is a stateless, sessionless core designed to run more naturally on ordinary HTTP infrastructure.

That is a major improvement for protocol implementers. It does not make the work performed through MCP stateless.

Disclosure: AI tools assisted with editing this article. The Manor AI team reviewed the technical claims against the stable MCP specification, changelog, and referenced SEPs before publication.

What problem MCP solves

Before MCP, each AI host tended to invent its own adapters for files, databases, developer tools, and business systems. Every connection brought a new schema, discovery model, authentication flow, error model, and lifecycle.

MCP gives hosts and servers a common way to expose:

Tools a model can invoke;
Resources that provide data and context;
Prompts that package reusable interaction patterns.

The protocol standardizes how capabilities are described and invoked. It does not decide why a capability should be used, who should approve it, or where the result should live tomorrow.

What changed in MCP 2026-07-28

1. The core protocol is stateless

Earlier Streamable HTTP deployments could establish a session and carry an Mcp-Session-Id across requests. Horizontally scaled servers then needed session affinity or shared session infrastructure.

The new revision removes the initialization handshake and protocol-level session. Each request carries the information needed to understand it, while server/discover lets clients inspect server capabilities.

Any healthy server instance can now handle a request. This fits ordinary load balancers, gateways, caches, and tracing systems much better.

When a workflow needs state across calls, the server can return an explicit handle and accept that handle as a normal argument later. A basket_id, browser_id, or job_id becomes application data instead of invisible transport state.

2. Server-to-client interaction becomes an explicit round trip

A server may still need more information while processing a request. The Multi Round-Trip Requests pattern makes that requirement explicit.

Instead of depending on an open bidirectional session, an operation can return input_required. The client collects the requested input and retries the operation with inputResponses.

The correlation state is visible and routable rather than hidden inside a connection.

3. Extensions can evolve outside the core

MCP now has a first-class extension model. Optional capabilities are advertised explicitly and can evolve without forcing every implementation to adopt them at the same time.

Two extensions are especially relevant to agent applications:

MCP Apps can render interactive interfaces such as forms and charts inside a conversation.
MCP Tasks adds asynchronous operations with durable handles, polling, and mid-flight input.

These extensions make MCP useful beyond short synchronous tool calls. They still do not replace the product-level operating model around a team.

4. Authorization improves, but host policy remains necessary

The revision strengthens authorization and aligns it more closely with OAuth and OpenID Connect deployments.

Authentication can establish whether a client may connect to a server. It cannot fully answer whether this specific agent should send an email, publish a post, modify a record, or delete a file in the current situation.

The specification keeps that boundary explicit: host applications still need consent interfaces, access controls, and safe execution behavior.

Stateless protocol is not stateless work

A tool call can be self-contained while the work around it remains durable.

Consider a customer-onboarding workflow. It may include research, document generation, CRM updates, email drafts, approvals, and a final handoff. Several MCP calls may participate, but the team still needs to know:

the goal and current status;
who owns the work;
which documents and instructions were used;
which tools were available;
what completed and what failed;
where human input was required;
which evidence supports the result.

None of that belongs in a transport session. It belongs in the host application's data model.

A prompt is not a durable task

Chat is useful for expressing intent. It is a poor database for operational state.

A real task needs an owner, priority, acceptance criteria, plan, status, evidence, comments, and a result that can be verified. If execution stops halfway through, another person should be able to see what happened and continue the work.

The conversation can start the task. The task should become the record of the work.

This also explains why an MCP Task and a product-level task are different concepts. The MCP extension represents the lifecycle of a protocol operation. A host application decides how that operation relates to a business goal, an owner, policy, review, and a result that remains useful later.

Context needs an operating boundary

Giving every agent access to every document and every tool is convenient in a demo and dangerous in production.

Context should belong to a boundary such as a project, workspace, customer account, team, or environment. That boundary groups the people, agents, knowledge, tools, integrations, and rules that belong to the same work.

It answers two basic questions:

What information may this agent use?
What actions may this agent take here?

Without a boundary, retrieval and tool calling become global capabilities with unclear ownership.

Human approval belongs inside execution

Approval should not be a popup added after an automation is designed.

A task should be able to pause, show the proposed action and supporting evidence, record a decision, and continue from the same state. That creates a useful division of responsibility:

the agent prepares and explains the action;
the runtime enforces the checkpoint;
a person makes the decision;
the task records what happened.

This matters most for customer communication, publishing, permission changes, payments, and destructive actions.

Evidence makes agent work debuggable

When automation produces a bad result, the first question is usually: why?

The answer should not require reconstructing an entire chat transcript. A production host should preserve the plan, steps, tool results, artifacts, approvals, errors, and final status associated with the work.

Evidence helps operators review a proposed action, developers debug a failed run, and teams improve a workflow after repeated use.

What production hosts still need to provide

The protocol is intentionally not a business-process engine. A production host still needs:

an operating boundary for people, agents, knowledge, and rules;
persistent context beyond one conversation;
work objects with ownership, status, acceptance criteria, and results;
narrowly scoped tools and credentials;
approval checkpoints for consequential actions;
evidence that makes execution reviewable;
workflows that can be repeated and improved.

That is not a weakness in MCP. It is the correct separation of concerns.

MCP standardizes the integration surface. The host remains responsible for turning tool calls into work a team can operate.

A practical test

Give an agent a small task with a verifiable result. Let it use one document and one scoped tool. Trigger an action that should require approval.

Then verify that the system:

pauses before the consequential action;
shows useful evidence;
records the decision;
resumes from the same state;
leaves a result another person can inspect.

That path reveals whether the system is only an agent demo or something a team can operate.

References

Originally published by the Manor AI team on Medium. This DEV edition is a technical cross-post with the original URL set as canonical.
``