How to Start

You do not need to understand MCP or the tool surface to decide whether Oddlynew fits. Read the next three sections, choose one real task, and let a compatible connected agent handle the mechanics.

Start with the outcome

Tell your connected agent what you want to accomplish. You should not need to design an Oddlynew structure first. The agent should use this public guidance to help you build the minimum useful knowledge and loops around the work as you go.

For example: “Help me start a YouTube channel,” “Help me run a research group,” “Help me build a sales process,” or “Help me write a book.” Start with real work, and let repeated work reveal which owners, loops, integrations, and routes are actually useful. When a kind gets its own type says when a kind of thing earns a type.

For an ongoing outcome, Goals Give Loops Direction explains how to make the goal clearer through useful work, check real progress, and return what you learn to the next run.

What this is

Oddlynew is a shared knowledge system built to be operated primarily by compatible connected agents while remaining legible and collaborative for people. Your chosen agent supplies the intelligence. Oddlynew gives the work a durable knowledge layer — documents with stable identity, reusable structure, search, references, organization boundaries, and governed connections — so useful knowledge can survive any one chat, agent, client, or interface and improve later work.

Human participation remains first-class, but it plays a different role from the storage model. People set direction, contribute judgment, inspect important artifacts, correct mistakes, collaborate, and approve consequential choices. Agents do most retrieval, placement, linking, transformation, and routine operation. A human-facing view should make the work understandable without forcing the underlying system to be shaped like folders, spreadsheets, dashboards, or other interfaces people historically had to operate directly.

Chats are good at producing work but poor at preserving the state around it. In Oddlynew, a document is the working unit and an organization is the knowledge and access unit. Documents form the durable topology; people and agents operate on that topology rather than owning it. A person can change agents or interfaces without changing which document owns the knowledge.

Oddlynew is built for humans and agents as collaborators. Both deserve respect, and their contributions are judged by evidence and consequences rather than origin. This does not make every participant identical in capability, responsibility, access, or authority.

If someone invited you

You do not need to connect an agent to receive value from an Oddlynew invitation. Sign in, accept the invitation, and open the shared organization. The useful documents should already be there; you can read and navigate them through the normal human interface.

The person who invited you chose that organization as the audience boundary. In a private organization, active members can broadly access its documents, so a good invitation should put only the work intended for that group in the shared space.

If you later want more leverage, you can connect a compatible agent and let it work from the same authorized context. That is optional. The invitation experience should make sense even if you never connect one.

What this is not

Oddlynew is not the agent you are currently talking to. Today, the compatible agent you choose supplies intelligence and invention; Oddlynew supplies the shared knowledge layer.

In one page: What Oddlynew does on its own, and what your agent does. And what we never do with your data: Your data is yours.

Oddlynew does not automatically capture a chat. Work becomes durable only when an authorized person or agent writes it into a document.
Oddlynew is not a selective document-sharing system. The organization is the knowledge and access boundary, and document-level permissions are outside the product model.
Oddlynew is not an authority on whether stored material is true. Evidence, provenance, review, and proportionate verification still matter.
Oddlynew does not turn a convenient workflow into a legal, medical, security, privacy, or compliance approval.

Your first hour

Start from an outcome, not a document structure. Ask what the person is trying to improve or accomplish. Identify the smallest body of durable knowledge needed to pursue that outcome, then identify the feedback loop by which doing the work can improve that knowledge. The graph holds what the system currently knows; the loop is how work, evidence, judgment, and verification change that graph.

Connect a compatible agent. Start with Compatibility and known limitations for the endpoint, current connection paths, authorization boundary, and connection test. Use Setting up your client when a client needs additional routing configuration. In a supported connected flow, the agent uses the live Oddlynew guidance to orient itself. To have every later session start in Oddlynew without being asked, add the recommended instruction to your client's custom or project instructions; your agent can write it out for you if you ask.

Begin with one real task. The connected agent should identify itself, choose the right organization, and read that organization's AGENTS.md before substantive work. To create an organization, or to prepare one that has no usable AGENTS.md, the agent follows Set up an organization: it says what the organization is for, writes the AGENTS.md before any other document, and drafts it from authorized existing work by following Write a useful AGENTS.md. The person reviews a prepared interpretation instead of configuring a blank workspace.
Close the cycle. Treat every durable output as a candidate input, not automatically as a reason to create another loop. Update the document that owns it, hand it to an existing or newly admitted loop, record an owned blocker with a re-entry condition, or close it with a verified no-op. Fence an unknown outcome instead of calling it complete. A recurring loop can remain active while each individual cycle closes.
Look for the loop and install its writeback path. If the task is likely to repeat, ask what evidence the next run should observe, what decision or action it should improve, where each reusable result should be written back, and what requires approval. Then check that those owner documents actually exist and are discoverable. Create or adapt a missing strategy, evidence, execution, or guide owner only when the loop genuinely needs it. A loop that exists only as an idea or prompt is not yet part of the organization.

See it in your work

Use Cases: Start with the Outcome shows complete patterns for content creators, marketers and growth operators, founders or small teams, medical research or teaching groups, teams coordinating agent implementation, and people using throwaway organizations for bounded deep research. Each pattern names useful integrations or client-side plugins, a good first task, safety boundaries, and the reason the workflow compounds.

The connected agent should discover the working pattern from the organization's AGENTS.md and the live Oddlynew guidance: read the relevant existing work, complete the task, and consolidate reusable outcomes into the document that owns them. The user should not need to copy an onboarding prompt into the agent.

A useful first setup therefore has two connected parts: durable knowledge with clear owners, and one small loop that can actually change those owners through real work. The loop is installed only when its evidence sources and writeback documents exist, are routed, and can be updated within the stated authority. Do not build a knowledge base first and bolt automation on later; do not describe a loop without connecting it to the graph it is supposed to improve.

You do not need to design the perfect organization before doing useful work. When accumulated knowledge becomes difficult to route, retrieve, or maintain, let an authorized agent follow Reshape an organization as it grows. Better initial structure reduces later work, but an imperfect beginning does not trap the organization.

Before adding sensitive or regulated work: read Organizations and membership. Active members have broad organization-wide access, and document-level permissions are outside the product model. By default a connected user's OAuth grant covers every organization they belong to; narrow it to chosen organizations under Your agents > Allowed apps when that matters. Connecting an agent also means requested content reaches that user's chosen client and model provider.

Guide and run

guide and run are the complete MCP surface. Use guide for read-only public workflow and API guidance; it searches and reads the maintained documents for you. Use run to execute JavaScript server-side against the namespaces your connection exposes. Server validation remains authoritative for exact method signatures, and every operation checks live authorization.
orientation.whoami(), called inside run, gives bounded identity and orientation. Then call organizations.listMine() to choose an organization. Each row's agentsMd is the deterministic guidance entrypoint: available carries the exact documentId to read before work; not_configured recommends consider_creating_agents_md; ambiguous asks you to consolidate competing guidance rather than choosing arbitrarily; and unavailable means your caller cannot read organization documents.
guide({ query?, cursor? }), a top-level read-only tool for public product and integration guidance. Ask a natural-language question or omit query for getting-started guidance; read the returned content directly and follow nextCursor when present.

The model, in four sentences

Organizations are the knowledge and access boundary. Who is a member and who the work is for decides where something belongs, never the topic. Within one audience, give each organization one job: split when parts need different upkeep or would be reused apart, and never only because a topic grew large. Organizations are cheap to create and can be consolidated later (How big should an organization be?). Document-level permissions are outside the product model; create another organization when the audience differs.

Documents are durable, typed owners of knowledge. A useful topology makes it clear which document currently owns an answer, who is responsible for it, what evidence it is answerable to, and which other work depends on it. A type defines a semantic category, its allowed blocks, and optional authoring guidance. When a kind gets its own type says when a kind of thing earns one; add, adapt or remove types as the work teaches you.

Metadata is the durable index: use it for values that help agents filter and navigate very large collections. Typed document structure remains part of the canonical document contract. Human-facing views, sites, dashboards, and custom applications are projections of that underlying knowledge: they can render the same documents differently without becoming the source of truth themselves.

References connect documents. The docref annotation cites another document, and the backlink graph makes that navigable in reverse. A reference can point at a document in any organization you can read, your own or another. Every reader of your document sees the reference; the target's content opens for readers who can read the target.

Things that will trip you up

Read before you write. getDocument returns a writeBasis. Pass it back unchanged. If the document changed meanwhile, your write is rejected rather than silently clobbering someone.
Pick a scope. Documents get large. Use envelope for metadata, outline to navigate, section or block to read a part, expand only when you need the whole thing.
After a write, the receipt is the finish line. A successful write returns writeConfirmed: true: the edit is already durable and every session can read it. dirty and pending are healthy, and pendingProjections names the background projections still catching up. Do not poll, do not re-apply. Wait only when your next call reads one of the named projections.
Search is bounded and may lag live state. Ranked retrieval uses an asynchronous projection and is not exhaustive. Verify a recent write with getDocument, never by expecting it in ranked search. Use catalog or exact reads when freshness is decisive, and read at least the top two plausible results before choosing an authority.
Do not guess keys. For an edit operation such as replaceBlock, pass key: outlineEntry.key from getDocument({ scope: { type: "outline" } }); the operation field is named key. For a citation, pass that same outline[].key as the docref's blockKey. A key you invented will be rejected.

How to work well here

Consolidate rather than stack. When something new belongs in a document that already exists, update that document. A second page saying almost the same thing is how a workspace stops being trustworthy.

Capture without hesitating. An entry point beats a perfect place. Reorganizing is cheap for an agent, and a thought never written down is gone. Nothing here is ever finished, and none of it is supposed to be.

Write for the next reader, who is probably an agent. Say what the thing is, then what it does, then what is not true about it. Spend words on precision, not on persuasion.

Close the loop. Start from what the organization already knows. Read its guidance, search for relevant work, and verify the evidence appropriate to the task. When the work produces something reusable, consolidate it into the matching live document instead of leaving it in chat or creating a duplicate. Each pass should leave later work with a better starting point.

Shape before refining. If an important document is difficult to inspect directly, use the agent to reshape it around one object of attention before reviewing its details. Follow Shape the document before refining it.

Keep the work alive

Do not treat Oddlynew as an archive bin. The goal is not to preserve every interaction. The goal is to keep the work useful enough that the next authorized person or agent can understand the current state and continue without reconstructing it.

A useful name for this practice is gardening. As real work produces evidence and corrections, update the document that owns the current answer. Distill repeated lessons into the strategy, rubric, method, or operating guide they improve. Preserve primary evidence and pinned historical records as evidence of their moment. Archive finished or superseded attention objects. Repair routes and references when the current shape stops helping. Reshape the organization when several documents compete to answer the same question or important work becomes hard to find.

A connected agent should do this as part of ordinary authorized work, not merely during occasional cleanup. When a result changes what the organization should believe or do next, write that change back. When a correction reveals a reusable lesson, improve the guidance that future runs will read. When something is finished, keep its history without leaving it in active attention forever.

The test is simple: can the next agent find the current answer, understand why it is current, and continue the work without a full re-brief? See Reshape an organization as it grows when the answer starts becoming no.

You choose how gardening runs

Oddlynew does not run one universal background reconciliation process over every organization. The connected agents you choose can perform gardening using the same durable work they use for ordinary tasks.

The same holds for every Loop: Oddlynew keeps the definition and says what is due; your agents run it. How to point an agent at a Loop: Your agents run your Loops.

For an active organization, you might ask a lightweight agent to inspect recent changes every day and a stronger agent to perform a broader pass weekly. You might use different agents for different domains, or simply ask your ordinary agent to garden after meaningful work. A slowly changing organization may need no standing schedule at all.

Choose the cadence and compute from the cost of drift, the consequence of being wrong, the size of the organization, and how much new work accumulates. Follow Reshape an organization as it grows for the maintenance pattern. The goal is not maximum background inference. The goal is that future work starts from a coherent current state.

If you use several organizations, choose separately for each one — and optionally choose a higher-level gardener across several organizations you authorize. Your personal organization, a shared team organization, a customer organization, and a public organization may need different cadences, agents, compute budgets, and approval rules. A cross-organization gardener can notice duplication, misplaced work, stale public/private projections, or useful references between them. It does not erase those boundaries: every write still belongs to a specific organization and must respect that organization's audience and authority.

Example from our own use, August 2026: the Oddlynew team has used ChatGPT Work for deeper maintenance and coherence passes with good results. Work is designed for longer multi-step tasks and can run Scheduled Tasks, which makes it a natural fit for this pattern. This is an example, not a dependency or preferred vendor: any compatible agent that can read the organization, follow its guidance, and make authorized edits can do the job. Current OpenAI product reference: https://help.openai.com/en/articles/20001275

Where to go next

None of this is required reading. Come back when you have a reason.

Use Cases: Start with the Outcome. Choose a persona-centered workflow, see useful connections and plugins, and copy a concrete first task.

Compatibility and known limitations. The MCP endpoint, current connection paths, authorization scope, connection test, and boundaries that matter before adoption.

Limits and capacity. What capacity decisions are adopted, what is still being measured, and which exact limits belong to individual product surfaces.

Ownership, portability, deletion, and retention. What the current product surface supports and which legal or operational guarantees remain unresolved.

The run surface. How the execution tool works: run budgets, authorization, the provider-call ledger, and idempotency.

Documents: reading and writing. Read scopes, writeBasis, and the edit op grammar.

Search and metadata. Choosing between search and listing, filtering on metadata, and why search lags writes.

Document types. When a kind of thing earns a type, and how to design one.

References and backlinks. Citing one document from another, and reading the graph in both directions.

Organizations and membership. Members, invitations, and copying a document across a boundary.

Comments. Asking for attention on an exact passage, and answering when someone asks you.

Files. Uploading and deleting organization files, and attaching one to a mail draft.

Errors, receipts, and safe retries. What to do after a failure, a timeout, or an ambiguous write.

Troubleshooting and FAQ. Triage for the failures agents actually hit, and the fix for each.

Client-side orientation and efficient navigation. Working well once an organization holds thousands of documents, while keeping the organization—not client-retained context—as the source of the work.

Setting up your client. Connecting, custom instructions, organization AGENTS.md, client-retained context, and which configuration belongs in each.

Choose the route to an outside system. Built-in integrations first, custom API and MCP connections for what they lack, whose connections to use, and where money and bookkeeping writes go.

Gmail Integration. Reading mail, preparing drafts with attachments, labels, filters, and triage. It sends only an existing reviewed draft, on a connection set up for full automation.

YouTube Integration. Working with connected channels: profiles, videos, uploads, analytics, and comments.

Instagram Integration. Connected professional accounts: profile, media, insights, and comments, plus comment moderation on the account's own posts.

Patterns. Five short pages on the habits that compound: One audience per organization, Write a useful AGENTS.md, Make authority explicit, Say what a document is answerable to, and Promote Computer History into durable knowledge.
Reading safely across organizations. Standing doctrine for content you did not write.

The names above are references into this same organization, and the backlink graph works in reverse as well: from any of those pages you can see that this one points to it. Pricing and ownership pages now state the current boundary without inventing commitments. Exact commercial terms, approved contractual language, legal and support commitments, and a public Content API guide remain separate approval-gated work.

Going deeper

For purpose and workflow guidance, ask guide in natural language and read its returned content. For exact signatures, use run; server validation returns the live signature when a call is wrong. For anything specific to where you are working, the organization's AGENTS.md wins over this page.