osFoundry / Platform
Agent configs
Edit any agent's name, model, tools, prompt and policy as a versioned record. Fork, publish, share.
What it is
An agent config in osFoundry is the full definition of an AI agent kept as a single, editable record: its name, the model it runs on, the tools it can call, its system prompt, and the policy that governs what it is allowed to do. Instead of scattering those settings across code, config files, and a provider's dashboard, you edit them in one place and every change is captured as a version. You can see how an agent's prompt or tool list looked three edits ago, compare it to now, and roll back if a change made it worse.
Because osFoundry is bring-your-own-key and local-first, the config points at whatever model you choose — a local model on your own machine, a cloud model through your own API key, or a self-hosted endpoint — with no reseller sitting in the middle. Swapping the model on an agent is a field on the config, not a rewrite: keep the same prompt, tools, and policy and try it on a different model to compare cost and quality. The policy field is where you set the guardrails — which tools require approval, what the agent may touch — so behavior and permissions travel with the agent rather than living somewhere separate.
Configs are made to move. Fork any agent to get an independent copy you can change without affecting the original, publish a version when it is solid, and share it so a teammate or another workspace can run the same agent. Versioning means a shared config is a specific, reproducible state, not a moving target — the person you hand it to gets exactly the model, tools, prompt, and policy you tested, and can fork it to make it their own.
Key capabilities
- Edit an agent's name, model, tools, system prompt, and policy from a single record instead of scattered files and dashboards
- Every change is saved as a version, so you can review history, diff edits, and roll back a prompt or tool change that made things worse
- Swap the underlying model on any agent as one field — reuse the same prompt and tools to compare local, cloud, and self-hosted models
- Fork any config into an independent copy, then publish a version and share it so others run the exact agent you tested
- Runs on your own API keys and can use local models, so an agent's definition and its data stay on your device — no per-seat fees, no markup
Use cases
- Prompt engineer: iterate on an agent's system prompt across a dozen versions, diff two of them, and roll back to the wording that scored best
- Team lead: publish a vetted support agent with a locked-down policy, then let each teammate fork it for their own workflow without breaking the original
- Cost-conscious builder: keep one agent's prompt and tools fixed and swap only the model to compare a local model against a cloud key on the same task
Frequently asked questions
What exactly does an agent config include?
Five things as one versioned record: the agent's name, the model it runs on, the tools it's allowed to call, its system prompt, and its policy (the rules and approvals that govern what it can do). Editing any of them creates a new version you can review or revert.
Can I change which model an agent uses without rewriting it?
Yes. The model is a field on the config. Point the same agent at a local model, a cloud model via your own API key, or a self-hosted endpoint, and keep its prompt, tools, and policy intact — which makes it easy to compare models on identical setups.
What's the difference between forking and sharing a config?
Forking makes an independent copy you can edit freely without touching the original. Sharing hands someone a published version to run as-is. Because configs are versioned, a shared agent is a specific, reproducible state — the recipient can fork it if they want to change it.