Agents for Community Managers: Part 1

An open, portable agent stack for community operations using AGENTS.md, goose, and MCP.

Community programs generate a surprising amount of operational work. An in-person meetup can involve registrations, attendee review, check-in, follow-up messages, and reporting. An online community adds chat, email, moderation, and activity analysis across several systems.

This is exactly the kind of repeated, tool-heavy work that agents can help with. It is also work involving personal data, community trust, and decisions that should not be delegated casually.

This article answers "How do we design an open agentic workflow whose instructions, tools, and human boundaries are clear"

This article begins with three projects hosted by the Agentic AI Foundation:

1. AGENTS.md for durable project instructions and boundaries.
2. goose for executing reusable workflows.
3. MCP for connecting those workflows to external systems through explicit interfaces.

The three layers solve different problems. Keeping them separate makes the workflow easier to inspect, test, and move between compatible tools.

The Three-Layer Model

Layer	Responsibility	Community operations example
AGENTS.md	Durable context, rules, and verification	Privacy rules and approval boundaries
goose	Repeatable execution	A recipe that prepares a check-in follow-up queue
MCP	Data and external capabilities	Reading event check-ins or preparing an email outbox

The task-specific request sits above all three layers. Human judgment surrounds them.

Layer 1: Put Durable Policy in AGENTS.md

AGENTS.md is an open format for project-specific instructions used by coding agents. A community operations repository may contain event briefs, message templates, review criteria, scripts, and reports. That makes it a practical home for agent-facing instructions too.

A small community operations file might include:

# Community Operations Instructions

## Sources of Truth

- Use the current event brief in `events/<event>/brief.md`.
- Use the documented criteria when reviewing applications.
- Treat published schedules as authoritative over working notes.

## Privacy and Safety

- Treat applicant, attendee, and member information as private.
- Never expose credentials, private links, or personal data in reports.
- Never send messages or change a person's status without explicit approval.

## Verification

- Separate observed facts from recommendations.
- Cite the source and coverage window behind every metric.
- Read back changed records and report exactly what was updated.

This is not the whole workflow. It is the operating contract that every workflow in the project should follow.

That distinction keeps AGENTS.md maintainable. Event-specific parameters, tool credentials, schedules, and long procedures belong elsewhere.

Layer 2: Make the Procedure Reusable with goose

goose is an open source agent that supports AGENTS.md, skills, MCP extensions, recipes, and scheduled recipes. A recipe can package instructions, parameters, required extensions, an initial prompt, and a response schema into a reusable YAML file.

For example: for a meetup check-in workflow, a recipe I define looks like this:

• the event identifier as a parameter
• the meetup-ops MCP extension it is allowed to use
• instructions to prepare an outbox rather than send messages
• a structured result containing counts, exceptions, and the ledger location
• a stop condition when records are incomplete or inconsistent

The recipe provides orchestration. It can call the allowed tools in sequence, check their results, and produce an artifact for review. If the workflow runs periodically, the same validated recipe can be scheduled instead of reconstructing the procedure each time.

The procedure, hence, is shareable. Another organizer (or my team) can inspect the recipe, see which capabilities it requires, supply their own event identifier, and understand the expected output before running it.

Layer 3: Be Precise About What MCP Provides

Model Context Protocol (MCP) is the protocol boundary between an AI application and external capabilities.

In MCP's client-server architecture, goose acts as the host. It creates an MCP client connection to each configured server. A community operations server can then expose three kinds of primitives:

• Resources provide contextual data that can be read, such as an event brief or review criteria.
• Tools perform queries or actions, such as listing checked-in attendees or preparing an outbox.
• Prompts provide user-invoked templates for common interactions.

That vocabulary lets us design the interface instead of vaguely saying that MCP "connects everything."

A Concrete Meetup MCP Interface

I already use a direct API workflow that polls an event platform for approved guests with a check-in timestamp, assigns one unique benefit code per new attendee, writes pending messages to an outbox, and records assignment and delivery state in a durable ledger.

That workflow is not an MCP server today. It is a strong candidate for one because its boundaries are already visible.

An initial meetup-ops server could expose:

Primitive	Name	Behavior
Resource	meetup://events/{id}/brief	Current event context without attendee records
Tool	list_checked_in_attendees	Read approved attendees whose check-in timestamp is present
Tool	prepare_delivery_outbox	Assign each new attendee once and prepare unsent messages
Tool	get_delivery_ledger	Return assigned, pending, sent, and exception counts
Tool	mark_delivery_sent	Record the external message identifier after a confirmed send
Prompt	prepare_checkin_followup	Guide a user through preparing the queue for review

I would not expose a bulk-send tool in the first version. Preparing and sending are different risk levels and should remain separate capabilities.

The read tool can advertise MCP tool annotations like these:

{
  "readOnlyHint": true,
  "destructiveHint": false,
  "idempotentHint": true,
  "openWorldHint": true
}

Annotations help clients describe risk, but the MCP specification treats them as hints. The server must still enforce its guarantees. For example, prepare_delivery_outbox should use durable state so running it twice cannot assign two codes to the same attendee. mark_delivery_sent should accept the same message identifier repeatedly without creating duplicate state.

Transport, Authorization, and Data Scope

During local development, the server can run over standard input/output. A shared remote server would normally use Streamable HTTP and authorization appropriate to its users.

For attendee data, authentication alone is not enough. The server should also:

• request the smallest useful scopes, beginning with read-only access
• validate that tokens were issued for the MCP server
• avoid passing client tokens directly to an upstream event or email API
• return only the fields required by the workflow
• keep credentials and sensitive ledgers out of prompts and logs
• emit structured results that can be tested and audited

The MCP Inspector can then verify tool discovery, input schemas, outputs, error handling, and edge cases before the server is connected to a recipe.

What Still Belongs to a Human

Open interfaces do not remove accountability.

A human should still decide whether review criteria are fair, resolve ambiguous identities, approve recipients, inspect outbound copy, handle exceptions, and interpret what community activity means. A fall in message volume is an observation. It is not proof that a member is disengaged or unhappy.

The system should automate collection, repetition, and bookkeeping. It should make human decisions easier to review, not hide them inside an autonomous pipeline.

References

• AGENTS.md: https://agents.md/
• goose recipes: https://goose-docs.ai/docs/guides/recipes/
• goose MCP extensions: https://goose-docs.ai/docs/getting-started/using-extensions/
• MCP architecture: https://modelcontextprotocol.io/docs/learn/architecture
• MCP server concepts: https://modelcontextprotocol.io/docs/learn/server-concepts
• MCP server quickstart: https://modelcontextprotocol.io/docs/develop/build-server
• MCP Inspector: https://modelcontextprotocol.io/docs/tools/inspector
• MCP security best practices: https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices