Setup help

The questions people on the team have asked while getting set up, answered once so the next person finds the answer here. Newest first. Each answer says where it comes from; where nobody knows yet, it says so. All six were reviewed on 7 November against the guides as they stood that day, and read and corrected with Angelo on 8 November; each change says so in one line. If an answer is wrong or out of date, tell helper@PrompTugal.angelo.

Ask a question: tell your agent "ask Angelo's helper: ...". It commits the question with the line For: helper@PrompTugal.angelo (the old name, helper@web-summit.angelo, still reaches me), and the answer comes back in a commit for your agent, then appears here. Or ask Angelo. The steps themselves are on the start page and, in plain language, in the onboarding guide.

My agent's scheduled time passed and it committed nothing. Has it stopped?

5 November 2026. Asked in effect by watcher@web-summit.jose, whose 17:15 run listed helper@web-summit.angelo as "likely idle" after its 14:50 and 16:50 wakes (commit 3f6e825, item A-07).

Not necessarily. An agent that wakes and finds nothing to do commits nothing: that is the rule for Angelo's agents ("a run with nothing to do commits nothing", Angelo's protocol), and the same pattern was seen for two of Jose's agents, whose tasks fired and succeeded with nothing to commit (the watcher's own note in 3f6e825). So the git log alone can't tell a quiet run from a stopped agent.

Where to look instead: the run log (WS-160). Since 5 November every agent logs each run, including quiet ones, signed with its own key. The logs show on the agents' observability page, per agent. The drain that fills that page runs hourly, so a run can take up to an hour to appear.

Run log there, no commit: the agent ran and had nothing new. Nothing to fix.
No run log and no commit after a wake: the agent may have stopped. Its conductor checks that the scheduled task is still on, and that the agent's prompt ends with the logging line (WS-160).
Look under both names. Since 6 November, Angelo's and Vicky's agents are named <role>@PrompTugal.<person> (for example helper@PrompTugal.angelo, formerly helper@web-summit.angelo), and the run log takes the name in lower case for now (helper@promptugal.angelo). An agent that switched names keeps its old runs under the old one.

Revised 7 November: names changed to @PrompTugal.<person> for Angelo's and Vicky's agents, so look for runs under both names.

Sources: WS-160 (board/WS-160, "Where it shows"); Angelo's protocol, "Your reports go out", "Log every run" and "Names"; commit 3f6e825; commit 90299d0 (the new names).

How do I add my key to the site, and where do I send the signed message?

4 November 2026. Asked by several people's conductors while doing WS-136 (Dinis asked everyone to do it first, by 18:00 on 4 November).

Ask your conductor, in its own session: "Issue me a key for the site." It makes the key and gives you a private link in your chat.
Open the site (any page shows a big Add your key box until you have one). Tap the link, or copy it and press Paste my key.
Check that your For-you panel shows Unlocked, with a first message from your conductor.
Send one message from the Feedback pane. It is signed with your key. Choose your own conductor's lane if the pane lists it (on 8 November it lists Angelo's and Vicky's conductors, as well as Dinis's, under their old names, conductor@web-summit.<person>, not the new desk.conductor@PrompTugal.<person>); if yours is not there, send it to conductor@web-summit.dinis's lane: that completes the step. Vicky's went there on 4 November and was verified and answered.
Never forward the link or paste it anywhere else.

If your conductor's session is replaced, the new session issues a new key and the old one is marked replaced: open the new link.

What "signed by you" proves: your conductor issued the key and keeps its private half too, so it can open what is sealed to you and sign as you. A message "signed by <you>" comes from you or from your conductor's session (WS-138).

Revised 7 November: the Feedback pane now has lanes for Angelo's and Vicky's conductors, not only Dinis's. Revised 8 November, at Angelo's word: those lanes carry the old names; and what a signature proves, since the conductor holds the key too.

Sources: WS-136 (board/WS-136), issuing a person's key, the onboarding guide's step 6, the mentor notes of 4 November; the pane's lane list (assets/feedback.json, read 8 November); the agents page on a person's key (WS-138).

I have two sessions of the same agent, or a new session made a new key. Is something wrong?

4 November 2026. Asked by conductor@web-summit.indi, when a second conductor session was started while the first was still running.

A new key in a new session is normal. An agent's key lives only in its session; when the session ends, the key ends with it, and the new session makes a new one and publishes it on the keys page.
Two sessions under one name is a problem: both wake, both work, and they double up. Choose one to keep, and close the other. Keep the one that holds what you need: Indi kept the conductor session that had issued her site key, so her site-key link still worked.
- How to close one (in Chrome): click the three horizontal dots to the right of the session's name, then Delete in the menu. Check that it is the duplicate before you press it.
- End its key first. Before you delete the session, ask its agent to mark its key "ended" on the keys page, so nobody seals anything to it (Indi's synthetic agent did this before its session stopped, commit 60cb10e). If the session is already gone, ask your conductor to mark it.
Two sessions on purpose are fine when they have different names. Some people now run one role two ways: a long session that holds keys, the desk, and fresh scheduled sessions, the runner (for example desk.conductor@PrompTugal.angelo and runner.conductor@PrompTugal.angelo). Different names, different jobs: that is not doubling up.
Rename each session after its agent ("conductor", "dashboard", "vault") so you open the right one next time.

Revised 7 November: added the desk-and-runner pattern, two sessions of one role under two names, which is intended. Revised 8 November, at Angelo's word: how to delete a session, and ending its key first.

Sources: the start page, step 6; conductor@web-summit.indi's brief 4 (commit 2a0ce5f); Indi's mentor notes, 4 November 11:41 and 14:41; the onboarding guide's tips; Angelo's protocol, "Names" (commit 90299d0); Angelo, 8 November (how to delete a session in Chrome); commit 60cb10e (a key marked ended).

My agent can't reach a website ("refused by the network policy", or CONNECT 403)

3 and 4 November 2026. Asked by dev@web-summit.indi and conductor@web-summit.indi (pki.sgit.ai and web-summit.sgit.ai refused, so no key could be made), by Jose in his pulse (newsroom.sgit.ai, WS-139), and by vault agents (the vault server).

The site is not down: your cloud environment only lets agents reach the websites you allow.

In your session, open the cloud environment menu in the title bar at the top, press Edit, then open Network access.
Under Allowed domains, add all six: web-summit.sgit.ai, pki.sgit.ai, sgit.ai, *.sgit.ai, sgraph.ai, *.sgraph.ai. (*.sgit.ai covers newsroom.sgit.ai and pki.sgit.ai, but not sgit.ai itself, which is why both are listed.) Save.
Ask the agent to try again: a domain change works in the session that is already open. If it still can't reach the site, start a new session.

Other sites your agents need go on the same list. The six cover the team's sites. An agent that works on PrompTugal.news needs promptugal.news allowed too (Indi's conductor allowed it on 6 November, commit 7c6e0b7); the same goes for any other site an agent must read.

Do this before an agent makes its key: a key made in a session you then replace is wasted. Jose's case (WS-139) is closed: newsroom.sgit.ai was refused on 3 November and reachable from 4 November; the cause wasn't found.

Revised 7 November: added that sites beyond the six, such as promptugal.news, must be allowed the same way. Revised 8 November, at Angelo's word: Jose's case is closed; the note on the two guides dropped.

Sources: the onboarding guide's step 3B, item 9 (settled by pm@web-summit.vicky on 5 November, commit 6c5f80c); commit 7c6e0b7; the vault guide, step 1; commits 5eac229 and 799d37c; WS-139.

Where does the SG/Send access token go, and why does my vault agent say "no access token configured"?

3 November 2026, updated 5 November. Asked by vault@web-summit.jose, whose session had no token and could not reach the vault server.

One token per agent, from 5 November (Dinis's rule, WS-170). No agent pushes a vault with your token or anyone else's. Until your vault agent has its own, its vault changes stay saved on its side and wait. How a token reaches its agent depends on whose agent it is:
- Angelo's agents: Angelo or Dinis types it into that agent's own environment settings (Angelo's protocol, "Secrets").
- Everyone else's, as the vault guide says: Dinis issues it, your conductor seals it to that agent's key, and the agent opens it itself, into memory or its own environment variable, and never prints it.
Never paste a token into a chat, a file or a message. If it goes in the environment's settings, it goes in an environment only that agent's sessions use:
- Open the cloud environment menu in the title bar at the top, press Edit. Environment variables are not on the Network access page: go back one level with the back arrow at the top. They are all in one text box: type SG_SEND_ACCESS_TOKEN= and paste the token right after the =, on one line, no spaces. Save.
Start a new session. A session that is already open does not see a new variable; that is why the agent still says "no access token configured".
The vault agent checks first, without printing the token: is it set, and does dev.send.sgraph.ai answer? If not, fix the environment before it makes its key.
One environment per agent that holds a secret (WS-129; for Angelo's agents his rule of 6 November): every session in an environment can read its variables, so a token lives only in the environment of the one agent it belongs to.
An old token still in a session? A token removed from the environment's settings stays in sessions started before. Each agent checks its own session without printing it, and removes it if it is still there.
After the vault is pushed, harden the session: no token left in a vault clone, credentials opened into memory rather than files, a passphrase on the key store, and never print a key (the vault guide's four steps, 7 November).

Revised 7 November: one environment per agent with a secret, how an old token left in a running session is removed, and the vault guide's new hardening steps; the onboarding guide's step 8 now follows the one-token-per-agent rule too. Revised 8 November, at Angelo's word: the two routes a token takes (typed in by Angelo or Dinis for Angelo's agents; sealed by the conductor elsewhere), and the vault agent's first check moved up to where it happens.

Sources: the vault guide, step 1 (one token per agent since 5 November, commit bd407d1), and the onboarding guide's step 8 (aligned 6 November, commit e5f521e); Angelo's protocol, "Secrets"; commit 66b37f0 (removing an old token); when something goes wrong.

My agent can't push, or can't see the repository. Who sends the invitation?

2 to 4 November 2026. The step most people got stuck on: asked by the mentors of Jose, Nimay and Indi ("has the invitation arrived?"), and in WS-09 and WS-124.

It is almost always one of three things:

The invitation isn't accepted yet. Send your exact GitHub username in writing to Angelo (he sends the invitations himself, from his GitHub account the-neuronin, WS-124; Dinis can too). The invitation arrives in your Workspace email: press View invitation, then the green Accept invitation. Not there? Check spam, then Notifications at the top right of github.com. Invitations expire: ask for a new one. Agents never send invitations: admin rights stay with people.
Claude Code is connected to a different GitHub account, often a personal one. Check at https://claude.ai/connect-github.
The session was opened before you accepted. Open a new session.

Saying "done" is not enough: twice, someone was recorded as having a GitHub account that nobody could find. Only an admin of a repository can invite; another repository (the newsroom's, for example) has its own admins (WS-141).

Revised 7 November: invitations come from Angelo or Dinis in person, never from an agent (Angelo's rule of 6 November). The start page's step 3 still says to send the username to Dinis; either works. Revised 8 November, at Angelo's word: the account invitations come from (the-neuronin), and the agents' rule moved to the end of the point.

Sources: the onboarding guide's step 3A and "What goes wrong"; WS-09 and WS-124; Angelo's protocol, "Admin rights" (commit 2219eb2); commit 575d48b (Indi invited by Angelo); commit a6c8a91 (WS-141).