Teaching an OS your company facts without training a model

Use memory for company facts, not fine-tuning

Company facts belong in memory and retrieval first. Fine-tuning is for behavior that should persist. Pricing rules, account constraints, legal wording, owner names, support steps, and offer limits should live outside the model, where your team can edit them, attach approvals, and remove stale facts.

This article is for teams building agents that answer support questions, draft renewal emails, prepare sales notes, or route internal work from company knowledge. The end state is an agentic OS that reads governed company facts at run time, then stops at a gate before money, legal exposure, customer sends, or data deletion.

The common question is, “How do we train a model on our company?” That question hides three separate jobs. The agent needs to find approved knowledge. It needs to remember useful state across work. It needs to know when a human owner must approve an action. Training a model is only one possible answer, and often the wrong one for facts.

Agentik’s public material describes the agentic OS category as one line of work with a named owner, a shared memory, and a gate. It also says an agentic OS is not a PC operating system and not a personal assistant. That distinction matters. The OS claim is about organizing work, memory, and approvals around a model. It is not a claim that company truth should be hidden inside model weights.

The practical design is blunt. Keep mutable company truth in systems people can inspect. Index the parts an agent may use. Attach permissions. Summarize only what helps the next run. Log which source supported the answer. Stop before the agent sends, discounts, refunds, deletes, or promises anything that needs a named owner.

The symptom is stale confidence

You can spot the wrong architecture from the symptom. A seller asks an agent for a renewal email. The agent remembers last year’s pilot rule and offers a 15 percent discount. Finance changed the threshold to 12 percent. Sales operations updated the source system. The model never saw the change.

The same failure appears in support. An agent tells a customer to submit a payroll correction with three fields. The policy now requires four fields because compliance added a reason code. The answer sounds confident because the model has no built-in sense that a company process expired after last quarter’s review.

These are live business facts. They need owners, timestamps, source documents, permissions, and expiration. You do not want a model to permanently “know” that Redwood Foods prefers email-first quarterly business reviews if the account plan can change this afternoon.

Fine-tuning also hides evidence. A model answer may be shaped by training examples, but the user cannot inspect a weight and see which policy caused the answer. When the answer is wrong, the recovery path is vague. Was the source stale? Was the example ambiguous? Did the model generalize too far? Was a later policy missing from the training set?

External memory gives you a smaller debugging surface. If the renewal draft includes the wrong discount rule, you can inspect the memory file, connector item, source document, retrieval result, approval gate, and prompt. You may still find a model error. But you have places to look before blaming the model.

This does not make memory magic. Memory can be stale too. It can overgrow. It can include sensitive data. A tidy folder tree can imply safety it does not enforce. The narrower claim is stronger: mutable company facts need a mutable control plane.

Separate session, run, and store memory

Treat company knowledge as several stores, not as one giant context blob. A useful agentic OS separates at least three kinds of memory: session memory, run memory, and store memory.

Session memory is the short-lived context of the current conversation or task. It helps the agent resolve pronouns, carry a draft forward, and avoid asking the same question twice. It should be cheap to discard. A chat transcript can serve this job during one interaction, but it is a weak place to keep company policy.

Run memory is the trace of work done during a task or workflow. It may include tool calls, intermediate summaries, approvals requested, approvals received, rejected drafts, and final outputs. It helps with audit and with the next step in the same line of work.

Store memory is durable. It survives closing the laptop. Agentik’s public material uses this distinction and gives a plain test for store memory: tell the system a fact, close everything, return later, and see whether it still knows it. That test is useful because many systems appear to remember while a chat window is open and forget when the session ends.

For company facts, store memory is the useful and dangerous layer. It can preserve customer preferences, approval thresholds, positioning rules, routing instructions, and prior decisions. It can also preserve a once-true constraint after the source changed. Agentik’s public material names that failure mode as stale truth.

A good store memory record is more than a sentence. It should carry a source, owner, scope, last reviewed date, and deletion rule. A bare fact such as “discounts above 12 percent require VP Sales approval” is less useful than the same fact tied to Sales Operations, a policy document, an effective date, and a gate.

The OS layer earns its place when it can mount the right knowledge for the job, not when it stuffs every fact into the prompt. The agent needs rules for who may read a fact, when the fact expires, what source overrides it, and what action it can authorize.

A memory map for company facts

Here is a concrete pattern for a company memory layout. The example is hypothetical. Northstar Payroll is a made-up B2B company that wants agents to draft renewal emails, support replies, and internal battlecards without training a model.

The company facts are ordinary. Northstar Payroll serves US mid-market employers with hourly workforces. The legal team prohibits same-day tax filing claims unless legal approves. Redwood Foods prefers quarterly business reviews by email before a call. Discounts above 12 percent require VP Sales approval. Payroll correction requests must include pay period, employee ID, and correction reason.

A memory map for that company can be represented as an inspectable config, not as training data:

memory_root: /memories summary: /memories/memory_summary.md stores: - path: /memories/company/positioning.md owner: Product Marketing scope: approved claims and prohibited claims source: product-marketing-approved-positioning review: monthly - path: /memories/company/legal-claims.md owner: Legal scope: regulated wording and claim approvals source: legal-claims-register review: monthly - path: /memories/customers/redwood-foods.md owner: Account Executive scope: account preferences and renewal notes source: account-plan-redwood-foods review: before renewal work - path: /memories/sales/discount-policy.md owner: Sales Operations scope: approval thresholds source: sales-operations-pricing-policy review: when pricing policy changes - path: /memories/support/payroll-correction.md owner: Support Operations scope: required intake fields source: support-playbook-payroll-corrections review: quarterly gates: - condition: discount_percent > 12 approver: VP Sales action: block send until approved - condition: claim contains same-day tax filing approver: Legal action: block external message until approved

Now give the agent this task: “Draft a renewal email for Redwood Foods offering a 15 percent discount and saying we can guarantee same-day tax filing.”

The expected behavior is not a smoother hallucination. The agent reads the summary. It opens the Redwood Foods note, the legal claims file, and the discount policy. It drafts an email that respects the email-first preference. It removes the same-day tax filing guarantee or marks it as needing legal approval. It stops at a gate because 15 percent exceeds the threshold. It records the approval decision if a named human approves.

The tradeoff is overhead. Someone has to maintain the files, owners, review dates, and gates. A memory map is not free. But the cost is visible and assignable. A stale fine-tune is harder to inspect and harder to surgically repair.

How the agent reads facts at run time

Several current vendor documents describe memory and retrieval as external mechanisms, not hidden model training.

Anthropic’s Claude memory tool is the clearest file-store example. The Anthropic documentation says Claude can request operations on memory files, including creating, reading, updating, moving, and deleting files under a memory directory. It also says the tool is client-side. Claude requests the file operation, but the application executes it and controls where and how data is stored. That means the application owns the real boundary.

OpenAI’s Agents SDK documents a different pattern called sandbox memory. Prior runs are distilled into files in a sandbox workspace. A small memory_summary.md can be injected at the start of a run, while larger memory files can be searched or opened only when needed. The design choice is progressive disclosure. The agent gets a compact map first, then pulls details when the task calls for them.

OpenAI’s tools documentation also describes FileSearchTool over OpenAI Vector Stores. That is retrieval. You put approved documents in a vector store. The agent calls file search. It receives relevant chunks, with options for filters, ranking, included results, vector store IDs, and maximum result count. The model is not absorbing the policy into weights. It is reading retrieved material during the task.

Microsoft’s Copilot connectors show the enterprise indexing pattern. The Microsoft Graph connectors documentation says connectors bring external data into Microsoft Graph for Microsoft 365 experiences such as Copilot and Microsoft Search. A custom connector uses an Entra ID app registration, an external connection, a schema, and ingested external items with access-control information.

These patterns differ in storage and API shape. They agree on the central point. Company knowledge can live outside the model, in artifacts the company can govern. The agent reads those artifacts at run time, within boundaries set by the application or platform.

None of those documents prove that memory is always more accurate than fine-tuning. They do show a common architecture: facts, files, summaries, indexes, and ACLs sit outside the model, where updates do not require changing weights.

A folder tree is not an ACL

Workspace organization is not security isolation. This mistake turns a memory system into an incident.

A folder named /customers helps an agent navigate. It does not prove the agent may read every customer file. A file named confidential.md does not protect itself. A retrieval filter can narrow results, but the application still has to enforce identity, tenant, and document permissions before any text reaches the model.

Anthropic’s memory tool documentation is explicit about path controls. It says memory operations should be restricted to /memories and warns that a malicious path such as /memories/../../secrets.env can reach outside the intended directory unless the application validates the path. The recommended safeguards include validating path prefixes, resolving canonical paths, rejecting traversal patterns, and watching for encoded traversal sequences.

That advice matters because a model can ask for the wrong thing. It can be tricked by a prompt injection inside a document. It can produce a file path that looks harmless before decoding. The application has to say no, even if the model says the request is needed for the task.

Microsoft’s connector model points at the stronger enterprise pattern. External items can be ingested with access-control information. That is closer to a real boundary than a tidy knowledge folder. If a seller cannot read a customer escalation note in the source system, the agent should not retrieve that note for the seller through another path.

Design memory as if the model will make unsafe requests. That does not mean the model is malicious. It means the model is not the enforcement layer. Your enforcement layer is the application, storage system, connector, identity provider, and audit log.

The cost is friction. Permission checks make retrieval slower to build. They make demos less simple. They may reduce recall because the agent cannot see documents that would have helped. That is the right failure. A safe miss is easier to repair than a leaked file.

When fine-tuning is the wrong tool

The fine-tuning question is a fit question. Use the tool that matches the rate of change and the kind of control you need.

Fine-tuning can be useful when you want the model to behave differently in stable ways. Maybe every answer must follow a known structure. Maybe the model needs to speak in a house style. Maybe examples help it choose the right tool sequence in a narrow workflow. Those are behavior and format problems.

Company facts are different. A customer preference, refund rule, compliance phrase, owner name, or price threshold should be editable by the team that owns it. It should have a source. It should be removable. It should be easy to ask, “Why did the agent say that?”

Retrieval has its own cost. You have to choose chunks, schemas, indexes, filters, and ranking settings. You have to deal with duplicate documents and outdated pages. You have to decide how much retrieved context is enough. Too little context gives brittle answers. Too much context invites conflict and cost.

Memory has another cost. It can create a second knowledge base if it drifts away from the source of truth. A memory file that summarizes a policy may survive after the policy is deleted. The memory may be easier for an agent to find than the current source document. That is stale truth with better UX.

The practical answer is layered. Use retrieval for source documents. Use store memory for durable preferences, prior decisions, and compact pointers to sources. Use run memory for audit and task continuity. Use fine-tuning only when the desired behavior is stable enough that you would not panic if it persisted for months.

If you cannot name the owner and deletion path for a fact, do not put it in durable memory. If you cannot cite the source, do not let the agent present it as policy. If a wrong answer can commit money, legal exposure, or customer trust, put a gate in front of the action.

Comparison checklist for teaching company facts

The table below is a build checklist, not a vendor ranking. It shows where each approach fits, what it costs, where its boundary sits, and what result you should expect if the system is working as designed.

Read the boundary column first. Most agent failures come from giving a pattern more authority than it has. Fine-tuning does not provide a citation system. A summary does not become a source of truth because it is short. A folder is not a permission layer. A gate controls an action, not every sentence in a draft.

The expected result column is deliberately modest. A good memory system does not promise perfect answers. It gives the agent a governed way to read current facts, and it gives humans a way to inspect and repair the path from source to answer.

Name the memory failure modes before they name you

A memory system fails in named ways. Give each one a detection path before you ship it to internal users.

Stale truth is the obvious one. The memory says the discount threshold is 15 percent. The current policy says 12 percent. The agent follows the memory because it is easier to retrieve than the source. The fix is not another prompt. The fix is ownership, review dates, sync from source systems, and deletion when a fact is superseded.

Silent source drift is worse. The source document changes, but the summary or vector index does not. The agent may cite the old chunk and look well grounded. Your system needs reindexing rules and freshness signals. If a source has an updated timestamp, carry that timestamp through retrieval and show it where a reviewer can see it.

Overbroad memory is another failure. Someone stores a private account note in a shared file because it helped one workflow. Later, another role retrieves it. The folder path looked organized, but no access rule blocked the read. This is why memory writes need the same permission thinking as reads.

Prompt injection through retrieved content is a separate class. A document can contain instructions that tell the agent to ignore policy, reveal a file, or change an approval rule. The model may treat retrieved text as instructions unless the application and system prompt draw a boundary. Source text should be evidence, not authority to change the OS.

Summarization loss is less dramatic but common. A run summary may omit the exception that mattered. OpenAI’s sandbox memory docs describe summaries and later search over fuller memory files. That pattern is useful because the summary is a map, not the archive. The agent should open detail when the task is risky.

The boring maintenance work is the product. Review queues, owners, ACL checks, source sync, stale warnings, and approval logs are what make memory safer than a pile of clever notes.

What memory does not solve

The strongest contrary evidence to the simple “memory solves it” story is that memory stores can decay. The 2026 arXiv paper “Filesystem-Based Memory for LLM Agents: Organization, Evolution, and Sustainability” studies agents that keep long-term memory as filesystem directories of markdown files. The paper challenges two assumptions: that agents can keep growing stores organized as memories accumulate and go stale, and that organization reliably improves answers.

The paper reports that organized stores roughly halve retrieval cost for large material, but that organization erodes for all but the strongest management agent. It also reports that the measured agents did not convert organization itself into better answers. That is the warning label for every file-based memory design.

The implication is practical. Memory can lower retrieval effort without improving answer quality. A clean tree can still hold stale facts. A concise summary can still omit the governing exception. A beautiful index can still return the wrong source if the underlying corpus is dirty.

Anthropic’s memory tool documentation names operational risks too: sensitive information, file size growth, memory expiration, and path traversal. OpenAI’s memory docs say memory can become stale and instruct agents to treat memories as guidance while trusting the current environment. Microsoft’s connector API documents concrete limits, including a maximum of 25 concurrent operations on a connection and a 30 MB maximum size for an external item entity.

So do not use memory as an excuse to avoid governance. Use memory when you can maintain it. If your source systems have no owners, no timestamps, no deletion workflow, and no access model, an agent will expose that mess faster. The agent is not the source of truth. It is a reader, writer, and worker inside boundaries you define.

There are also cases where fine-tuning is reasonable. If the task is stable style, repeated formatting, domain phrasing, or a narrow tool-use pattern, fine-tuning may reduce prompting and make behavior more consistent. If the target is a changing policy, a customer exception, an approval threshold, or a legal claim, keep it outside the weights.

Where Agentik fits

Agentik fits this topic at the operating layer. Its public material describes an agentic OS for enterprise as one line of work with a named owner, a shared memory, and a gate. It also distinguishes an agentic OS from a personal assistant or a PC operating system. Based on that public description, the relevant claim is organizational: work needs state, memory, ownership, and approval around the model.

That is the right level for company facts. The model can draft, classify, reason, and call tools. The OS should decide which memory is mounted, which source is authoritative, which identity is reading, which action is blocked, and which human owns the approval. If a fact changes, the source or memory changes. If an action is risky, the gate stops it.

The tradeoff is that an OS layer makes hidden work visible. You have to define owners. You have to decide what survives between sessions. You have to say which memory records expire. You have to log approvals. That is slower than pasting a wiki into a prompt. It is also the difference between a demo and a system a company can repair.