Knowledge for AI agents

Agents that know your business. And remember the conversation.

Give each agent the documents it should always have, let it read and write files as it works, and keep a conversation going across calls without storing the history yourself.

The problem

A model knows the internet. It does not know you.

Your pricing, your refund policy, your tone of voice and last week's plan are not in any model. Pasting them into every request is slow and easy to get wrong, and a chat that forgets the previous message is no use to a customer. The agent needs the right material at the start of every run, a place to keep what it produces, and a memory of the conversation it is in.

  • Reference material. The documents the agent should treat as the source of truth.
  • Working files. Plans, lists and drafts it reads and writes as it goes.
  • Conversation. The earlier turns, so a follow-up question makes sense.

Resources

One library of files for every agent.

Resources is the workspace's file library. Upload a file or drag it onto the page, write one in the built-in editor with New file, and group files into folders. Each file can be up to 10 MB.

  • Text and Markdown. .txt, .md and .markdown, for policies, notes and plans.
  • Data. .csv and .json for reference tables, and Excel files, converted to CSV on upload.
  • Images, for your apps. .png, .jpg, .gif and .webp, stored for integrations that attach them, such as an image on a post. Agents do not read image contents.

PDF is not supported: export the text to a .txt or .md file first.

Knowledge

Choose what each agent always knows.

On an agent's Knowledge tab, switch on the files it should have. At the start of every run, the attached files are added to its instructions as reference material the agent is told to treat as authoritative.

Attached files share a budget of 200 KB per run, and a file that does not fit is skipped rather than cut off. Because every attached file is sent with each model call, the budget also keeps token costs in check: attach what the agent needs every time, and let it read the rest on demand.

Files at work

Read what it needs. Write what it makes.

Two built-in tools let a hosted agent work with Resources during a run.

  • read_resource reads a file by name, only when the agent needs it. Large or rarely used files belong here rather than in the per-run budget.
  • write_resource creates or overwrites a file: a weekly plan, a list of leads, a draft for a person to read. Files written during a run show as that run's artifacts.

Files can also be listed, written and deleted from code through the control plane, or from any MCP client.

Memory

Conversations that carry on.

For a chat or a support bot, start a session on the first call. AgentOS returns a session id; pass it on the next call and the agent sees the conversation so far, without your code storing anything.

The agent sees the latest 30 messages, and a conversation is deleted 24 hours after its last message. You can tag a session with your own id for the end user it belongs to. If your app already stores its threads, send the earlier turns with each call instead, up to 50 of them, and AgentOS keeps nothing.

Prompt variables

One agent, the right values for each caller.

Write {{SHEET_ID}} or {{API_URL}} in an agent's instructions and fill it in when the agent runs, instead of hardcoding it. Each variable has a description, so callers, MCP clients included, know what to supply, and an optional default value.

A value passed with the call wins over the default. Scheduled runs use the defaults, so give any variable a scheduled agent needs a value on the agent.

What you get

Context you control, and can see.

  • Nothing attached by accident. Uploading a file does not give it to any agent. Only the files you switch on are sent.
  • Remove without deleting. Detach a file from one agent and it stays in Resources for the others.
  • Conversations you can manage. List, read and delete conversations from code, or clear an agent's whole history from its settings.

In our own workspace

Our social posts live in Resources.

Our weekly Social Content agent drafts the week's posts and saves them as files in Resources. A second agent picks them up from there.

Daily LinkedIn Post runs every weekday. It reads the day's post from that file and prepares to publish it to our company page.

Case studyEvery post on our LinkedIn page is drafted by an agent and approved by a person

Give one job to an agent this week.

Start with one repetitive workflow, gate the sensitive step behind your approval, and read the first run end to end.