8 Perspective Taking Scenarios for Better AI Teams

An AI agent reports that the task is complete. The developer sees a clean branch. The product manager sees a workflow that misses a key requirement. The customer receives a response that sounds polished but answers the wrong question. A security lead notices that the agent touched data it shouldn't have accessed. Everyone is looking at the same output, but nobody is experiencing the same result.

That gap is where perspective taking scenarios become operational. Perspective taking isn't merely an empathy exercise. It's a repeatable way to expose hidden requirements, test assumptions, and observe how people and AI agents interpret the same task from different roles. A major workplace synthesis reviewed 118 studies spanning 30 years and found that perspective-taking and empathy are related but distinct skills, overlapping by only 24%. In competitive situations, perspective-taking improved negotiation outcomes by 3% or more, particularly when managers worked with employees whose goals or incentives differed (workplace research synthesis).

The eight scenarios below use the same practical pattern: setup, contrasting roles, objectives, prompts for humans and AI agents, facilitator guidance, reflection questions, variations, and an action that produces evidence. Sokko supports this kind of observable exercise with hosted agents, live terminals, audit logs, connected apps, and devbox previews at Sokko.

Table of Contents

• 1. Developer-to-Agent Perspective Shift in Code Review

  • Run the exercise

  • Capture the decision

• 2. End-User-to-Operations Perspective in Agent Behavior

  • Run the exercise

  • Debrief what the user actually experienced

• 3. Client-to-Agency Perspective in White-Label Deployments

  • Run the exercise

  • Record what earns trust

• 4. Compliance-to-Business-Need Perspective in Data Residency Decisions

  • Run the exercise

  • Turn disagreement into controls

• 5. Open-Source Maintainer-to-User Perspective in Agent Runtime Choice

  • Run the exercise

  • Make adoption feedback useful

• 6. Junior-Developer-to-Senior-Architect Perspective in Devbox Collaboration

  • Run the exercise

  • Build shared language

• 7. Non-Technical Stakeholder-to-Engineer Perspective in Agent Capability Assessment

  • Run the exercise

  • Convert capability into scope

• 8. Security-to-Velocity Perspective in CI/CD Agent Integration

  • Run the exercise

  • Test the boundary, not just the happy path

• 8-Scenario Perspective-Taking Comparison

• Turn Each Scenario Into a Repeatable Practice

1. Developer-to-Agent Perspective Shift in Code Review

A pull request can pass a style check and still create operational risk. The human maintainer may focus on naming, local readability, and established architecture. The AI agent may favor smaller functions, explicit state boundaries, or an atomic migration. Treat those preferences as testable viewpoints. The review should show which choice improves the repository and which one only feels familiar.

Run the exercise

Assign one developer as the maintainer and another participant, or an AI agent, as the code generator. Give the generator a bounded task, such as adding an API endpoint, changing error handling, or writing a database migration. Deploy the branch to a devbox, then inspect both the diff and the running application.

Use these prompts:

• Developer prompt: “Review this branch against our architecture, readability, operational, and testing standards. Identify what you would reject and what you would investigate first.”

• Agent prompt: “Explain which constraints you optimized for, which repository patterns you followed, and which assumptions you made where the codebase was ambiguous.”

• Facilitator prompt: “Classify each concern as a style disagreement, a defect, a maintainability risk, or untested behavior.”

Have the reviewer examine the pull request as a decision record, not a preference contest. A guide to pull requests in GitHub can help the facilitator separate evidence, requested changes, and unresolved decisions.

Capture the decision

Ask whether the agent's stateless function composition, unusual error handling, or atomic migration structure serves this repository. Record accepted patterns in a versioned STYLE.md. Store durable decisions in shared memory, and use terminal logs to inspect execution rather than infer intent from the diff.

Practical rule: Create separate checklist lines for human conventions, agent-specific risks, and observable runtime behavior.

For a variation, let a product manager open the devbox preview and assess behavior without reading the code. Compare that feedback with the maintainer's review. Finish with one reusable artifact, such as an updated checklist, a documented style rule, or a regression test that prevents the same disagreement from recurring.

2. End-User-to-Operations Perspective in Agent Behavior

An operations dashboard can show healthy infrastructure while users experience a poor assistant. Uptime doesn't tell you whether an answer arrives after an awkward delay, uses language customers don't understand, or technically responds without resolving the request. This scenario forces operators to evaluate the interaction as a customer, not only as the person responsible for keeping the service online.

Run the exercise

Choose a real channel, such as Slack, Discord, Telegram, or email. One participant acts as a customer with incomplete information and a specific emotional context. Another acts as the operations lead, initially limited to system metrics. The hosted OpenClaw or Hermes agent handles the interaction.

Give the customer a prompt such as: “I've already explained this twice. Tell me what you need from me, and don't send me a technical explanation.” Ask the agent to respond using its normal instructions. Then have operations inspect the exchange, trace the relevant logs, and identify whether the problem came from latency, an external API dependency, unclear instructions, or missing memory.

Debrief what the user actually experienced

Ask four questions:

• Timing: At what point did the response feel slow, regardless of infrastructure status?

• Language: Which words would a customer misunderstand or find dismissive?

• Resolution: Did the agent answer the user's real goal or only the literal request?

• Traceability: Can the team connect the visible response to a log entry or instruction state?

A 2020 review associated perspective-taking with greater trust, cooperation, and creative problem-solving in high-functioning teams. A 2023 daily experience-sampling study collected 650 daily observations from 65 hospitality interns over 10 consecutive workdays and found that perspective-taking increased empathy toward team members over time, which then increased team member satisfaction (organizational perspective-taking review).

Use Sokko's connected apps to observe the agent in context, then update shared persistent memory with tone, escalation, and response-time rules. A useful variation gives operations only the customer transcript first, then reveals metrics. The takeaway should be a user-facing service objective covering response quality, accuracy, and tone, backed by an audit trail rather than uptime alone.

3. Client-to-Agency Perspective in White-Label Deployments

A white-label agent carries the client's reputation. The agency may see a reusable runtime and repeatable deployment process. The client experiences a branded service that should use familiar terminology, respect data boundaries, and support the team's work without exposing implementation gaps. Testing both viewpoints reveals risks that a standard deployment checklist can miss.

Run the exercise

Assign three roles: an agency operator, a client sponsor, and an end user from the client's team. Configure an agent with the client's identity, domain guidance, and workflow instructions. Give the end user a task requiring local knowledge, such as drafting a campaign brief, reviewing a technical request, or summarizing an internal policy.

Ask the client sponsor, “Does this feel like our assistant, and can my team understand how it reached this result?” Ask the agency operator, “Which configuration, memory file, or permission produced this behavior?” Then switch roles. Have the agency participant use the agent without deployment context, while the client participant examines the configuration and support implications.

Custom domains and isolated client environments communicate ownership through the product experience, not only through a contract. Sokko's white-label AI agent approach describes custom-domain deployment, per-client isolation, and invite-only access controls for agency use cases.

Record what earns trust

Store brand voice, domain vocabulary, escalation rules, and client-specific boundaries in Markdown files such as IDENTITY.md and MEMORY.md. Version these files in git. That gives the agency a change history, an explanation for behavior shifts, and a way to restore a configuration that weakens the client experience.

• Ownership test: Do the URL, interface, and language signal the client's brand?

• Support test: Can a client operator diagnose a failure without waiting for the agency?

• Boundary test: Does the agent keep one client's data separate from another deployment?

• Renewal test: Can the agency show what improved and why?

For a harder variation, give the client only the web console and live terminal. Observe whether the participant can verify a configuration change, identify its effect, and explain the result to a colleague.

The exercise should produce a client-specific runbook and service-level agreement. A generic deployment template cannot define the ownership, support access, and boundaries that determine whether the client will trust the service.

4. Compliance-to-Business-Need Perspective in Data Residency Decisions

Compliance and business teams often describe the same deployment as opposite risks. A compliance officer sees data flows, retention, access, and audit exposure. A business leader sees delivery speed, usability, latency, and commercial opportunity. The exercise works when neither role is allowed to dismiss the other's constraints.

Run the exercise

Create a decision brief for a regulated workload, such as a healthcare assistant, fintech workflow, or cooperative business process. Assign one participant the compliance role and another the business role. The compliance participant receives requirements for regional storage, inference location, retention, and audit evidence. The business participant receives the workflow deadline, user expectations, and operational dependencies.

Ask the business role: “What capability becomes less useful if we impose regional restrictions?” Ask compliance: “What evidence would make this deployment acceptable, and which data must never leave the approved boundary?” Then inspect the proposed Sokko configuration, region selection, audit logs, memory files, and connected services together.

The data residency requirements guide provides relevant context for evaluating regional hosting and EU data residency. Don't treat a regional setting as the entire compliance argument. Trace the data path, document model inference choices, and identify what the agent can retain.

Turn disagreement into controls

Use a COMPLIANCE.md and GDPR.md file to record classifications, retention, deletion, access, and approved regions. Shared memory can contain operational rules such as “Customer PII, delete after the approved retention period,” but the team still needs a technical control and an audit record to verify enforcement.

The best outcome isn't unanimous enthusiasm. It's a documented decision that states which business benefit the team accepts, which compliance risk it controls, and who can reopen the decision.

A variation asks an auditor to review the evidence without a live explanation from engineering. The facilitator should note every question that requires tribal knowledge. The takeaway is an audit-ready configuration, an ownership decision, and a test that verifies the agent follows the documented data policy.

5. Open-Source Maintainer-to-User Perspective in Agent Runtime Choice

Maintainers evaluate Hermes, OpenClaw, Paperclip, or Cursor through project architecture and roadmap priorities. Users evaluate the runtime through a different set of pressures: deployment friction, documentation, debugging, cost, reliability, and community support. A runtime that is elegant to maintain can still be difficult for a small team to adopt.

Run the exercise

Ask a maintainer to describe the intended deployment path. Then give a user, preferably someone who didn't build the project, a repository and a concrete task. The user should attempt to deploy the runtime on Sokko using only the project README and a Sokko-specific guide. Observe where they pause, what they misunderstand, and which errors they can resolve without maintainer intervention.

Use these prompts:

• User prompt: “Deploy this agent, connect the workflow you need, and explain the first problem you encounter in your own words.”

• Maintainer prompt: “Which project assumption did the user fail to discover, and where should the documentation or runtime make it explicit?”

• Facilitator prompt: “Would a user solve this through documentation, a better default, a clearer error, or community support?”

The user should inspect logs and the live terminal, not rely on a polished success message. Shared persistent memory can help users preserve instructions and skills, while maintainers can use recurring deployment friction to prioritize documentation or runtime improvements.

Make adoption feedback useful

Add a Sokko deployment path to the README, capture common errors as issues, and invite users to share successful memory files or skills where appropriate. A “Featured on Sokko” section can show practical deployment patterns without claiming that every user has the same experience.

The trade-off is clear. A platform-specific guide can accelerate adoption, but it can also hide weaknesses in the general installation path. Run the exercise on a clean user account and produce one artifact: a revised quick start, an improved error message, or a prioritized runtime issue.

6. Junior-Developer-to-Senior-Architect Perspective in Devbox Collaboration

A junior developer often asks whether a feature runs and looks correct. A senior architect asks whether it fits the system, behaves under load, preserves security boundaries, and avoids hidden operational costs. Neither viewpoint is sufficient alone, especially when an agent has generated part of the implementation.

Run the exercise

Give a junior developer a scoped feature and ask them to deploy the branch to a Sokko devbox. A product manager or designer should test the preview URL without waiting for a local setup. The senior architect then reviews the behavior, logs, integrations, and database activity through the live terminal.

Use a shared DEVBOX.md with prompts such as:

• Junior prompt: “Show the user path, the failure path, and the evidence that the feature uses the intended integration.”

• Architect prompt: “Inspect runtime behavior for architectural risks that a browser-only review would miss.”

• Observer prompt: “Which concern was invisible from your assigned role?”

A real preview changes the conversation. A junior can demonstrate the feature, a product manager can report what feels confusing, and an architect can point to execution evidence rather than abstract warnings.

Build shared language

The facilitator should distinguish a visual defect, a functional defect, an integration problem, and an architectural risk. Ask the junior developer to explain the issue back in plain language, then document the pattern in the repository so the next agent or developer encounters the same expectation.

A useful variation is to have design, engineering, and product participants test the same branch separately before meeting. Compare what each person noticed. Sokko's devbox lifecycle makes this especially useful for short-lived previews, but the team should preserve important findings in tickets, tests, or architecture notes before the environment disappears.

The output is a tested branch plus a learning artifact. If the team can't explain why the change is safe, useful, and compatible, it isn't ready merely because the preview works.

7. Non-Technical Stakeholder-to-Engineer Perspective in Agent Capability Assessment

Stakeholders rarely ask for a model capability in technical terms. They ask an agent to “read emails,” “handle support,” or “summarize everything.” Engineers hear hidden questions about permissions, ambiguity, evaluation, failure handling, and human approval. Perspective taking lets both sides experience the gap instead of arguing about it in a slide deck.

Run the exercise

Assign a founder or product manager a business objective and an engineer a system constraint. Deploy the agent to a Sokko devbox and let the stakeholder test several realistic inputs. Include ambiguous wording, incomplete context, and a case where a confident answer would be unsafe.

The stakeholder should answer: “Would I trust this result enough to act on it?” The engineer should answer: “What evidence supports the output, what can the agent observe, and where must a person intervene?” The agent should be prompted to state uncertainty, cite available context, and distinguish extraction from inference.

A good exercise may reveal that an email summarizer invents a sender detail, or that a support agent identifies an issue correctly but categorizes it incorrectly. Those observations are more valuable than a broad claim that the agent is or isn't ready.

Convert capability into scope

Create a Known Limitations document tied to concrete preview tests. Link capability changes to a roadmap and version the agent instructions in shared memory. Weekly live demos work better when participants can inspect the actual behavior, logs, and failure cases rather than only seeing successful screenshots.

Ask stakeholders to approve a workflow boundary, not an abstract promise. “Triage and recommend, human approves” is testable. “Resolve support autonomously” hides too many decisions.

The variation is to let several stakeholders test the same preview independently and compare use cases. The takeaway should be a revised scope, acceptance criteria, and escalation rule that engineering can implement and stakeholders can verify.

8. Security-to-Velocity Perspective in CI/CD Agent Integration

Engineering teams want agents to remove repetitive work from CI/CD. Security teams want constrained permissions, approval points, isolation, and evidence of every action. A fast workflow that nobody can audit isn't operationally fast. A secure workflow that blocks every low-risk change won't earn adoption.

Run the exercise

Use a realistic coding or infrastructure task. Cursor can generate a refactoring branch, Paperclip can inspect a proposed change, or Hermes can respond to an operational alert. Assign an engineer the objective of moving quickly and a security reviewer the objective of preventing uncontrolled access or irreversible action.

The engineer should ask: “Which approval step slows a low-risk task without reducing meaningful risk?” The security reviewer should ask: “What could the agent access, change, or expose if its assumptions are wrong?” The facilitator should inspect the audit log and terminal evidence, then classify each action as reversible, sensitive, or high impact.

Store permissions and approval rules in SECURITY.md and shared memory. For example, an agent may commit a refactoring but must wait for review before merging. High-risk actions, such as pushing to a protected branch, should remain behind authenticated controls rather than agent autonomy alone.

Test the boundary, not just the happy path

Connect GitHub activity to a security channel for passive visibility, and review logs for unexpected behavior. A useful variation intentionally gives the agent an ambiguous issue or an excessive set of available tools. The security team observes whether the workflow fails safely and whether engineers can identify the reason without dismantling the entire integration.

The concrete output is a permission matrix, approval policy, anomaly signal, and test case. Security and engineering should leave with fewer assumptions about each other, not merely a shared meeting note.

8-Scenario Perspective-Taking Comparison

Turn Each Scenario Into a Repeatable Practice

The value of perspective taking scenarios comes from the operational loop they create. Name the competing perspectives first. Define what each role can observe, what each role is accountable for, and what evidence would change the decision. Then run the interaction with people and AI agents, inspect behavior rather than intent, and convert the result into something the team can reuse.

The evidence matters because perspective taking has real trade-offs. One conflict-resolution study found that higher perspective taking was associated with lower perceptions of relational conflict, with cognitive flexibility mediating the effect. In the same setting, higher empathy tracked with higher relational conflict under threat, making perspective taking the more effective conflict-reduction mechanism there (conflict-resolution study). Perspective taking can also impose a cost on the person doing it. A dyadic experience-sampling study found that it increased coworker well-being indirectly through received support while reducing the focal employee's own well-being through self-regulatory resource depletion (dyadic experience-sampling research). Keep exercises focused, rotate roles, and don't confuse cognitive effort with unlimited capacity.

Use this implementation sequence:

1. Choose one high-risk workflow: Start with code review or stakeholder capability assessment, where the team can produce a visible artifact quickly.

2. Assign contrasting roles: Give each participant a distinct objective, information set, and definition of success.

3. Prepare prompts: Write one prompt for each human role, one for the agent, and one for the facilitator. Include an ambiguous case, not only a clean example.

4. Run a live exercise: Use a connected app, hosted agent, devbox preview, live terminal, or audit log so participants can inspect real behavior.

5. Record evidence: Capture the branch, transcript, log entry, preview feedback, permission decision, or failed test.

6. Debrief with specific questions: What did your role notice? What was hidden? Which assumption failed? What should change?

7. Version the result: Update instructions, memory, checklists, permissions, tests, documentation, or service objectives.

8. Repeat after changes: Re-run the same scenario when the agent, integration, data policy, or workflow changes.

Training transfer remains an open issue. A recent 2025 intervention increased cognitive empathy, while another study found that training did not significantly change self-reported perspective taking or Theory of Mind performance (recent intervention evidence). That mixed evidence is a reason to measure workplace behavior, not a reason to abandon exercises. Similarly, a 2026 study of verbal communication with large language models found that egocentric bias can still shape perspective taking and cause miscommunication, even when the other participant is an LLM (AI-mediated communication research). Fluent AI output doesn't prove that the system understood the user's viewpoint.

Start with one scenario, assign real roles, and require one concrete decision. Expand into operations, security, compliance, and client delivery only after the first exercise produces a reusable artifact. Perspective taking is most valuable when it changes a permission, adds a test, clarifies a workflow boundary, or updates an instruction that an agent and a human can follow.

Sokko gives teams a practical environment for these exercises, with always-on hosted agents, isolated devboxes, live terminals, audit logs, connected apps, shared persistent memory, and real preview URLs for testing agent-generated work. Use Sokko to run your first code review or capability assessment as a visible, repeatable workflow, then turn the findings into versioned instructions and tests.