Maintain the shared setup
Follow inheritance, ownership, review, and release through one configuration change.
Open this resource →Working with Betterloop
Give the next session a better starting point.
Maintain a reviewed agent setup, check its arrival on developer devices, and carry useful team knowledge into subsequent work.
A team setup should be understandable to the people who maintain it. Betterloop connects reviewed configuration, local agent setup, and shared engineering knowledge.
01 / Working with Betterloop
Start with a team problem you can name.
Harbor is an imaginary company used in this walkthrough. Its Search team maintains search-api with Claude Code and Codex.
Developers have different local instructions. Some have an outdated documentation connection. New colleagues ask which setup the team actually supports.
The platform owner needs a maintainable answer. The answer must identify the reviewed configuration and show whether participating devices received it.
The Search team also needs repository context. A documentation reference for search-api should accompany that project without appearing in unrelated work.
Betterloop gives these responsibilities a common path. Administrators maintain the organization baseline. Team owners prepare permitted additions and review the resulting configuration.
Developers retain their preferred supported client. Enrollment connects their device to the organization and team. Native authentication remains with the client.
The following example describes a possible workflow. Harbor, Search, and search-api are invented names. They do not represent a customer deployment.
- 01
Prepare the baseline
Record the organization requirements in the shared rules editor.
- 02
Set the team context
Select the organization revision for the team configuration.
- 03
Request review
Submit the proposed configuration through Git.
- 04
Check publication
Confirm that a compatible signed release exists.
- 05
Enroll one developer
Provide a personal enrollment code or team invite.
- 06
Inspect the first session
Compare Doctor results with Connections after native activation.
02 / Working with Betterloop
Keep configuration work separate from application work.
Harbor uses a configuration repository for rules and versioned resources. The application repository contains search-api. These repositories serve different review responsibilities.
A change to application code does not revise the shared agent setup. A configuration release does not provide permission to read application code.
The team associates search-api with approved references through its knowledge map. That mapping follows configuration review and publication before clients use it.
One organization has one rules configuration. One team also has one. Drafts and releases represent successive versions rather than selectable policy profiles.
The organization baseline supplies requirements that the team inherits. The team adopts a newer baseline explicitly instead of receiving an unnoticed replacement.
This makes an ordinary maintenance question answerable. The owner can identify the parent revision, resource versions, and approved changes behind a release.
Required resources travel with the team configuration. An optional resource becomes available through the approved library without becoming mandatory for every developer.
03 / Working with Betterloop
Follow the device into its first repository.
A developer accepts an invite and supplies a name and work email. Setup then issues a personal enrollment command for that connection.
Enrollment binds the device to one organization and team. It enables the selected agents with restricted credentials. Each client still requires native sign-in and trust.
The next fresh session identifies its working repository. The client verifies signed policy and prepares a bounded context before selecting applicable signed knowledge.
A search-api session receives its matching references. Another repository receives its own context. An ambiguous match requires the developer to choose a project.
Working in another repository does not require another enrollment code. Switching organization or team requires an explicit disconnect from the existing connection.
Background activity retains the connection identity captured when it started. A device connection does not create automatic routing between teams.
Use status to inspect the local connection. Use Doctor to investigate authentication, cache validity, activation, and detectable unmanaged skill sources.
npx @betterloop/setup status --harness codex
npx @betterloop/setup doctor --harness codex04 / Working with Betterloop
Choose additions without losing the shared boundary.
A Search developer might want an approved documentation skill in addition to required team resources. The developer can inspect its reviewed files first.
Selecting that optional resource pins a version for the chosen agents on the device. The selection applies across repositories; later updates require an explicit choice.
Personal restrictions can reduce permissions. They cannot enlarge the shared allowances for tools, models, or shell programs.
Different resource types also need different expectations. A skill explains a workflow. A hook checks a covered lifecycle event. An MCP connection reaches an authorized service.
Instructions do not ensure that a model follows them. Connection files do not establish a working login. A hook needs an active, supported host integration.
Connections and Sessions help maintainers investigate reported setup and activity. These records are bounded client reports, so an absent event remains unresolved evidence.
Claude Code and Codex operate without Mimir. Mimir provides an optional runtime whose supported native gates have their own versions and conditions.
05 / Working with Betterloop
Make the first rollout inspectable.
For Harbor, the initial question is whether Search receives the reviewed setup. Start with a release and one participating device before expanding enrollment.
Compare the approved revision with the signed runtime artifact. Then inspect local activation in a fresh session on each selected client.
Try a permitted operation and an agreed prohibited operation at a covered boundary. Record whether the actual operation ran, alongside any displayed decision.
If knowledge is missing, inspect project matching and external authorization. Republishing a rule does not repair an unrelated service login.
If activation is missing, investigate native trust or reload behavior. Installed files alone do not establish that a session invoked its integration.
Use the result to decide what to expand. A repeatable setup path and an understood coverage gap are more useful than an unexplained green indicator.
| Check | Useful evidence | Remaining question |
|---|---|---|
| Reviewed setup | Approved commit, parent revision and resource versions | Was the compatible artifact published? |
| Device delivery | Verified release and local diagnostics | Did the native integration activate? |
| Operation check | Actual permitted and prohibited outcomes | Which execution paths remain uncovered? |
| Repository context | Selected project and retrieval diagnostics | Does external authorization succeed? |
| Team lesson | Recorded exposure and meaningful verification | Does the result repeat on comparable work? |
Can our team keep its existing coding clients?
Yes. Use the native Claude Code or Codex integration. Consider Mimir separately if its runtime capabilities fit your evaluation.
What changes when we open another repository?
Startup resolves a separate project context. Enrollment remains at device scope; repository access still follows the relevant service permissions.
What if we need every process on a device controlled?
Native integration coverage cannot establish that requirement. Evaluate the exact supported boundary and any additional managed controls you require.