Point each agent at its organization: your setup makes Oddlynew useful
Oddlynew gives you building blocks for knowledge work: organizations, documents, types, Lenses, Loops and connections. How useful it is depends on how you set your agents up to use them. The most important part of that setup is telling each agent where its work starts: which organization, and for a dedicated agent, which job.
Why it matters
Most people who use Oddlynew belong to several organizations and work with several agents: a coding agent in a repository, a chat assistant, a few dedicated agents for research or support. An agent with no pointer may not use Oddlynew at all, or may write into whichever organization it found first. A pointer costs one sentence and decides where the work lands and which rules the agent follows.
The patterns
A code repository: one line in its AGENTS.md. Name the organization the work belongs to:
Oddlynew organization: <organization id>. Every session in that repository starts there: it reads that organization's AGENTS.md, finds its Tickets and decisions, and writes its results back. The agent still knows your other organizations; the line only says where to start.A chat assistant: one line in its instructions.
Use Oddlynew as my knowledge base. Oddlynew organization: <organization id>, in the client's custom or project instructions (Setting up your client: the recommended instruction).A dedicated agent: its job, its organization and its kind of document. An agent you run for one job gets instructions that say all three, for example: "You are our market research agent. Use Oddlynew organization <organization id>. Read its AGENTS.md first. Save every source you find there as a Market Source document, with its link and the date you read it." A support agent, a writing agent or a reviewing agent each gets its own version.
A session across several organizations: name the home one first. The first organization named is where the session's own work lives; each other organization's AGENTS.md applies to work there (Work across several organizations).
Recurring work: a Loop and the agent that runs it. Point the agent at the Loop rather than describing the work again (Your agents run your Loops).
Put the rules in the organization, not the agent
Keep each agent's instructions to the pointer and its job. How the work is done, what goes where and what needs a person belong in the organization's AGENTS.md, where every agent and every person reads the same rules and anyone can correct them. One agent's private instructions drift; the organization's rules stay shared.
Let your agent set it up
You do not have to write any of this yourself. Ask your agent: "Look at my Oddlynew organizations and the agents I use, and suggest which organization each one should start in and what one line each needs. Then write the lines with me." The guidance it reads is the same as this page.