DEV Community: Calvin Lin

A Practical Architecture for Self-Hosted AI Agent Operations

Calvin Lin — Tue, 08 Sep 2026 04:50:20 +0000

Running an AI agent on your own infrastructure gives you control over deployment and data, but it does not automatically make the system reliable or safe.

The difficult part begins when an agent can use tools, access business context, and continue working after the first prompt. At that point, the system needs operational boundaries—not only a model endpoint and a collection of tools.

Here are seven boundaries worth designing before adding more agents.

1. Give each workspace a clear goal

Do not use one global agent context for every project. A workspace should have a defined goal, its own relevant knowledge, and an explicit set of participants and capabilities.

A measurable goal also gives the system a way to decide whether work is complete. “Help with marketing” is too broad. “Produce a reviewed launch brief and a seven-day content plan” can be checked.

2. Separate agent identity from user identity

An agent should not silently inherit every permission of the person running it.

Use a distinct identity or capability set for each agent role. A research agent may read approved sources but should not publish. A communications agent may draft a message but require approval before sending it. Credentials should be scoped to the smallest useful surface.

3. Treat tools as capabilities, not plugins

A tool description is part of the security boundary. Record what the tool can read, what it can change, and whether the action is reversible.

This is particularly important for MCP servers. Treat MCP configuration like executable dependency metadata:

allowlist server origins;
pin the expected package, version, or image digest;
isolate credentials per server;
review tool-schema changes;
default new capabilities to disabled or read-only;
require approval when capabilities expand.

The question is not only whether a server is trusted. It is what the server can do with the identity and environment available to it.

4. Distinguish planning from execution

The output of a planning step should not automatically authorize execution.

Plans can be reviewed, changed, and rejected. Execution should use a specific plan version and record each attempted step. This makes failures easier to reproduce and prevents the system from quietly changing its approach after approval.

5. Make approval requests inspectable

An approval request should contain a compact decision packet:

proposed action;
reason for the action;
target account or resource;
important parameters;
expected effect;
rollback or recovery path, when one exists.

Users should not need to inspect a full agent transcript to understand what they are approving.

6. Store artifacts separately from chat

A final answer is not always the result of the work. The result may be a document, spreadsheet, code change, report, or updated task state.

Store those artifacts as durable objects, link them to the task that produced them, and keep the supporting evidence available. This gives users something concrete to verify and reuse.

7. Define completion with observable checks

Agents are good at producing plausible completion reports. They still need objective acceptance criteria.

Examples include:

a command exits successfully;
an expected file exists and passes validation;
a message remains in draft until approved;
a workflow creates the expected artifact;
a required source is cited;
a human reviewer accepts the result.

Without these checks, “done” is only another model-generated sentence.

A small reference model

The resulting loop is straightforward:

Goal
  -> Workspace context
  -> Plan
  -> Task steps
  -> Tool calls
  -> Approval when required
  -> Artifact
  -> Acceptance check

We use this operating model in Manor AI, a self-hosted AI workspace for connecting conversations to persistent work. The public repository is source-available under the Sustainable Use License 1.0.

Self-hosting is most valuable when it gives operators understandable control. The architecture should make the agent’s scope, actions, and results easier to inspect—not merely move the same black box onto another machine.

Policy checks for AI agents: the proposal envelope pattern

Calvin Lin — Mon, 24 Aug 2026 20:44:25 +0000

AI agents become useful in business when they can move work forward. They also become risky at exactly that moment.

Reading a document is low risk. Drafting a reply is usually manageable. Sending the reply, changing a CRM stage, refunding a customer, editing a billing record, inviting a user, deleting a file, or posting publicly is different. Those actions leave the workspace and change the business.

That is why the operating layer around an agent matters as much as the agent itself. A business does not only need intelligence. It needs a repeatable way to decide whether an AI-proposed action is allowed, should be reviewed, must be blocked, or should be re-checked because the state changed.

The pattern I keep coming back to is the proposal envelope.

What is a proposal envelope?

A proposal envelope is a structured record an AI agent must produce before it changes a business system, sends an external message, touches money, updates permissions, or makes a public commitment.

It packages the exact proposed action, source evidence, risk class, approval owner, expiry time, idempotency key, rollback path, and log destination so a human or policy layer can review the action before it becomes a side effect.

The flow looks like this:

agent output
-> proposal envelope
-> policy check
-> approval inbox
-> state re-check
-> action
-> evidence log

The agent can still reason over messy context. It can still prepare useful work. But before it creates a side effect, it must produce a structured proposal that another layer can inspect.

Why this matters in real workflows

Most early agent workflows grow from small experiments.

A founder asks an agent to draft emails. A team adds a Slack approval step. A CRM workflow gets another condition. A support automation pauses when refund words appear. A billing exception goes to email. A public post waits in a document.

Each rule may be reasonable on its own. The problem is that the review system becomes scattered.

Nobody can easily see:

which proposals are waiting
which approvals expired
which actions already ran
what evidence the agent used
whether another workflow touched the same record
whether the business state changed after approval

That is how a sanctioned AI tool can still behave like shadow AI. The app may be approved, but the exact interaction is not governed. The connector exists, but the workflow does not have a shared policy contract.

What the envelope should contain

A useful proposal envelope includes:

Actor: which agent, workflow, user, or schedule requested the action
Goal: which business goal loop this action is supposed to advance
Target system: Gmail, CRM, billing, calendar, file storage, Slack, Discord, or another tool
Exact action: the specific message, update, record change, invite, post, or task to create
Affected record: the customer, lead, invoice, document, thread, account, project, or channel touched by the action
Source evidence: the emails, docs, notes, policies, tickets, or records the agent used
Risk class: low, review, sensitive, blocked, or custom levels defined by the business
Approval owner: the person or role allowed to approve the proposal
Expiry time: when the approval stops being valid
Idempotency key: a key that prevents duplicate sends, duplicate updates, or duplicate refunds
Rollback path: what can be undone, what cannot, and what mitigation exists
Log destination: where the final decision, evidence, and result should be recorded

This is much easier to review than a vague notification saying the agent wants to update something.

What the policy check should decide

The policy check should be boring. That is a feature.

Its job is not to rethink the whole business problem. Its job is to classify the proposal and decide what happens next:

Allow: safe, reversible, inside scope, and low impact
Require approval: customer-facing, financial, public, permission-related, or ambiguous
Deny: outside tool scope, missing evidence, unsupported claim, forbidden action, or unsafe target
Escalate: requires a named owner, legal review, founder approval, manager approval, or manual handling
Ask for more context: the proposal cannot be judged because the source set is missing or stale

The decision should come with a reason. A reviewer should know whether the workflow paused because of missing evidence, customer impact, money movement, public visibility, policy mismatch, or stale state.

The approval inbox is not just notifications

A real approval inbox is a queue of proposed side effects.

Each item should show what will happen, why the agent believes it should happen, which records are affected, what sources were used, who can approve it, and when the proposal expires. The reviewer should not need to reconstruct the entire thread from scratch.

This matters because review time is the hidden cost of AI. A draft that saves five minutes but requires ten minutes of fact-checking is not an improvement.

The approval inbox should make the reviewer faster by carrying evidence and constraints with the proposal.

State re-checks prevent stale approvals

An approval is only valid against a specific business state.

If the customer replied after approval, the approved follow-up may be wrong. If pricing changed, the old renewal draft may be wrong. If another workflow already updated the CRM record, a retry may create a duplicate task. If inventory changed, a fulfillment message may no longer be accurate.

Before execution, the workflow should re-check the minimum state that must still be true:

the goal is still active
the affected record has not changed in a conflicting way
the approval has not expired
the proposal is still inside the approved scope
the idempotency key has not already been executed
the source evidence is still current enough for the action

This is where many agent demos break in real operations. The demo shows an action. The business needs the action to still be correct at the time it runs.

Where deterministic workflow tools fit

Workflow automation tools are excellent for deterministic plumbing: triggers, transformations, webhooks, retries, routing, record updates, and scheduled jobs.

The proposal envelope pattern does not compete with that. It gives the AI part of the system a contract before the deterministic part executes.

A practical setup can look like this:

workflow trigger
-> AI drafts proposal
-> policy check
-> approval inbox
-> workflow executes approved action
-> log result

That split is important. The workflow should not ask the agent to improvise every step.

The agent handles the messy judgment: what does this customer mean, which policy applies, what action should be proposed, and what evidence supports it. The workflow handles reliable execution after the proposal is allowed or approved.

A concrete example: a renewal email

Suppose a small SaaS company wants an agent to help recover renewals at risk.

The agent reviews account notes, support tickets, usage, billing status, and the latest human message. It decides that one customer should receive a retention email with a proposed support plan.

Instead of sending, the agent creates a proposal envelope:

Goal: reduce churn risk for active customer accounts
Target: Gmail and CRM
Action: send a specific renewal email and create a CRM follow-up task
Evidence: last support thread, usage drop, renewal date, account owner's note
Risk: review required because the message mentions a service commitment
Owner: account owner
Expiry: 24 hours
Re-check: do not send if the customer replied, renewal status changed, or another task already exists
Log: save final email, approval decision, evidence, and outcome to the account timeline

That is reviewable business execution. The agent did useful work, but the human is not approving a black box. They are approving a concrete side effect with evidence and boundaries.

Checklist before agents touch live systems

Define which action types are low-risk, review-required, sensitive, or blocked.
Require a proposal envelope before any external side effect.
Route proposal envelopes through one approval inbox or shared review contract.
Add expiry times for approvals.
Use idempotency keys for sends, record updates, refunds, invites, and task creation.
Re-check state immediately before execution.
Log the proposal, evidence, policy decision, reviewer, action result, and failure state.
Measure cost and outcome by completed goal loop, not by number of agent runs.

If those pieces are missing, the next improvement is not a more powerful agent. The next improvement is a better operating contract around the agent.

At Manor AI, this is the workspace layer we are designing around: agents, skills, context, approval gates, policy checks, evidence logs, and goal loops that make business execution reviewable.

Originally published on the Manor AI blog: https://manorai.xyz/blogs/blog-ai-agent-policy-checks-proposal-envelope

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.
``