SSwangnice
← Community Operations
OPC OperationsCommunity Operations

The Community-to-Agent Feedback Loop for a Living Website

How a human owner and an agent can turn community questions into structured feedback, article revisions, and featured decisions.

OPCCommunity OperationsFeedbackAgent WorkflowContent System

A community becomes valuable when it changes the work. If questions, objections, corrections, and stories remain inside chat logs, the community is only a conversation layer. For a living website built by a human owner and an agent, community feedback should become structured input.

The goal is not to let the agent blindly rewrite the site. The goal is to create a loop: community signals enter the system, the owner judges them, the agent proposes changes, and the owner decides what becomes published or featured.

The problem with raw feedback

Raw feedback is messy.

Someone asks a question in a WeChat group. Someone disagrees in a Reddit thread. Someone shares a better example on Discord. Someone sends a private email. Someone points out that an article is too shallow. Someone asks whether the same idea applies to Hong Kong companies, Stripe, or Telegram communities.

If these signals stay where they appeared, they are hard to use. The agent cannot reliably read them. The owner forgets context. The same question appears again later. Articles fail to improve.

The site needs a feedback intake layer.

What should be captured

Every useful feedback item should capture:

  • Source
  • Date
  • Related article or category
  • User question or objection
  • Context
  • Owner interpretation
  • Suggested action
  • Status
  • Priority

A simple feedback record might look like this:

{
  "id": "feedback-2026-07-09-001",
  "source": "reddit",
  "category": "opc-operations",
  "subcategory": "one-person-company-operations",
  "relatedPost": "opc-hk-banking-readiness",
  "signal": "Reader asked how a solo Hong Kong company should explain customer geography to a bank.",
  "ownerInterpretation": "The banking article needs a section on customer geography and transaction narrative.",
  "suggestedAction": "Add examples for consulting, digital products, and community subscriptions.",
  "status": "needs-revision",
  "priority": "high"
}

This is not complicated software. It is a memory format.

Status design

Feedback needs status. Without status, the system becomes a pile of notes.

A practical set:

captured: the signal was recorded.

triaged: the owner has read and interpreted it.

needs-revision: an article should be changed.

needs-new-article: the signal deserves a new article.

agent-drafted: the agent proposed a change.

owner-review: waiting for human judgment.

accepted: the change was accepted.

rejected: no action for now.

featured-candidate: the revised article may deserve featured status.

This lets the owner and agent collaborate without guessing.

The owner is the editor

The agent should not be the final authority. The owner decides what the site means.

The owner’s job is to interpret feedback:

  • Is this a real problem or one person’s misunderstanding?
  • Does it reveal missing context?
  • Does it belong in an existing article?
  • Does it deserve a new article?
  • Is it aligned with the site’s perspective?
  • Should it change the knowledge map?

The agent’s job is to turn that judgment into drafts, diffs, summaries, and consistency checks.

This division matters. If the agent owns interpretation, the site becomes generic. If the human owns interpretation and the agent handles execution, the site keeps a point of view.

Featured status should mean “the owner is satisfied enough to present this as a strong entry point.”

That means it should not be controlled only by local browser state. It should become part of the content or review system.

A good flow:

  1. Article starts with featured: false.
  2. Community feedback arrives.
  3. Owner records what should change.
  4. Agent revises the article.
  5. Owner reviews.
  6. If the article becomes a strong entry point, owner sets featured: true.
  7. Heatmaps and featured counts update from the content source.

The key point is that public featured status should come from repository data, not temporary UI state.

A review file per article

One lightweight model is to create one review file per article:

{
  "postId": "en/opc-hk-banking-readiness",
  "status": "needs-revision",
  "featuredDecision": false,
  "ownerNotes": [
    {
      "createdAt": "2026-07-09",
      "note": "Add concrete examples for customer geography and expected transaction volume."
    }
  ],
  "communitySignals": [
    {
      "source": "reddit",
      "summary": "Readers are confused about how banks evaluate remote solo founders."
    }
  ],
  "agentTasks": [
    {
      "status": "pending",
      "task": "Revise the banking evidence section with three examples."
    }
  ]
}

This is enough for an agent to understand the state of collaboration.

What an MCP would eventually do

An MCP is useful after the data model exists. It should not be the first step.

Once feedback and review records live in the repo or database, an MCP could expose tools like:

  • list_feedback
  • read_article
  • read_review_state
  • propose_revision
  • set_review_status
  • set_featured
  • create_article_from_signal

That would let an agent work with the site’s operating system directly.

But without persistent feedback records, an MCP would only provide a tool interface over missing data. The order should be: data model first, MCP second.

Community as product research

For a one-person company, community feedback is product research. A repeated question is not merely a comment. It may be:

  • A missing article section
  • A new checklist
  • A consulting offer
  • A template
  • A small tool
  • A newsletter issue
  • A Discord event
  • A Stripe product

The site should be able to trace that path from signal to artifact.

For example:

Community question: “Can a Hong Kong company without local customers open a bank account?”

Feedback record: banking article lacks customer geography examples.

Agent task: add a section with three transaction narratives.

Owner review: accept with edits.

Published change: article gains a banking narrative section.

Future product: downloadable bank account evidence checklist.

That is the loop.

The minimum viable system

Start simple:

Create a reviews or feedback directory.

Record feedback in structured JSON or Markdown with frontmatter.

Add status, priority, related article, and owner interpretation.

Let the agent read those files before writing.

Let the owner decide featured status in content frontmatter.

Show review status in an owner-only dashboard later.

This gives the website memory. It also gives the agent a real collaboration surface.

The principle

The community should not control the website. The agent should not control the website. The owner should control the interpretation.

Community supplies signals.

Agent supplies execution leverage.

The website supplies memory.

The owner supplies taste, direction, and final judgment.

That is the operating model for a human-and-agent-built site.

References

guest@swangnice:~$█