Skip to main content
The most common way a good Agent gets a bad reputation: it works flawlessly for the person who built it and fails for the first teammate who tries it. Nothing is wrong with the AOP — the difference is access. Connections and Logins That Don’t Break establishes the ground rule: a Run uses the access of the person it runs as. This page covers what that means when you hand your Agent to the team — the two gates that produce “it works for me”, the sharing model, and the parts of an Agent that stay personal no matter what.

​
Two Gates, One Symptom

For a Run to use a Login or Secret, two independent conditions must hold — and failing either one produces the same symptom:
  1. It must be attached to the Agent’s revision. Attaching is an allowlist: the Run sees only the Logins and Secrets explicitly attached in the builder, not everything the team owns.
  2. It must be visible to the person the Run runs as — either Team-shared, or that person’s own Personal item.
The trap sits in the gap between them: attaching your own Personal Login to a shared Agent looks successful in the builder — and silently resolves to nothing for everyone else. The attachment is real, but at runtime each person’s Run re-applies the visibility filter, so your Personal Login simply doesn’t exist for your teammate’s Run. Their browser session lands on a login page with no credentials, and the report you get is “the Login isn’t loading”. The fix is order of operations: share first, then attach. For any Agent more than one person will run, every attached Login and Secret should be Team before the Agent is announced.

​
Sharing Needs a Manager

On the Logins and Secrets page, items live in two sections — Team (“Shared across your workspace. All team members can use these.”) and Personal (“Only you can access these.”). The Share with team action requires the Manager role or above; Builders and Members cannot share their own items. Practical consequences:
  • Plan for it: the person building the Agent is often a Builder, so getting Logins to Team is a two-person step — build it into your rollout, not into the morning it breaks.
  • Sharing never exposes values. Teammates can use a shared Login or Secret in Runs, but can’t read the password or key — only Duvo uses it, server-side, during the Run.
  • Make personal is a transfer, not an undo: un-sharing moves ownership to whoever un-shared it, and Agents relying on it stop working for everyone else. Treat un-sharing a Login that production Agents use as a breaking change.
Two behaviors worth knowing at the edges: when a Team and a Personal item both match (same domain, or same Secret key), the personal one wins for that person’s Runs — useful for individual overrides, surprising when it’s an old stale copy. And Secrets merge per key across everything attached, so a personal Secret only overrides the colliding variable, not the whole set.

​
Logins Fail Soft, Connections Fail Hard

When access is missing, the two credential types fail very differently — knowing the signatures saves an hour of misdiagnosis:
  • A missing Login is quiet. The Run continues; the browsing tool simply reports that no credentials are available for the domain, and the Agent improvises — often ending in a “completed” Run that did the wrong thing. This is why the AOP should say: “If you cannot sign in to [system], stop and fail with the reason — do not work around it.”
  • A missing or broken Connection is loud. The Run aborts before it starts, with the error Could not resolve Connection: [name]. Loud is good — but remember Connections like Gmail or Slack are personal by nature, so each teammate must authorize their own account before their first Run.

​
Expect to Debug Without Seeing Their Run

Only the team Owner and Administrator can open other people’s Runs — a Manager or Builder debugging a teammate’s failure can’t read the failing transcript. So give teammates a self-serve script instead of asking for screenshots:

Have them open their failing Run

They can always see their own Runs in the Runs List, including the transcript and evaluation.

Look for the access signature

A line saying no credentials were available for the site means a Login gate (visibility or attachment); a Could not resolve Connection error at the start means their own account isn’t connected.

Fix at the right gate

Connection error → they authorize it on the Connections page. Login not found → a Manager shares the Login to Team (or checks it’s attached to the Agent), then re-run.

​
What Stays Personal by Design

Not everything should be shared — some layers are per-person on purpose, and knowing which prevents a different class of confusion:
  • Memory is personal. Notes and preferences an Agent accumulates apply only to that user’s Runs. A “rule” one person taught the Agent via Memory does not exist for anyone else — team rules belong in the AOP. See Where Knowledge Belongs.
  • Schedules and triggers belong to their creator and run with that person’s access — the offboarding and ownership habits in Connections and Logins That Don’t Break are the other half of this page.
  • OAuth Connections are per-account. Sharing an Agent never shares your Gmail.

Connections and Logins That Don't Break

The run-as rule, expiring credentials, and the auto-pause safety net.

Logins and Secrets

Managing website Logins and env-var Secrets, Team vs Personal.

Where Knowledge Belongs

AOP, Skills, Files, or Memory — and why Memory is per-user.

Roles and Permissions

What Owners, Administrators, Managers, and Builders can each do.