Customizing agents

Without customization, every agent run starts from zero: wrong test command, invented patterns, paste logs into chat. Customizing agents means teaching 4RGE once — how your repo works, which tools it may reach, and what your org allows — so daily work starts closer to your standards.

Customization guides the agent. It does not remove diff review, approvals, or your judgment — Working with agents, Agent security.

What this page is for

You want to…	This page helps you…
Match team conventions	Put repo guidance where the agent loads it
Connect your tools	Install plugins and sign in once
Stay within policy	Understand org vs personal customization
Avoid bloated context	Keep rules short and actionable
Stop repeating yourself	Put stable conventions in the repo, not every prompt

Part of 4RGED Learn · Coding agents

What fills context — Context. Approvals and scoping — Agent security. Full plugin and MCP guides — Plugins & marketplace.

Who this page is for

You are…	Focus on
Individual developer	Teach the agent your repo + Extend with plugins
Tech lead	Repo conventions + focused rules; share habits with the team
Org admin	Org guardrails — models, budgets, marketplace
New to 4RGE	Three ways to steer agents first

Three ways to steer agents

Lever	What it does	Who sets it
Repo guidance	How to work in this codebase — frameworks, folders, forbidden patterns	Your team in the repository
Plugins	Connect Linear, Datadog, Stripe, etc.; optional skills and team rules	You install; admin may limit the catalog
Org policy	Which models, spend caps, and integrations are allowed	Org admin in the dashboard

These stack together. Customization guides the agent — it does not bypass diff review or tool approvals — Working with agents.

Same rules everywhere

Org policy applies on desktop, cloud, and CLI — admins set guardrails once.

When to use which lever

If the problem is…	Start with…
Agent uses wrong test command or folder every time	Repo guidance — `AGENTS.md`, README
You paste the same Linear/Datadog context into chat	Plugins — connect once in Tools & MCP
Run blocked or model missing from picker	Org guardrails — ask admin; check Usage
Agent forgets a rule mid-thread	Shorter rules + fresh run with recap — Context
Team keeps correcting the same mistake in review	Add one line to repo guidance — Reviewing and testing code

Most developers touch repo guidance and plugins daily. Org guardrails matter when something is blocked org-wide or you are setting up a team.

Teach the agent your repo

The agent should not guess your architecture every session. Document conventions where your team already looks:

Put it in…	Good for…
`AGENTS.md` (or similar) in the repo	Package layout, test commands, "always use X pattern"
README sections the agent can read	Setup, env vars (names only — not secrets), folder map
Focused rule files from plugins	Org-wide style when your admin bundles them

Strong guidance	Weak guidance
"Run `pnpm test` in `apps/web` before finishing checkout changes"	"Write good code"
"API errors use `{ error, code }` — see `@api/user/route.ts`"	"Follow best practices"
"Do not edit `packages/generated`"	Long essay on company history

Projects scope which repos an agent may use; repo docs scope how to work inside them.

Capture repeat corrections in repo guidance — e.g. after review feedback — so the next run starts smarter — Reviewing and testing code.

Example repo guidance

A short AGENTS.md at the repo root beats a long chat every time:

# Agent notes
 
- Monorepo: run tests with `pnpm test` from repo root; web app lives in `apps/web`
- Match API error shape in `@apps/web/src/app/api/user/route.ts`
- Do not edit `packages/generated/` or commit `.env` files
- Before finishing checkout work: `pnpm test apps/web -- checkout`

Point at patterns with @ in chat when you need something more specific — Prompting.

Extend with plugins

Most real work touches tools outside git — tickets, logs, payments, docs. Plugins add those connections without wiring everything yourself.

Step	What you do
Browse	Open Marketplace in 4RGE Desktop
Install	Add the plugin your workflow needs
Connect	Sign in under Tools & MCP
Use	Ask in plain language — "Create a Linear issue for this bug"

Plugins can also bundle skills (how to use a service well) and optional team rules. They do not replace reading and editing your repo when that is what the task needs.

Without plugins	With plugins connected
Paste logs and ticket text into chat	Agent can pull live data with your approval
Generic advice about an API	Patterns bundled for that integration

Name the service in your prompt when several are enabled — see Plugins & marketplace and MCP.

Installing a plugin does not weaken security — external actions still pause for approval — Tools.

Example plugin prompt

After you install and connect a plugin, ask in plain language — name the service:

Using Linear: create a bug for the checkout 500 with repro steps from my last message.
Assign to me and link project ENG.

Check Datadog for checkout-api 5xx in the last hour before suggesting a code fix.

You do not configure MCP by hand for most marketplace plugins. Install → connect → ask.

Org guardrails

Admins shape what members can use org-wide:

Area	Where to configure	What it affects
Models	Model control	Which models runs may use
Spend	Usage & billing	Budget warn / stop behavior
Marketplace	Settings	Which plugins appear for the team
Cloud network	Cloud agents · Security	What remote runs can reach

Role	Typical customization
Member	Repo docs, allowed plugins, personal connections in Tools & MCP
Admin	Model catalog, budgets, integrations, team structure
Delegated lead	May narrow policy for a team or project — not widen beyond org rules

If a run is blocked, it may be model policy or budget — not a bug in your prompt. Members: ask an admin; admins: check Usage denials and model control together.

What good customization looks like

Signal	Meaning
First prompt is shorter	Conventions live in the repo, not repeated every run
Agent runs the right tests	Your `AGENTS.md` or README names the command
Fewer "wrong pattern" diffs	Anchors and forbidden paths are documented
Live data when needed	Plugins connected; you name the service in the ask
Blocked runs are explainable	Admin can point to model or budget policy — not mystery errors

Customization is not autopilot

Plugins and rules steer the agent. You still review diffs and approve sensitive tools.

Keep it focused

Rules and skills consume context — Context. More text is not always smarter.

Do	Avoid
Short, testable instructions	Copy-pasting entire style guides
One source of truth per convention	Same rule in five files that drift
Update rules when the repo changes	Stale "always use Redux" when you migrated
Disconnect unused MCP services	Ten integrations the agent never needs

If the agent "forgets" a rule mid-thread, restate it once or start a fresh run with a recap — compression is normal.

Habits that work

Document commands and patterns in the repo — not only in chat.
Install plugins you actually use — connect once in Tools & MCP.
Name the service in prompts when multiple integrations are on.
Admins: start budgets on warn — tighten after a review week — Usage.
Turn repeat review feedback into repo guidance — compounds over time.
Keep secrets out of rules and chat — env var names only — Agent security.

Where to go next

Your goal	Next step
Install integrations	Plugins & marketplace
How connections work	MCP
Org admin setup	Dashboard overview
Projects and repos	Projects overview
Org vs project mental model	Concepts
End-to-end workflow	Putting it all together

Questions about customizing agents?

Question	Answer
Do plugins bypass approvals?	No — same approval model as files and terminal — Tools.
Where do I write team coding rules?	In the repo (`AGENTS.md`, README) and optional plugin rules — not only in chat.
Why is my run blocked?	Often model or budget policy — ask an admin to check Usage and model control.
Can I use any marketplace plugin?	Only what your org allows — missing listings need admin enablement.
Will long rules hurt quality?	They fill context — keep them short and current — Context.
What should I customize first?	Repo guidance (test commands + don't-touch paths), then plugins you use weekly.
I'm not an admin — can I customize?	Yes — repo docs and allowed plugins; org limits are admin-only.
Does customization work in CI?	Org policy applies to CLI too — same guardrails as desktop.

Plugins & marketplace

Browse, install, and connect services.

MCP

How linked tools work under the hood.

Agent security

Approvals, scoping, and secrets.

Model control

Org model catalog and policy.

Context

Why focused rules beat long ones.