Tygart Media

Tag: Notion Agents

  • The Security Posture of Notion Agents: What You’re Actually Granting Access To

    The Security Posture of Notion Agents: What You’re Actually Granting Access To

    The Security Posture of Notion Agents: What You’re Actually Granting Access To

    The 60-second version

    Agents are powerful access tokens. Treating them casually is a security mistake. The correct posture: scope agent access tightly, audit access logs monthly, treat connected user accounts as security-sensitive (not convenient), and build approval gates around destructive operations. Most “AI agent caused a problem” stories trace back to over-broad access, not malicious intent.

    What an agent can access

    Within Notion:
    – Every page the connected user can see
    – Every database the connected user can edit
    – Cross-workspace content if the user has multi-workspace access
    Through integrations (when connected):
    – Slack channels the user can see (including DMs in some configurations)
    – Email content if Mail integration is on
    – Calendar events including private ones
    – Google Drive content the user has access to
    Through Workers:
    – Outbound HTTP to any pre-approved domain
    – Can write to external systems via API calls

    Three security postures

    1. Permissive (avoid): Connect admin or executive accounts. Agents inherit broad access. High risk.
    2. Functional (default for most): Connect a dedicated integration account with role-based access scoped to the agent’s purpose.
    3. Restrictive (compliance-sensitive use cases): Per-task scoped accounts. Approval gates on every external action. Daily audit log review.
    For most operators, functional is right. For finance, legal, healthcare, or regulated industries, lean restrictive.

    Five practices that reduce risk

    1. Use dedicated integration accounts. Don’t connect the founder’s account. Create an “agent-ops” user with scoped access.
    2. Audit access logs monthly. Notion shows what the agent has read. Look at it. Anomalies show up fast if you check.
    3. Approval gates on destructive operations. Workers that delete, send, or charge should require human confirmation.
    4. Curate approved domains. Each new approved domain is new attack surface. Add deliberately.
    5. Review skill scope before deployment. A skill with access to “all databases” is too broad.

    Where this goes wrong

    1. The “connect everything” pattern. Agents with access to every database, every integration, every approved domain. Convenient to set up; high blast radius.
    2. Treating agent audit logs as theoretical. They exist for a reason. If you never look, you won’t catch the problem until it’s downstream.
    3. Letting agents act on opposing-party data. Agents writing to customer-facing systems autonomously needs much higher review.

    What to read next

    Workers + External APIs, MCP, AI-Native Company Patterns, Notion AI for Legal Ops.

  • Multi-Agent Orchestration in Notion: When One Agent Hands Off to Another

    Multi-Agent Orchestration in Notion: When One Agent Hands Off to Another

    Multi-Agent Orchestration in Notion: When One Agent Hands Off to Another

    The 60-second version

    Single mega-agents are tempting and bad. Specialized agents in a sequence with clear handoffs are harder to design but much more reliable. The principle: each agent does one thing well and hands a structured result to the next. Three handoffs is about the practical limit before debugging becomes painful. Beyond three, refactor.

    Three orchestration patterns that work

    1. The pipeline pattern.
    Agent A produces structured output → Agent B consumes and produces → Agent C consumes and produces final result. Each agent’s output schema matches the next agent’s input schema. Clear linear flow.
    2. The router pattern.
    A routing agent decides which specialist agent should handle the request, then dispatches. Specialists are scoped tightly to their domain. The router doesn’t do work itself; it just routes.
    3. The reviewer pattern.
    A producer agent generates output. A reviewer agent checks against criteria and either approves or returns specific feedback. Iterates until approved or max-attempts hit.

    Three patterns that fail

    1. Recursive agent chains. Agent A calls Agent B which calls Agent A again. Debugging is awful. Don’t.
    2. Shared mutable state. Two agents writing to the same database row simultaneously. Race conditions and overwrites. Don’t.
    3. Implicit handoffs. Agent A produces unstructured text; Agent B parses it. The first format change breaks everything. Use structured handoffs.

    Designing the handoff contract

    The handoff between agents is the highest-risk surface. Three rules:
    – Define the schema explicitly. The output of Agent A is JSON-schema-validated input to Agent B.
    – Version the schema. Schema changes are breaking changes. Version like APIs.
    – Test the handoff in isolation. Mock Agent A’s output; test Agent B’s handling. Mock Agent B’s expected input; test Agent A’s production.

    Where orchestration goes wrong in production

    1. Cost compounds with depth. Each agent call consumes credits. A three-handoff workflow costs roughly 3x a single-agent workflow. Budget accordingly.
    2. Latency compounds too. A 5-second agent x 3 handoffs is 15 seconds end-to-end.
    3. Failure modes multiply. Agent A succeeds, Agent B fails, what happens? Define the failure handling explicitly.

    What to read next

    Workers for Agents in TypeScript, Building Your First Skill, Error Handling in Notion AI Workflows, Custom Agents vs Basic.

  • Workers for Agents in TypeScript: Patterns That Hold Up in Production

    Workers for Agents in TypeScript: Patterns That Hold Up in Production

    Workers for Agents in TypeScript: Patterns That Hold Up in Production

    The 60-second version

    Workers reward a specific style of TypeScript: small, single-purpose, structured-input-and-output, well-typed. The constraints (30 seconds, 128MB, no state) push you toward this style automatically. Workers that hold up in production share patterns: typed input/output schemas, defensive HTTP calls with timeouts, structured error returns, no hidden side effects.

    Five production patterns

    1. Type your input and output.
    Type strictly. The agent works against the schema. Schema drift breaks the agent silently.
    2. Defensive HTTP with timeouts.
    External API calls inside a 30-second budget need their own timeouts. A 25-second API call leaves 5 seconds for everything else. Set explicit fetch timeouts shorter than the Worker timeout.
    3. Structured error returns instead of throws.
    Throw inside a Worker and the agent gets opaque failure. Return structured error objects and the agent can reason about the failure and respond gracefully.
    4. Idempotency where state matters.
    Workers have no persistent state, but they can hit external systems that do. If the external call is non-idempotent (e.g., creates a record), include an idempotency key derived from input. Calling the Worker twice should produce one record, not two.
    5. Approved domains as a deployment artifact.
    Track domain approvals in code. When a Worker stops working in production, “did the approved domains change” is the first thing to check.

    Three production failures to design around

    1. The 30-second wall. Aim for under 5 seconds typical, under 15 worst case. Long calls fail under retry loads.
    2. Silent domain blocks. A Worker calling a non-approved domain fails with an error that isn’t always obvious. Log every outbound destination.
    3. Memory leaks via large responses. Don’t pull a 50MB JSON response into a 128MB Worker. Stream, paginate, or pre-filter at the source.

    Testing strategy

    Unit-test the Worker logic separately from the agent. Use mock HTTP. Then integration-test with the actual agent calling the Worker. The two test layers catch different bugs.

    What to read next

    Workers + External APIs, Notion AI Meets MCP, Workers for Agents foundation piece, Security Posture.

  • Building Your First Notion Skill: A Step-By-Step Walkthrough

    Building Your First Notion Skill: A Step-By-Step Walkthrough

    Building Your First Notion Skill: A Step-By-Step Walkthrough

    The 60-second version

    Building a skill that works on the first try is rare. Building a skill that works after three iterations is normal. The discipline is starting with a narrow scope, writing specific instructions, testing against real inputs, and tightening based on what fails. Most operators build skills that are too broad and too vague. The fix is the opposite of intuition — narrower, more specific, more bounded.

    Step-by-step

    Step 1 — Pick the right first skill. Not the most ambitious one. The most repetitive one. “Weekly digest from project database” is a great first skill. “Generate our entire content strategy” is a terrible first skill.
    Step 2 — Write the instructions. Specific format. Specific sections. Specific length. Specific tone. “Summarize” produces variance; “Produce a one-page summary with these five sections in this order, max two sentences per section, in active voice” produces consistency.
    Step 3 — Bound the context. Which database does it read? Which pages? Which fields? Pin tightly. Expand only when needed.
    Step 4 — Test five times. Run the skill against five different real inputs. Look at outputs side by side. The variance you see is the variance you’ll get in production.
    Step 5 — Tighten based on failures. What was wrong in any output? Update the instructions to prevent that. Re-test. Loop.
    Step 6 — Document the skill. Note what it does, when to call it, and what its known failure modes are.

    Three patterns that fail

    1. The mega-skill. A skill that “drafts the weekly report including stakeholder updates and exec summary and content calendar.” Break it into three skills.
    2. The vague skill. “Help me write.” Define what kind of help, what kind of writing, in what format.
    3. The unbounded skill. No context boundaries. The agent reads everything and produces something that sounds related to nothing.

    Where this goes wrong

    1. Skipping the five-test step. Skills that work once fail differently. Test variance early.
    2. Treating skills as static. Skills need maintenance. When a database schema changes, the skill changes.
    3. Building too many skills too fast. Three great skills beat ten mediocre ones.

    What to read next

    How Notion Skills Work, Custom Agents vs Basic, Workers for Agents, Prompt Patterns That Work Inside Notion.

  • Notion Agents vs n8n Alone: When the Workflow Belongs Inside Notion

    Notion Agents vs n8n Alone: When the Workflow Belongs Inside Notion

    Notion Agents vs n8n Alone: When the Workflow Belongs Inside Notion

    The 60-second version

    This isn’t either-or. n8n is the deterministic workflow engine — when X happens, do Y across these 5 apps. Notion Agents are the reasoning layer — given the context, decide whether X actually warrants action and what the right action is. Combined via the n8n MCP bridge, they form a complete automation stack: agent reasons, n8n executes. Operators who treat them as competitors miss the leverage.

    When Notion Agents win

    • The workflow needs to read and synthesize Notion workspace content
    • Natural-language understanding of context matters
    • The “decide whether to act” question is the hard part
    • Schedule-driven autonomous work is the goal
    • The workflow output is itself in Notion

    When n8n wins

    • Pure cross-app data movement (no reasoning needed)
    • Hundreds of integration options matter
    • Visual workflow building with branching logic
    • High-volume deterministic automations
    • Workflows that don’t touch Notion at all

    The combined pattern

    The pattern that’s emerging:
    – Notion Agent decides what to do based on context
    – n8n workflow executes the cross-app coordination
    – Connected via the n8n MCP bridge inside Notion
    Example: Agent reads new lead in Notion → reasons whether it matches ICP → if yes, calls n8n workflow that updates Salesforce, sends Slack notification, schedules follow-up email.

    What n8n does that Notion Agents don’t

    • Massive integration catalog (Salesforce, Stripe, hundreds of others)
    • Visual flow building
    • High-throughput deterministic execution
    • Self-hosting option for compliance-sensitive use cases

    What Notion Agents do that n8n doesn’t

    • Natural-language understanding of unstructured workspace content
    • Native Notion database manipulation
    • Skills (saved natural-language workflows)
    • Workers for custom code execution
    • Schedule-driven autonomous reasoning

    Where this goes wrong

    1. Trying to do everything in one tool. Reasoning in n8n (limited) or deterministic execution in Notion Agents (expensive) is the wrong direction.
    2. Skipping the MCP bridge. Without it, you re-implement n8n integrations as Workers. Don’t.
    3. Letting agent reasoning replace simple n8n triggers. If the trigger is “row added to database,” that’s deterministic. Just use n8n.

    What to read next

    n8n MCP Bridge, Workers + External APIs, Notion AI vs Zapier, MCP foundation piece.

  • The n8n MCP Bridge: Letting Notion Agents Run Your Existing Automations

    The n8n MCP Bridge: Letting Notion Agents Run Your Existing Automations

    The n8n MCP Bridge: Letting Notion Agents Run Your Existing Automations

    The 60-second version

    n8n is where many ops teams already run their cross-app automations. Notion’s n8n MCP bridge lets Custom Agents call those automations as tools. The agent decides what to do; n8n executes the cross-app work. This combines two strengths: Notion AI’s natural-language understanding and database fluency, and n8n’s mature integration library and workflow tooling. You don’t have to rebuild your n8n setup inside Notion.

    What this enables

    Three patterns that get easier:
    1. Agent-triggered cross-app workflows. Agent reads a Notion page, decides an action is needed, calls the relevant n8n workflow which handles the actual work (Salesforce update, Stripe charge, file move, whatever).
    2. Existing n8n investment compounds. Every n8n workflow you’ve built becomes a tool the agent can use. The library grows as your agent-callable surface grows.
    3. Workflow logic stays in n8n. When the workflow logic changes, you change it in n8n once. All agents using that workflow inherit the change automatically.

    When to use n8n vs Workers

    Notion has Workers (developer preview) for custom code. n8n is for cross-app workflows. The split:
    – Workers when you need custom logic that doesn’t exist as an integration
    – n8n when you need to coordinate across many existing apps with mature connectors
    – Both for complex flows where Workers handle specific computation and n8n handles app coordination
    For most ops teams, n8n is the right starting point. Workers are an advanced layer.

    Where this goes wrong

    1. Treating the agent as a smarter n8n trigger. The agent’s value is judgment about when to run the workflow. If you can express the trigger as a simple condition, just run n8n directly.
    2. Letting agents call destructive workflows without confirmation. Agent + n8n + Salesforce delete = potential disaster. Add human approval steps for destructive operations.
    3. Not versioning n8n workflows that agents call. When you change a workflow, agents don’t know. Version your workflows so agent prompts can pin to specific versions.

    What to read next

    Workers for Agents, MCP foundation piece, Notion Agents vs n8n Alone, The Solo Operator’s Stack.

  • Workers + External APIs: Building a Notion Agent That Talks to Anything

    Workers + External APIs: Building a Notion Agent That Talks to Anything

    Workers + External APIs: Building a Notion Agent That Talks to Anything

    The 60-second version

    Before Workers, Notion AI couldn’t reliably call external APIs. With Workers (developer preview), an agent can talk to anything — internal CRMs, public APIs, payment processors, shipping trackers — provided you’ve configured a Worker for it. Workers are sandboxed (30-second timeout, 128MB memory, approved-domain HTTP only) and run on Vercel Sandbox infrastructure. The setup is API-only as of April 2026; this isn’t a point-and-click feature, it’s a developer feature.

    The basic Worker pattern for API calls

    1. Agent receives a prompt requiring external data
    2. Agent calls Worker with structured input (e.g., {orderId: 123})
    3. Worker makes HTTP request to the approved external API
    4. Worker parses response, returns structured output to agent
    5. Agent incorporates result into its natural-language response
      This is the core loop. Everything else is variations on it.

    Three Worker + API patterns

    1. The data lookup Worker. Agent needs current information not in Notion. Worker calls external API (CRM, ERP, public data source), returns structured result. Common for “what’s the status of order X” type queries.
    2. The transform-and-write Worker. Agent receives data, Worker reshapes it for an external system, Worker writes via the external API. Common for syncing data from Notion to other systems.
    3. The orchestration Worker. Worker calls multiple APIs in sequence, collects results, returns synthesis to agent. Common for cross-system workflows that don’t fit n8n’s pattern.

    Approved domains and security

    Workers can only call domains you’ve added to the approved list. This is a feature. Two implications:
    – Plan your domain list before building. Adding domains later requires admin action.
    – Don’t approve broad domains (e.g., *.amazonaws.com) — be specific.

    Where this goes wrong

    1. Hitting the 30-second timeout. Workers aren’t for long jobs. Slow APIs need different patterns (queue + poll, or split into multiple Workers).
    2. Letting Workers call destructive endpoints without verification. Worker calling DELETE on a customer record is a single-line bug away from disaster. Add confirmation patterns.
    3. Treating Workers as Lambda. Workers are constrained for security reasons. The 30-sec/128MB limits are intentional. Build accordingly.

    What to read next

    Workers for Agents foundation piece, Workers in TypeScript (Deep Technical), n8n MCP Bridge, Security Posture.

  • Notion AI for Finance: Close Calendars, Variance Notes, and the Reconciliation Trail

    Notion AI for Finance: Close Calendars, Variance Notes, and the Reconciliation Trail

    Anchor fact: Custom Agents can manage close calendars, draft variance commentary, sequence reconciliations, and produce audit-ready documentation — but should never autonomously approve journal entries or sign off on financial statements.

    How does a finance team use Notion AI?

    Finance teams use Custom Agents to manage close calendars, draft variance commentary, surface reconciliation exceptions, and prepare audit documentation. The agents handle the documentation and synthesis layer; humans retain decision authority for journal entries, approvals, and any output that gets signed.

    The 60-second version

    Finance work is 60% documentation and synthesis, 40% judgment. Custom Agents handle the documentation and synthesis layer well. Close calendars, variance narratives, reconciliation status, period-over-period write-ups — agents produce these faster than humans and the audit trail is cleaner. The judgment layer — booking entries, approving reconciliations, signing financial statements — stays human. The split is clean and the leverage is real.

    Four finance-specific agent patterns

    1. The close calendar agent. Manages the month-end close sequence. Reads the close database, identifies dependencies, sequences tasks, surfaces blockers daily. Produces the close standup in three sentences instead of a 30-minute meeting.

    2. The variance commentary agent. Reads actuals vs budget. Decomposes variances into drivers. Drafts narrative commentary in your team’s house format. Human reviews, tightens, signs.

    3. The reconciliation status agent. Reads the reconciliation database. Flags reconciliations that have stalled, items aging beyond threshold, balances that don’t tie. Surfaces priority queue for the controller’s morning review.

    4. The audit prep agent. Pulls evidence packages on demand. Given a control number, assembles the testing workpaper, the sample selections, the evidence references, and the deficiency log. Auditor asks for X; you have it in 15 minutes instead of a week.

    What absolutely stays human

    The lines that don’t move:

    • Booking journal entries (agent drafts, human posts)
    • Approving reconciliations (agent surfaces, human signs)
    • Signing off on financial statements (agent prepares; human owns)
    • Estimates and judgmental accruals (the judgment is the work)
    • Anything that goes to a regulator (period)

    The agents do the work that prepares the human to make these calls faster. They don’t replace the calls themselves.

    The audit posture shift

    For SOX-regulated entities, agent audit trails change the conversation with internal and external audit. Every agent action is logged. The reproducibility of evidence packages improves. Sample selections that used to take days assemble in hours. This isn’t theoretical — finance teams running this pattern in 2026 are reducing audit-prep cycle time meaningfully.

    The caveat: audit doesn’t accept “the agent did it” as substantiation. The human review at each gate has to be visible in the trail.

    Where finance teams go wrong

    1. Letting the agent draft commentary without source attribution. Every variance number needs to tie back to an underlying report or pull. Agents that produce commentary without citations are a control weakness.

    2. Skipping period-end re-runs. Agent output reflects the moment it ran. If data changes after the agent drafted commentary, the commentary is stale. Build re-run discipline into the close.

    3. Building one mega-agent for finance. Specialized agents (close, variance, recon, audit) outperform a single agent trying to do everything.

    Agent drafts, human posts. That line doesn’t move.

    Sources

    • Notion 3.3 release notes (February 24, 2026)
    • Tygart Media editorial line

    Continue the journey

    This article is part of the May 3 Cliff Decision journey-pack on Tygart Media. Here’s where to go next:

  • Gates Before Volume: The Counterintuitive Way to Scale Notion AI Output

    Gates Before Volume: The Counterintuitive Way to Scale Notion AI Output

    Anchor fact: AI amplifies whatever editorial infrastructure you have. Tighter inputs and clearer gates produce more reliable output at scale than adding more agents or more credits.

    What does “gates before volume” mean for AI workflows?

    Gates before volume is the principle that scaling AI output requires tightening quality controls before increasing throughput. Adding more agent runs without first improving inputs, prompts, and review checkpoints multiplies bad output, not good output.

    The 60-second version

    The temptation when AI starts working is to run more of it. Resist that. The order that works is gates first — the inputs the agent reads, the prompts it uses, the checkpoints that catch bad output — then volume. Operators who skip the gate-tightening phase end up with high-volume slop. Operators who tighten gates first end up with high-volume quality. Same agent, same model, same credits. The difference is the gates.

    What a gate actually is

    A gate is any checkpoint where output quality gets verified before it propagates downstream. In a Notion AI workflow, gates exist at five points:

    1. Input gate — the data the agent reads (database hygiene)
    2. Prompt gate — the instructions the agent receives (specificity)
    3. Output gate — the format and quality criteria the agent produces against (rubric)
    4. Review gate — the human checkpoint before downstream use
    5. Distribution gate — what triggers final propagation (publish, send, file)

    Each gate is a place where a small fix prevents large drift. Each missing gate is a place where bad output silently propagates.

    The volume trap

    Without gates, scaling looks like this: agent runs once, output is mediocre but acceptable. Operator runs it 10× per week. Now there’s 10× the mediocrity. By month three, the operator has built a content factory that produces volume but nobody trusts the output enough to skip review. The “scale” never actually shipped because everything still goes through human eyes anyway.

    With gates, scaling looks like this: tighten input substrate, write specific prompts, define a rubric, set a review checkpoint, then ramp volume. Each piece that ships clears the gates. Trust accrues. Eventually the review gate can be sampled rather than universal. That’s when the scale is real.

    Five gates worth installing this month

    1. A controlled-vocabulary tag system on the databases your agent reads from
    2. A prompt template library so prompts are versioned, not improvised
    3. A quality rubric for the output type (the foundry article uses a 5-dimension rubric — same idea)
    4. A weekly review window where you sample 10% of agent output
    5. A failure log where caught drift gets recorded so prompts can be tightened

    Why this is hard

    Because gates are boring. Volume is exciting. Adding a new Custom Agent feels like progress. Tightening a tag taxonomy feels like procrastination. The operators who win at AI scale are the ones who can stay with the boring work long enough that the volume is actually trustworthy.

    Same agent, same model, same credits. The difference is the gates.

    Sources

    • Tygart Media editorial line
    • Notion 3.3 release notes (February 24, 2026)

    Continue the journey

    This article is part of the May 3 Cliff Decision journey-pack on Tygart Media. Here’s where to go next:

  • When Not to Use a Notion Agent: The Cases That Stay Manual

    When Not to Use a Notion Agent: The Cases That Stay Manual

    Anchor fact: Custom Agents are powerful but inappropriate for tasks involving novel judgment, regulated content, sensitive personnel matters, or work where the cost of being wrong exceeds the cost of doing it manually.

    When should you not use a Notion AI agent?

    Don’t use Notion agents for tasks requiring novel judgment about people, compliance-sensitive output (legal, medical, financial guidance), one-off work that won’t repeat, or any decision where the cost of being wrong is higher than the cost of doing the work manually.

    The 60-second version

    Notion agents are a hammer. Not everything is a nail. The honest list of tasks that should stay manual is longer than most operators want to admit. Performance reviews. Hiring decisions. Compliance-sensitive drafting. Anything that gets sent to a regulator or a lawyer. One-off work. Anything where the value of doing it yourself is the thinking, not the output. The discipline of saying “not this one” is what separates operators who use AI from operators who use AI badly.

    Five categories that stay manual

    1. Decisions about specific humans. Performance reviews, hiring choices, conflict mediation, layoff decisions. The agent can summarize and surface evidence; it shouldn’t draft the decision. The risk isn’t that the output is wrong — it’s that the decision-maker outsources the moral weight of the call. Don’t.

    2. Regulated or compliance-sensitive output. Legal language, medical guidance, financial advice, anything that gets reviewed by a regulator. Use AI to draft inputs to a human reviewer. Never ship the AI output as final.

    3. Novel work without precedent. “Plan our entry into a new market.” “Write our crisis response if X happens.” Agents synthesize from existing patterns. They struggle when the situation has no analog in your workspace.

    4. One-off tasks. Building a Custom Agent for a task you’ll do once is more work than just doing the task. The investment in setup (prompt, scope, rubric, review) only pays back across many repetitions.

    5. Work where doing it is the point. Strategic thinking. Writing meant to clarify your own ideas. Reflection journals. The output isn’t the value; the doing is. AI shortcuts the doing, which destroys the value.

    The dangerous middle category

    Worse than tasks that obviously shouldn’t be agent work are tasks that look like agent work but aren’t. Examples:

    • “Draft client emails” — sounds like a clear agent task, but the relationship cost of off-tone email outweighs the time saved
    • “Summarize our team’s wins for the board” — looks easy, but framing matters and an agent’s framing is generic
    • “Write our company values” — agents can produce values; only humans can mean them

    The test: if the value of the output depends on being recognizably yours, agent involvement should be limited to research and drafting, not production.

    How to decide

    Three questions before launching a new Custom Agent:

    1. Will I do this task at least 20 times in the next year? (No → don’t build an agent.)
    2. Is the cost of a wrong output bounded? (No → don’t automate it.)
    3. Is the value in the output, not the doing? (No → don’t outsource the doing.)

    If any answer is no, the task stays manual. That’s not a failure of AI. That’s discipline.

    AI shortcuts the doing, which destroys the value.

    Sources

    • Tygart Media editorial line
    • Operator practice notes

    Continue the journey

    This article is part of the May 3 Cliff Decision journey-pack on Tygart Media. Here’s where to go next: