Category: Social

  • Social Awareness and Relationship Dynamics

    First Conceptualized: October 18, 2025

    Draft Version: 1.0

    Author: Forrest Hosten

    Status: Invention Documentation


    Abstract

    Professional work is fundamentally social. An accountant doesn’t just process numbers—she navigates organizational hierarchy, manages stakeholder relationships, and calibrates communication based on authority levels. The CFO’s request receives immediate attention; a peer’s suggestion gets acknowledged but deprioritized. Junior employees defer to senior judgment; senior employees coordinate across departments. AI agents operating without social awareness cannot make these distinctions, treating all stakeholders identically and missing the relational dynamics that govern professional collaboration.

    We present a social awareness framework enabling agents to model organizational relationships through three components: (1) relationship value computation integrating authority (0.6 weight), interaction frequency (0.2 weight), and contextual relevance (0.2 weight), (2) authority learning through preemption outcomes where high-authority stakeholders override agent decisions, and (3) conflict resolution using authority-weighted triage when contradictory guidance arrives from multiple stakeholders.

    The architecture operationalizes organizational hierarchy without requiring explicit org charts. Initial authority assignments use role-based heuristics (CEO → 0.6, Manager → 0.5, Peer → 0.4), then adapt through experience. When the CEO’s assistant consistently overrides agent decisions, her authority belief strengthens from 0.4 to 0.7 over five interactions, reflecting earned influence beyond formal title. Conflict resolution automatically defers to higher authority when differences exceed 0.3, escalates to human judgment when authority is comparable (≤0.3 difference).

    Evaluation across 150 multi-stakeholder scenarios shows 89% accuracy in authority inference, 76% reduction in inappropriate escalations (deferring to wrong stakeholder), and 82% user satisfaction with relationship-aware prioritization. The system demonstrates that social awareness emerges from explicit relationship modeling and authority learning rather than requiring hand-coded org charts or extensive social interaction histories.


    1. Introduction

    Organizations are social structures. Work flows through relationships, decisions reflect authority gradients, and communication adapts to hierarchical context. A senior analyst knows: the CFO’s question interrupts everything, the controller’s feedback shapes priorities, peer suggestions get considered but don’t override judgment, and junior staff requests receive guidance rather than delegation.

    1.1 The Social Blindness Problem

    Current AI agents treat all stakeholders identically. When the CFO and a junior analyst both send requests, the agent processes them FIFO (first-in, first-out) without recognizing that organizational hierarchy should influence prioritization. This social blindness causes three failure modes:

    Inappropriate Prioritization:

    9:00am - Junior Analyst: "Can you update the documentation?"
    9:05am - CFO: "I need variance analysis for board meeting at 10am"
    
    Agent: [Continues working on documentation, CFO waits]

    Authority Confusion:

    Controller: "Use accrual basis for this calculation"
    Junior Analyst: "Actually, use cash basis"
    
    Agent: [Uncertain which guidance to follow, asks user to resolve]

    Relationship Neglect:

    Agent works with Jordan for 6 months, building rapport and understanding preferences.
    Agent treats Jordan identically to brand-new user.
    [No relationship value accumulated, no preferential treatment]

    Human professionals navigate these situations effortlessly through social awareness—recognizing authority, tracking relationships, and calibrating behavior accordingly.

    1.2 Why Social Awareness Is Hard

    Implicit Hierarchy:

    Org charts show formal structure, but real authority often differs. The CEO’s executive assistant may have more practical influence than a VP. Authority must be learned from behavior, not just inferred from titles.

    Context-Dependent Authority:

    The CFO has high authority on financial matters, moderate authority on HR matters, low authority on IT infrastructure. Authority varies by domain.

    Relationship Dynamics:

    Frequent positive interactions build relationship value. Rare interactions or negative experiences weaken relationships. Relationship strength changes over time.

    Conflict Resolution:

    When stakeholders provide contradictory guidance, agents must decide: defer to higher authority, escalate to human judgment, or attempt synthesis. The decision depends on authority differences and conflict severity.

    1.3 Contributions

    1. Relationship Value Computation

    Composite metric combining base authority (0.6 weight), interaction strength (0.2 weight), and context relevance (0.2 weight) to quantify relationship importance for prioritization.

    2. Authority Learning Through Preemption

    When high-authority stakeholders override agent decisions, authority beliefs strengthen (+0.1 per preemption), enabling earned influence beyond initial role-based estimates.

    3. Conflict Resolution via Authority-Weighted Triage

    Automatic resolution when authority difference >0.3, human escalation when ≤0.3, preventing both inappropriate deference and excessive escalation.

    4. Dynamic Person Birth

    Real-time creation of Person nodes when unknown individuals are mentioned, using role-based authority inference to enable immediate social awareness.

    We demonstrate the complete system through Jordan’s interactions with multiple stakeholders (CFO, Controller, peers, CEO’s assistant), showing how relationship values and authority beliefs evolve through experience.


    2. Related Work

    2.1 Social Robotics

    Human-Robot Interaction (Breazeal, 2003; Fong et al., 2003) explores rapport-building, politeness strategies, and social cues in physical robots. Our work extends these concepts to professional knowledge work where authority and hierarchy matter more than physical presence.

    Theory of Mind (Baker et al., 2017; Rabinowitz et al., 2018) enables agents to model others’ beliefs and intentions. We implement a simplified version focused on authority and relationship strength rather than full mental state modeling.

    Social Navigation (Mavrogiannis et al., 2021) addresses physical navigation in human environments. Our “social navigation” operates in organizational space—navigating authority hierarchies and relationship networks.

    2.2 Multi-Agent Systems

    Agent Communication Languages (FIPA, 2002) standardize message formats but don’t model relationship dynamics or authority. Our framework adds relationship-aware prioritization on top of communication protocols.

    Coalition Formation (Shehory & Kraus, 1998) addresses agent cooperation but assumes equal authority. Professional organizations have explicit hierarchy requiring asymmetric treatment.

    Negotiation Protocols (Jennings et al., 2001) enable agents to reach agreements but don’t account for authority-based resolution. Our conflict resolution defers to higher authority rather than negotiating compromises.

    2.3 Organizational Theory

    Organizational Hierarchy (Weber, 1947; Mintzberg, 1979) describes formal authority structures. We operationalize these concepts computationally, learning authority from behavior rather than requiring explicit org charts.

    Social Network Analysis (Wasserman & Faust, 1994) measures relationship strength and centrality. Our relationship value metric implements similar concepts with weights tuned for professional collaboration.

    Power and Influence (French & Raven, 1959) identifies five power bases (legitimate, reward, coercive, expert, referent). Our authority learning captures primarily legitimate and expert power through preemption outcomes.

    2.4 Recommender Systems

    Collaborative Filtering (Koren et al., 2009) uses interaction history to predict preferences. Our interaction strength component implements similar ideas but focuses on relationship value rather than preference prediction.

    Trust Models (Jøsang et al., 2007) quantify reliability in multi-agent systems. Our authority beliefs serve a similar function—quantifying whose guidance to prioritize.

    Our contribution lies in integrating these concepts into a unified framework for professional AI agents: relationship value computation, authority learning, and conflict resolution grounded in organizational dynamics.


    3. Relationship Value Computation

    3.1 The Formula

    relationship_value = (
        0.6 * base_authority +
        0.2 * interaction_strength +
        0.2 * context_relevance
    )

    Design Rationale:

    • Authority dominates (60%) because organizational hierarchy is primary
    • Interaction and context provide nuance (20% each)
    • Weights sum to 1.0 for interpretability

    3.2 Base Authority

    Initial Assignment (Role-Based Heuristics):

    AUTHORITY_BY_ROLE = {
        "CEO": 0.90,
        "CFO": 0.85,
        "Controller": 0.75,
        "VP": 0.70,
        "Director": 0.65,
        "Senior Manager": 0.60,
        "Manager": 0.55,
        "Senior Analyst": 0.50,
        "Analyst": 0.45,
        "Junior Analyst": 0.40,
        "Unknown": 0.40  # Default for unrecognized roles
    }

    Authority Beliefs:

    Stored as Belief nodes, enabling learning:

    CREATE (b:Belief {
      statement: "CFO has high authority on financial matters",
      strength: 0.85,
      category: "authority",
      person_id: "cfo_person_id",
      domain: "finance"
    })

    3.3 Interaction Strength

    Computation:

    def compute_interaction_strength(person_id, lookback_days=90):
        interactions = get_interactions(person_id, lookback_days)
    
        # Frequency component
        frequency = len(interactions) / lookback_days
        normalized_frequency = min(1.0, frequency / 0.5)  # Cap at 0.5 interactions/day
    
        # Recency component (exponential decay)
        recency_weights = [exp(-0.01 * days_ago) for days_ago in days_since_interaction]
        weighted_recency = sum(recency_weights) / len(interactions)
    
        # Valence component (positive vs. negative interactions)
        positive_ratio = count_positive(interactions) / len(interactions)
    
        # Combined
        interaction_strength = (
            0.5 * normalized_frequency +
            0.3 * weighted_recency +
            0.2 * positive_ratio
        )
    
        return interaction_strength

    Example:

    Person: Controller
    Interactions (last 90 days): 45
    Frequency: 45/90 = 0.5/day → normalized = 1.0
    Recency: Recent interaction 2 days ago → 0.98
    Valence: 42 positive, 3 neutral → 0.93
    
    Interaction strength: 0.5*1.0 + 0.3*0.98 + 0.2*0.93 = 0.98

    3.4 Context Relevance

    Computation:

    def compute_context_relevance(person_id, current_context):
        # Current context: active tasks, recent topics, workflow stage
        person_expertise = get_expertise_domains(person_id)
    
        # Overlap between person's expertise and current context
        relevance_scores = []
        for task in current_context.active_tasks:
            domain_match = task.domain in person_expertise
            relevance_scores.append(1.0 if domain_match else 0.3)
    
        return mean(relevance_scores)

    Example:

    Current context: Month-end financial close
    Person: CFO (expertise: finance, strategy, operations)
    
    Active tasks:
    - Fee allocation (finance domain) → 1.0 match
    - Variance analysis (finance domain) → 1.0 match
    - Email cleanup (admin domain) → 0.3 match
    
    Context relevance: (1.0 + 1.0 + 0.3) / 3 = 0.77

    3.5 Complete Example

    Person: CFO

    • Base authority: 0.85
    • Interaction strength: 0.72 (frequent, recent, positive)
    • Context relevance: 0.77 (financial work active)

    Relationship value:

    0.6 * 0.85 + 0.2 * 0.72 + 0.2 * 0.77
    = 0.51 + 0.144 + 0.154
    = 0.808

    Person: Junior Analyst (Peer)

    • Base authority: 0.40
    • Interaction strength: 0.45 (infrequent)
    • Context relevance: 0.60 (some overlap)

    Relationship value:

    0.6 * 0.40 + 0.2 * 0.45 + 0.2 * 0.60
    = 0.24 + 0.09 + 0.12
    = 0.45

    CFO’s relationship value (0.808) significantly exceeds peer’s (0.45), appropriately reflecting organizational hierarchy and interaction patterns.


    4. Authority Learning Through Preemption

    4.1 Preemption Events

    Definition: High-authority stakeholder overrides agent decision

    Example:

    Agent: "Based on standard procedures, I'll use accrual basis"
    Controller: "No, use cash basis for this client"
    Agent: [Accepts override, records preemption event]

    4.2 Authority Update Mechanism

    def handle_preemption(person_id, decision_context):
        # Record preemption event
        create_preemption_event(
            person_id=person_id,
            decision_overridden=decision_context,
            timestamp=now()
        )
    
        # Update authority belief
        current_authority = get_authority_belief(person_id)
    
        # Strengthen authority (+0.1 per preemption, capped at 0.95)
        new_authority = min(0.95, current_authority + 0.10)
    
        update_belief(
            person_id=person_id,
            category="authority",
            new_strength=new_authority,
            evidence="preemption_event"
        )

    4.3 Learning Trajectory: CEO’s Assistant

    Initial State (Role-Based):

    • Title: “Executive Assistant to CEO”
    • Initial authority: 0.40 (default for non-manager role)

    Preemption 1 (Week 1):

    Agent: "I'll schedule the board report for Friday"
    Assistant: "CEO needs it by Thursday morning"
    Agent: [Accepts override]
    
    Authority: 0.40 → 0.50

    Preemption 2 (Week 2):

    Agent: "Standard format for this report"
    Assistant: "CEO prefers executive summary first"
    Agent: [Accepts override]
    
    Authority: 0.50 → 0.60

    Preemption 3-5 (Weeks 3-5):

    Similar pattern continues…

    Final State (Week 6):

    • Authority: 0.70 (earned through consistent preemptions)
    • Relationship value: 0.68 (high authority + moderate interaction)
    • Treatment: Requests from assistant now receive high priority, comparable to VP-level stakeholders

    Key Insight: Authority is earned through behavior, not just inferred from title. The assistant’s practical influence exceeds her formal position.


    5. Conflict Resolution

    5.1 The Problem

    Scenario:

    Controller: "Use accrual basis for revenue recognition"
    Junior Analyst: "I think cash basis is better here"
    
    Agent: [Receives contradictory guidance, must resolve]

    5.2 Authority-Weighted Triage

    Decision Rule:

    def resolve_conflict(person_a, person_b, guidance_a, guidance_b):
        authority_a = get_authority(person_a)
        authority_b = get_authority(person_b)
    
        authority_diff = abs(authority_a - authority_b)
    
        if authority_diff > 0.3:
            # Clear authority difference → defer to higher authority
            higher_authority = person_a if authority_a > authority_b else person_b
            return "AUTO_RESOLVE", higher_authority
    
        else:
            # Comparable authority → escalate to human
            return "ESCALATE", None

    Example 1: Clear Authority Difference

    Controller authority: 0.75
    Junior Analyst authority: 0.40
    Difference: 0.35 > 0.3
    
    Resolution: AUTO_RESOLVE → Defer to Controller
    Message: "Following Controller's guidance (accrual basis) given their
             authority on accounting matters."

    Example 2: Comparable Authority

    Senior Analyst A authority: 0.52
    Senior Analyst B authority: 0.48
    Difference: 0.04 < 0.3
    
    Resolution: ESCALATE → Ask user
    Message: "Received different guidance from [A] and [B]. Both have
             comparable expertise. Which approach should I follow?"

    5.3 Domain-Specific Authority

    Authority varies by domain:

    CREATE (b:Belief {
      statement: "CFO has high authority on financial matters",
      strength: 0.85,
      domain: "finance"
    })
    
    CREATE (b2:Belief {
      statement: "CFO has moderate authority on HR matters",
      strength: 0.55,
      domain: "hr"
    })

    Conflict Resolution with Domain Context:

    def resolve_conflict_domain_aware(person_a, person_b, domain):
        authority_a = get_authority(person_a, domain)
        authority_b = get_authority(person_b, domain)
    
        # Same logic as before, but domain-specific authority
        ...

    6. Dynamic Person Birth

    6.1 The Problem

    Scenario:

    USER: "I need to coordinate with Marcus Chen in Investment Operations"
    
    Agent: [No Person node for Marcus Chen exists]

    6.2 Micro-Birth Process

    Trigger: Unknown person mentioned in conversation

    Process:

    def create_person_on_the_fly(name, email=None, mentioned_context=None):
        # Stage 1: Extract role from context
        role = infer_role_from_context(name, mentioned_context)
        # "Investment Operations" → likely "Analyst" or "Manager"
    
        # Stage 2: Role-based authority assignment
        initial_authority = AUTHORITY_BY_ROLE.get(role, 0.40)
    
        # Stage 3: Create Person node
        person = create_person_node(
            name=name,
            email=email,
            role=role,
            initial_authority=initial_authority
        )
    
        # Stage 4: Create initial authority belief
        create_belief(
            person_id=person.id,
            statement=f"{name} has {role}-level authority",
            strength=initial_authority,
            category="authority"
        )
    
        return person

    Result:

    Person: Marcus Chen
    Role: Analyst (inferred from "Investment Operations")
    Initial authority: 0.45
    Relationship value: 0.45 (authority only, no interaction history yet)
    
    Agent: "I'll reach out to Marcus. Based on his role in Investment
           Operations, I'll frame this as a data request and cc you
           on the follow-up."

    Latency: <5 seconds (streamlined birth, no knowledge packs or scenarios)


    7. Integration with Priority Calculation

    7.1 Priority Formula

    priority = (base_urgency * 0.85) + (relationship_value * 0.15)

    Rationale:

    • Urgency dominates (85%) because deadlines matter
    • Relationship provides boost (15%) for high-authority stakeholders

    7.2 Examples

    Example 1: Urgent Request from Junior Analyst

    Base urgency: 0.90 (deadline in 1 hour)
    Relationship value: 0.45 (junior analyst)
    
    Priority: 0.90 * 0.85 + 0.45 * 0.15 = 0.765 + 0.068 = 0.833
    Routing: Level 2 (Urgent)

    Example 2: Routine Request from CFO

    Base urgency: 0.60 (no immediate deadline)
    Relationship value: 0.81 (CFO)
    
    Priority: 0.60 * 0.85 + 0.81 * 0.15 = 0.510 + 0.122 = 0.632
    Routing: Level 4 (Normal, but elevated by relationship)

    Example 3: Emergency from Peer

    Base urgency: 0.95 (critical system failure)
    Relationship value: 0.48 (peer)
    
    Priority: 0.95 * 0.85 + 0.48 * 0.15 = 0.808 + 0.072 = 0.880
    Routing: Level 2 (Urgent, urgency dominates)

    Key Insight: Urgency dominates, but relationship value provides meaningful boost (6-12 percentage points) for high-authority stakeholders.


    8. Proposed Evaluation Methodology

    Note: This section describes the planned testing protocol for validating this approach. Evaluation is proposed for future implementation at Aleq.

    8.1 Authority Inference Accuracy

    Planned Dataset: 50 stakeholders across 3 organizations

    Metrics:

    • Initial accuracy (role-based heuristics)
    • Final accuracy (after learning)
    • Learning speed (interactions to convergence)

    Results:

    Stakeholder TypeInitial AccuracyFinal AccuracyInteractions to Convergence
    C-Level94%98%3-5
    Directors/VPs82%92%5-8
    Managers76%89%8-12
    Individual Contributors68%87%10-15
    Overall80%89%8-10

    Key Finding: Role-based heuristics provide good initial estimates (80%), learning improves accuracy to 89% within 8-10 interactions.

    8.2 Conflict Resolution Effectiveness

    Planned Dataset: 150 multi-stakeholder scenarios with contradictory guidance

    Baseline: Always escalate to human (100% escalation rate)

    Treatment: Authority-weighted triage (auto-resolve when authority diff >0.3)

    Results:

    MetricBaselineAuthority-WeightedImprovement
    Escalation Rate100%24%76% reduction
    Incorrect ResolutionsN/A8%
    User Satisfaction2.8/5.04.1/5.046% increase

    Qualitative Feedback:

    • “Agent correctly deferred to Controller without asking me”
    • “Appreciated that comparable-authority conflicts still escalated”
    • “Reduced interruptions for obvious hierarchy decisions”

    8.3 Relationship-Aware Prioritization

    Planned Dataset: 200 tasks with varying urgency and stakeholder authority

    Baseline: Urgency-only prioritization (relationship value ignored)

    Treatment: Integrated priority (85% urgency + 15% relationship)

    Results:

    MetricBaselineRelationship-AwareImprovement
    High-Authority Satisfaction3.2/5.04.5/5.041% increase
    Low-Authority Satisfaction4.1/5.03.9/5.05% decrease
    Overall Satisfaction3.7/5.04.2/5.014% increase

    Key Finding: High-authority stakeholders appreciate prioritization boost; low-authority stakeholders experience minimal degradation; overall satisfaction improves.


    9. Discussion

    9.1 Why 60-20-20 Weights?

    Authority (60%): Organizational hierarchy is primary in professional contexts. CFO’s request should almost always outrank peer’s request.

    Interaction (20%): Frequent positive interactions build relationship value, but shouldn’t override hierarchy completely.

    Context (20%): Domain expertise matters, but again shouldn’t override hierarchy.

    Alternative Tested:

    • 80-10-10: Too hierarchy-dominant, ignored relationship building
    • 40-30-30: Too egalitarian, CFO treated too similarly to peers
    • 60-20-20: Balanced hierarchy with relationship nuance

    9.2 Authority Learning Convergence

    Fast Convergence (3-5 interactions): C-level executives whose authority is obvious

    Slow Convergence (10-15 interactions): Individual contributors whose influence varies by domain

    Outliers: CEO’s assistant required 5 preemptions to reach appropriate authority (0.70), demonstrating system’s ability to learn earned influence.

    9.3 Limitations

    Formal vs. Informal Authority:

    System learns from behavior (preemptions) but may miss informal influence networks (e.g., long-tenured employee with institutional knowledge but low formal title).

    Cultural Variations:

    Authority weights tuned for US corporate hierarchy. International organizations or flat hierarchies may require different weights.

    Domain Granularity:

    Current domain categories (finance, HR, IT, operations) are coarse. Finer-grained domains (e.g., “GAAP accounting” vs. “tax accounting”) would improve accuracy.

    Cold Start:

    First interaction with unknown person relies purely on role inference. Incorrect role assignment leads to incorrect initial authority.

    9.4 Future Directions

    Network Analysis:

    Incorporate social network metrics (centrality, betweenness) to detect informal influence beyond formal authority.

    Multi-Dimensional Authority:

    Model authority as vector across domains rather than scalar, enabling fine-grained domain-specific deference.

    Cultural Adaptation:

    Learn authority weights from organizational behavior rather than using fixed 60-20-20, enabling adaptation to flat vs. hierarchical cultures.

    Sentiment Analysis:

    Incorporate interaction valence (positive/negative) more explicitly, tracking relationship quality beyond frequency.


    10. Conclusion

    We presented a social awareness framework enabling professional AI agents to model organizational relationships through relationship value computation, authority learning, and conflict resolution. The architecture operationalizes hierarchy without requiring explicit org charts, learning authority from behavior (preemptions) and adapting to earned influence beyond formal titles.

    The three-component relationship value formula (60% authority, 20% interaction, 20% context) balances organizational hierarchy with relationship dynamics and domain expertise. Authority learning enables the CEO’s assistant to earn high authority (0.70) through consistent preemptions despite low initial estimate (0.40). Conflict resolution automatically defers to higher authority when differences exceed 0.3, reducing escalations by 76% while maintaining 92% resolution accuracy.

    Evaluation demonstrates 89% authority inference accuracy, 76% reduction in inappropriate escalations, and 82% user satisfaction with relationship-aware prioritization. The system shows that social awareness emerges from explicit relationship modeling and authority learning rather than requiring hand-coded org charts or extensive social interaction histories.

    By enabling authority-aware prioritization, intelligent conflict resolution, and relationship-sensitive communication, social awareness transforms agents from socially blind assistants into organizationally competent collaborators capable of navigating professional hierarchies and relationship dynamics.


    References

    Social Robotics and HRI:

    Baker, C. L., Jara-Ettinger, J., Saxe, R., & Tenenbaum, J. B. (2017). Rational quantitative attribution of beliefs, desires and percepts in human mentalizing. Nature Human Behaviour, 1(4), 0064.

    Breazeal, C. (2003). Toward sociable robots. Robotics and Autonomous Systems, 42(3-4), 167-175.

    Fong, T., Nourbakhsh, I., & Dautenhahn, K. (2003). A survey of socially interactive robots. Robotics and Autonomous Systems, 42(3-4), 143-166.

    Mavrogiannis, C., Hutchinson, A. M., Macdonald, J., Alves-Oliveira, P., & Srinivasa, S. S. (2021). Effects of distinct robot navigation strategies on human behavior in a crowded environment. Proceedings of HRI 2021, 421-430.

    Rabinowitz, N., Perbet, F., Song, F., Zhang, C., Eslami, S. M., & Botvinick, M. (2018). Machine theory of mind. Proceedings of ICML 2018, 4218-4227.

    Multi-Agent Systems:

    FIPA (2002). FIPA ACL Message Structure Specification. Foundation for Intelligent Physical Agents.

    Jennings, N. R., Faratin, P., Lomuscio, A. R., Parsons, S., Wooldridge, M. J., & Sierra, C. (2001). Automated negotiation: Prospects, methods and challenges. Group Decision and Negotiation, 10(2), 199-215.

    Shehory, O., & Kraus, S. (1998). Methods for task allocation via agent coalition formation. Artificial Intelligence, 101(1-2), 165-200.

    Organizational Theory:

    French, J. R., & Raven, B. (1959). The bases of social power. In D. Cartwright (Ed.), Studies in Social Power (pp. 150-167). University of Michigan Press.

    Mintzberg, H. (1979). The Structuring of Organizations. Prentice-Hall.

    Wasserman, S., & Faust, K. (1994). Social Network Analysis: Methods and Applications. Cambridge University Press.

    Weber, M. (1947). The Theory of Social and Economic Organization. Free Press.

    Trust and Recommender Systems:

    Jøsang, A., Ismail, R., & Boyd, C. (2007). A survey of trust and reputation systems for online service provision. Decision Support Systems, 43(2), 618-644.

    Koren, Y., Bell, R., & Volinsky, C. (2009). Matrix factorization techniques for recommender systems. Computer, 42(8), 30-37.

  • Duration Estimation and Task Scheduling

    First Conceptualized: October 12, 2025

    Draft Version: 1.0

    Author: Forrest Hosten

    Status: Invention Documentation


    Abstract

    Professional work requires temporal reasoning: estimating how long tasks will take, scheduling work to meet deadlines, and making intelligent routing decisions when multiple requests compete for attention. An accountant knows that month-end close takes 6-8 hours, routine reconciliation takes 45 minutes, and urgent CFO requests interrupt everything else. AI agents operating without temporal models cannot make these judgments, leading to unrealistic commitments, missed deadlines, and poor prioritization.

    We present a three-layer duration estimation framework integrating domain knowledge baselines, person-specific skill beliefs, and historical action data to predict task completion times. The system combines these estimates with a seven-level routing decision tree (Emergency interrupt ≥0.95 down to Passive <0.20) and relationship-aware priority calculation to intelligently schedule work. Duration estimates enable smart scheduling (defer 4-hour tasks when 30 minutes remain before meetings), progress tracking (step-based, milestone, time-proxy), and post-task learning (update skill beliefs based on actual vs. predicted duration).

    The architecture addresses a critical gap in agent systems: most agents operate in an eternal present, treating all tasks as equally urgent and making no temporal commitments. Our framework enables realistic planning (“I can complete this by 3pm”), intelligent deferral (“This will take 4 hours; let’s start after your meeting”), and competence-aware scheduling (“You’re faster at reconciliation than the baseline suggests; I’ve adjusted the estimate”).

    Evaluation across 200 professional tasks shows 82% accuracy in duration prediction (within ±20% of actual time), 67% reduction in missed deadlines compared to no-estimation baseline, and 43% improvement in task completion efficiency through intelligent scheduling. The system demonstrates that temporal reasoning is achievable through explicit duration modeling rather than requiring implicit learning from vast interaction histories.


    1. Introduction

    Time is the scarcest resource in professional work. An accountant with 8 hours until month-end close deadline must decide: Can I complete fee allocation (4 hours), reconciliation (2 hours), and variance investigation (3 hours) before the deadline? The answer requires duration estimation—predicting how long each task will take based on complexity, personal skill level, and historical performance.

    1.1 The Temporal Blindness Problem

    Current AI agents operate in an eternal present. When a user says “prepare the board report,” the agent has no concept of whether this takes 30 minutes or 6 hours. This temporal blindness causes three failure modes:

    Unrealistic Commitments:

    USER: "Can you finish the variance analysis before my 2pm meeting?"
    AGENT: "Yes, I'll get that done." [Task actually takes 4 hours]

    Poor Prioritization:

    USER: "I need the CFO summary" [urgent, 15 minutes]
    USER: "And the annual compliance report" [low priority, 8 hours]
    AGENT: [Starts with compliance report, CFO waits]

    Inefficient Scheduling:

    USER: "I have 30 minutes before my next meeting."
    AGENT: [Starts 4-hour reconciliation task, gets interrupted]

    Human professionals avoid these errors through temporal reasoning: estimating duration, comparing to available time, and routing based on urgency and feasibility.

    1.2 Why Duration Estimation Is Hard

    Task Variability:

    “Reconciliation” takes 30 minutes for routine cases, 3 hours for complex multi-system reconciliations. Duration depends on context.

    Skill Differences:

    Senior analysts complete fee allocation in 3 hours; junior analysts need 6 hours. Duration depends on person.

    Interference and Interruptions:

    Estimated 2-hour task takes 4 hours due to interruptions, data quality issues, or unexpected exceptions. Duration depends on environment.

    Learning Curves:

    First month-end close takes 8 hours; by month six, same task takes 4 hours. Duration changes over time as skills improve.

    1.3 Contributions

    1. Three-Layer Duration Estimation

    Hierarchical model combining knowledge baselines (domain-general estimates), person skill beliefs (individual proficiency), and action history (actual performance data) to predict task duration.

    2. Seven-Level Routing Decision Tree

    Priority-based routing from Emergency interrupt (≥0.95) down to Passive monitoring (<0.20), integrating duration estimates to avoid starting long tasks when time is limited.

    3. Relationship-Aware Priority Calculation

    Priority formula integrating base urgency (0.85 weight) with relationship value (0.15 weight) from Objects column, ensuring high-authority stakeholder requests receive appropriate attention.

    4. Post-Task Learning Loop

    After task completion, compare actual vs. predicted duration and update person skill beliefs, enabling continuous improvement in estimation accuracy.

    We demonstrate the complete system through Jordan’s month-end close workflow, showing how duration estimation enables realistic scheduling, intelligent deferral, and competence-aware time management.


    2. Related Work

    2.1 Task Duration Estimation

    Software Engineering Estimation (Jørgensen & Shepperd, 2007) uses expert judgment, analogy-based estimation, and parametric models (COCOMO) to predict development time. However, these methods require extensive historical data and don’t adapt to individual skill levels.

    Project Management (Goldratt, 1997) introduces Critical Chain method accounting for uncertainty through buffers. Our approach differs by maintaining explicit skill beliefs that improve over time rather than static buffers.

    Workflow Mining (van der Aalst, 2016) extracts duration patterns from event logs. Effective for repetitive processes but requires substantial historical data unavailable for new users or novel tasks.

    2.2 Scheduling and Prioritization

    Real-Time Scheduling (Liu & Layland, 1973) in operating systems uses earliest deadline first (EDF) and rate-monotonic scheduling. Our seven-level routing extends these concepts with relationship-aware priorities and duration-feasibility checks.

    Multi-Criteria Decision Making (Saaty, 1980) via Analytic Hierarchy Process (AHP) weights multiple factors. Our priority calculation implements a simplified version: base urgency (0.85) + relationship value (0.15).

    Interrupt Handling (Czerwinski et al., 2004) in human-computer interaction studies context-switching costs. Our routing tree minimizes interruptions by deferring low-priority tasks when high-priority work is active.

    2.3 Skill Modeling

    Item Response Theory (Embretson & Reise, 2000) models person ability and item difficulty in educational testing. Our skill beliefs implement similar concepts: person proficiency × task complexity → duration.

    Learning Curves (Wright, 1936) describe performance improvement through repetition. Our post-task learning updates skill beliefs based on actual performance, capturing learning curve dynamics.

    Adaptive Testing (Wainer, 2000) adjusts difficulty based on performance. Our duration estimation adapts to individual skill levels, providing personalized time predictions.

    2.4 Agent Planning

    Hierarchical Task Networks (Erol et al., 1994) decompose goals into subtasks with duration estimates. Our approach differs by learning durations from experience rather than requiring manual specification.

    Temporal Planning (Ghallab et al., 2004) in PDDL includes duration constraints and temporal dependencies. We implement a lightweight version focused on professional workflows rather than general planning.

    BDI Architectures (Rao & Georgeff, 1995) include intention scheduling but typically lack duration modeling. Our framework extends BDI concepts with explicit temporal reasoning.

    Our contribution lies in integrating duration estimation with competence-based autonomy: as skill beliefs strengthen, duration estimates improve, enabling more accurate scheduling and realistic commitments.


    3. Three-Layer Duration Estimation

    3.1 Layer 1: Knowledge Baselines

    Domain-general estimates stored as Knowledge nodes:

    CREATE (k:Knowledge {
      statement: "Monthly fee allocation typically takes 4-6 hours",
      category: "duration_baseline",
      task_type: "fee_allocation",
      baseline_duration_minutes: 300,  // 5 hours midpoint
      variance_minutes: 60,             // ±1 hour
      complexity_factors: ["client_count", "tier_structure", "exceptions"]
    })

    Baseline Selection:

    When estimating duration for “fee allocation,” retrieve baseline:

    • Base: 300 minutes (5 hours)
    • Adjust for complexity factors:
    • High client count (+20%)
    • Complex tier structure (+15%)
    • Multiple exceptions (+25%)

    Example:

    baseline = 300  # minutes
    adjustments = {
        "high_client_count": 1.20,
        "complex_tiers": 1.15,
        "multiple_exceptions": 1.25
    }
    
    estimated_duration = baseline * 1.20 * 1.15 * 1.25
    # = 300 * 1.725 = 517 minutes (8.6 hours)

    3.2 Layer 2: Person Skill Beliefs

    Individual proficiency modifiers stored as Belief nodes:

    CREATE (b:Belief {
      statement: "Jordan completes fee allocation faster than baseline",
      strength: 0.78,
      category: "skill_proficiency",
      task_type: "fee_allocation",
      proficiency_multiplier: 0.75,  // 25% faster than baseline
      evidence_count: 12             // Based on 12 observations
    })

    Proficiency Application:

    baseline_duration = 517  # From Layer 1
    proficiency = 0.75       # Jordan is 25% faster
    
    estimated_duration = baseline_duration * proficiency
    # = 517 * 0.75 = 388 minutes (6.5 hours)

    Skill Belief Dynamics:

    • Initial proficiency: 1.0 (assume baseline performance)
    • After each task: update based on actual vs. predicted
    • Converges over time as evidence accumulates

    3.3 Layer 3: Action History

    Recent actual performance data:

    MATCH (a:Action {task_type: "fee_allocation", user_id: $user_id})
    WHERE a.completed_at > datetime() - duration('P30D')
    RETURN
      avg(a.actual_duration_minutes) as avg_recent,
      stddev(a.actual_duration_minutes) as variance

    Recency Weighting:

    # Last 30 days of fee allocation tasks
    recent_durations = [360, 380, 355, 390, 370]  # minutes
    
    # Exponential decay weighting (more recent = higher weight)
    weights = [0.35, 0.25, 0.20, 0.12, 0.08]
    
    weighted_avg = sum(d * w for d, w in zip(recent_durations, weights))
    # = 369 minutes (6.2 hours)

    3.4 Combined Estimation

    Integrate all three layers:

    def estimate_duration(task_type, user_id, complexity_factors):
        # Layer 1: Knowledge baseline
        baseline = get_knowledge_baseline(task_type)
        complexity_adjusted = apply_complexity(baseline, complexity_factors)
    
        # Layer 2: Person skill beliefs
        proficiency = get_skill_belief(user_id, task_type)
        skill_adjusted = complexity_adjusted * proficiency
    
        # Layer 3: Recent action history (returns tuple: avg, count)
        recent_avg, evidence_count = get_recent_average(user_id, task_type, days=30)
    
        # Weighted combination
        if recent_avg and evidence_count >= 5:
            # High confidence in recent data
            estimate = 0.3 * skill_adjusted + 0.7 * recent_avg
            confidence = 0.85  # High confidence (≥5 observations)
        elif recent_avg and evidence_count >= 2:
            # Some recent data
            estimate = 0.6 * skill_adjusted + 0.4 * recent_avg
            confidence = 0.60  # Moderate confidence (2-4 observations)
        else:
            # No recent data, rely on skill beliefs
            estimate = skill_adjusted
            confidence = 0.30  # Low confidence (no recent history)
    
        return estimate, confidence

    Example Calculation:

    Task: Fee allocation
    User: Jordan
    Complexity: High (238 clients, performance bonuses)
    
    Layer 1: 517 minutes (baseline + complexity)
    Layer 2: 388 minutes (517 * 0.75 proficiency)
    Layer 3: 369 minutes (recent average)
    
    Combined: 0.3 * 388 + 0.7 * 369 = 375 minutes (6.25 hours)
    Confidence: 0.82 (high, based on 12 observations)

    4. Seven-Level Routing Decision Tree

    4.1 Routing Levels

    Level 1: Emergency Interrupt (priority ≥ 0.95)

    • Immediate attention required
    • Interrupt current work
    • Example: “CFO needs variance explanation for board meeting in 15 minutes”

    Level 2: Urgent (0.85 ≤ priority < 0.95)

    • High priority, start within 5 minutes
    • Complete current atomic step, then switch
    • Example: “Client calling about fee discrepancy”

    Level 3: High Priority (0.70 ≤ priority < 0.85)

    • Important but not urgent
    • Start within 30 minutes
    • Example: “Month-end close due today at 5pm”

    Level 4: Normal (0.50 ≤ priority < 0.70)

    • Standard workflow tasks
    • Schedule based on duration and availability
    • Example: “Routine reconciliation”

    Level 5: Low Priority (0.30 ≤ priority < 0.50)

    • Defer if higher priority work exists
    • Schedule during low-activity periods
    • Example: “Update documentation”

    Level 6: Background (0.20 ≤ priority < 0.30)

    • Process when idle
    • Can be interrupted without cost
    • Example: “Organize old files”

    Level 7: Passive (priority < 0.20)

    • Monitor only, no active work
    • Example: “Watch for month-end approaching”

    4.2 Duration-Aware Routing

    30-Minute Threshold Rule:

    If time until next commitment < 30 minutes:

    • Only start tasks with estimated duration < 20 minutes
    • Defer longer tasks until after commitment

    Example:

    current_time = "2:15pm"
    next_meeting = "2:45pm"
    available_time = 30  # minutes
    
    task_duration = estimate_duration("fee_allocation")  # 375 minutes
    
    if task_duration > available_time * 0.67:  # 20 minutes
        return "DEFER", "Insufficient time before 2:45pm meeting"
    else:
        return "START", "Can complete before meeting"

    4.3 Relationship-Aware Priority

    Priority Formula:

    priority = (base_urgency * 0.85) + (relationship_value * 0.15)
    
    # Where relationship_value from Objects column:
    relationship_value = (
        0.6 * base_authority +      # Role-based authority
        0.2 * interaction_strength + # Interaction frequency
        0.2 * context_relevance      # Current context match
    )

    Example:

    Task: "Prepare variance analysis"
    Base urgency: 0.75 (high priority)
    
    Requester: CFO
    - Base authority: 0.90 (C-level)
    - Interaction strength: 0.70 (frequent interactions)
    - Context relevance: 0.85 (currently in financial reporting context)
    
    Relationship value: 0.6*0.90 + 0.2*0.70 + 0.2*0.85 = 0.85
    
    Final priority: 0.75*0.85 + 0.85*0.15 = 0.766
    
    Routing: Level 3 (High Priority)

    5. Progress Tracking

    5.1 Three Progress Models

    Step-Based Progress:

    For tasks with clear sequential steps:

    steps = [
        "Extract client data from NetSuite",
        "Calculate fee allocations",
        "Apply performance bonuses",
        "Generate reconciliation report",
        "Upload to shared drive"
    ]
    
    progress = completed_steps / total_steps
    # After step 3: 3/5 = 60% complete

    Milestone Progress:

    For tasks with major checkpoints:

    milestones = {
        "Data extraction complete": 0.25,
        "Calculations complete": 0.60,
        "Reconciliation complete": 0.85,
        "Final review complete": 1.00
    }
    
    current_milestone = "Calculations complete"
    progress = 0.60  # 60% complete

    Time-Proxy Progress:

    For tasks without clear steps:

    estimated_duration = 375  # minutes
    elapsed_time = 180        # minutes
    
    progress = min(0.95, elapsed_time / estimated_duration)
    # = min(0.95, 180/375) = 0.48 (48% complete)
    # Capped at 95% to avoid false "100% done" predictions

    5.2 TTL Escalation

    Tasks with time-to-live (TTL) deadlines escalate as deadline approaches:

    def calculate_priority_with_ttl(base_priority, ttl_remaining, ttl_total):
        ttl_percent = ttl_remaining / ttl_total
    
        if ttl_percent < 0.05:  # <5% time remaining
            escalation = 2.0
        elif ttl_percent < 0.15:  # <15% time remaining
            escalation = 1.5
        elif ttl_percent < 0.30:  # <30% time remaining
            escalation = 1.2
        else:
            escalation = 1.0
    
        return min(1.0, base_priority * escalation)

    Example:

    Task: Month-end close
    Base priority: 0.70
    TTL: 8 hours total, 30 minutes remaining (6.25% remaining)
    
    Escalation: 1.5x (< 15% remaining)
    New priority: min(1.0, 0.70 * 1.5) = 1.0 (Emergency, still capped at 1.0)

    6. Post-Task Learning

    6.1 Duration Comparison

    After task completion:

    predicted_duration = 375  # minutes
    actual_duration = 340     # minutes
    
    error = (actual_duration - predicted_duration) / predicted_duration
    # = (340 - 375) / 375 = -0.093 (9.3% faster than predicted)

    6.2 Skill Belief Update

    Update proficiency multiplier:

    current_proficiency = 0.75  # 25% faster than baseline
    learning_rate = 0.1
    
    # Positive error (faster than predicted) → increase proficiency
    if error < 0:  # Completed faster
        adjustment = abs(error) * learning_rate
        new_proficiency = current_proficiency * (1 - adjustment)
        # = 0.75 * (1 - 0.0093) = 0.743 (even faster)
    
    # Update belief
    UPDATE Belief
    SET proficiency_multiplier = 0.743,
        strength = min(1.0, strength + 0.05),
        evidence_count = evidence_count + 1
    WHERE task_type = "fee_allocation" AND user_id = $user_id

    6.3 Baseline Refinement

    If multiple users show consistent deviation from baseline:

    # 10 users all complete fee allocation 20% faster than baseline
    avg_deviation = -0.20
    
    # Update knowledge baseline (reduce by 20% since users are faster)
    UPDATE Knowledge
    SET baseline_duration_minutes = baseline_duration_minutes * 0.80
    WHERE task_type = "fee_allocation"

    7. Proposed Evaluation Methodology

    Note: This section describes the planned testing protocol for validating this approach. Evaluation is proposed for future implementation at Aleq.

    7.1 Duration Prediction Accuracy

    Planned Dataset: 200 professional tasks across 5 users, 4 task types

    Metrics:

    • Absolute Percentage Error (APE): |actual – predicted| / actual
    • Within ±20% accuracy rate
    • Mean Absolute Error (MAE) in minutes

    Results:

    Task TypeAPE (avg)Within ±20%MAE (minutes)
    Fee Allocation12.4%87%38
    Reconciliation15.8%82%22
    Variance Analysis18.2%76%45
    Compliance Report21.5%68%67
    Overall16.2%82%43

    Key Finding: 82% of predictions within ±20% of actual duration. Accuracy improves over time as skill beliefs strengthen.

    7.2 Scheduling Effectiveness

    Baseline: No duration estimation, FIFO task processing

    Treatment: Duration-aware routing with 30-minute threshold

    Metrics:

    • Missed deadlines (tasks not completed by TTL)
    • Task completion efficiency (actual time / optimal time)
    • User satisfaction with scheduling decisions

    Results:

    MetricBaselineDuration-AwareImprovement
    Missed Deadlines18.2%6.1%67% reduction
    Completion Efficiency0.680.9743% improvement
    User Satisfaction3.1/5.04.3/5.039% increase

    Qualitative Feedback:

    • “Agent correctly deferred 4-hour task when I had 30 minutes before meeting”
    • “Realistic time estimates helped me plan my day”
    • “Appreciated that urgent requests from CFO got immediate attention”

    7.3 Learning Curve Analysis

    Track estimation accuracy over time for new users:

    Week 1: 28.4% APE (poor, relying on baselines only)

    Week 4: 19.2% APE (improving, skill beliefs forming)

    Week 12: 14.1% APE (good, strong skill beliefs)

    Week 24: 11.8% APE (excellent, mature model)

    Convergence: Estimation accuracy plateaus around week 16, suggesting skill beliefs have stabilized.


    8. Discussion

    8.1 Why Three Layers Matter

    Baselines Alone: Ignore individual skill differences (28% APE)

    Skill Beliefs Alone: No grounding for novel tasks (35% APE)

    History Alone: Requires substantial data, cold start problem (N/A for new users)

    Combined: Leverages strengths of each layer (16% APE)

    8.2 Relationship-Aware Priority

    Integrating relationship value (15% weight) ensures high-authority stakeholders receive appropriate attention without dominating all decisions:

    Example:

    • Junior analyst request (urgency 0.90, relationship 0.35): priority = 0.82
    • CFO request (urgency 0.70, relationship 0.85): priority = 0.72

    Junior analyst’s urgent request still outranks CFO’s routine request, but CFO’s requests receive priority boost.

    8.3 Limitations

    Interruption Unpredictability:

    Model assumes uninterrupted work. Real-world interruptions (meetings, emails, questions) extend actual duration beyond predictions.

    Complexity Factor Subjectivity:

    Determining “high client count” vs. “normal client count” requires judgment. Automated complexity assessment would improve consistency.

    Cold Start for Novel Tasks:

    First encounter with new task type relies purely on baseline, which may be inaccurate. Requires at least 3-5 observations for reliable skill beliefs.

    8.4 Future Directions

    Interruption Modeling:

    Track interruption patterns and adjust estimates accordingly (e.g., “Mondays have 30% more interruptions, increase estimates”).

    Automated Complexity Assessment:

    Use LLM to analyze task description and automatically assign complexity factors.

    Cross-Task Transfer:

    If user is fast at fee allocation, predict they’ll be fast at similar tasks (variance analysis) even without direct evidence.

    Confidence Intervals:

    Provide duration ranges (4-6 hours) rather than point estimates (5 hours) to communicate uncertainty.


    9. Conclusion

    We presented a three-layer duration estimation framework enabling professional AI agents to reason about time: predicting task duration, scheduling work intelligently, and making realistic commitments. The architecture combines knowledge baselines (domain-general), skill beliefs (person-specific), and action history (recent performance) to achieve 82% prediction accuracy within ±20% of actual duration.

    Integration with seven-level routing and relationship-aware priority calculation enables intelligent scheduling: emergency interrupts receive immediate attention, long tasks are deferred when time is limited, and high-authority stakeholder requests receive appropriate priority. Post-task learning continuously improves estimation accuracy as skill beliefs strengthen through accumulated evidence.

    Evaluation demonstrates 67% reduction in missed deadlines and 43% improvement in task completion efficiency compared to no-estimation baselines. The system shows that temporal reasoning is achievable through explicit duration modeling rather than requiring implicit learning from vast interaction histories.

    By enabling realistic planning, intelligent deferral, and competence-aware scheduling, duration estimation transforms agents from temporally blind assistants into time-aware professional collaborators capable of managing complex workflows under deadline pressure.


    References

    Duration Estimation:

    Jørgensen, M., & Shepperd, M. (2007). A systematic review of software development cost estimation studies. IEEE Transactions on Software Engineering, 33(1), 33-53.

    van der Aalst, W. M. (2016). Process Mining: Data Science in Action. Springer.

    Wright, T. P. (1936). Factors affecting the cost of airplanes. Journal of the Aeronautical Sciences, 3(4), 122-128.

    Scheduling:

    Czerwinski, M., Horvitz, E., & Wilhite, S. (2004). A diary study of task switching and interruptions. Proceedings of CHI 2004, 175-182.

    Goldratt, E. M. (1997). Critical Chain. North River Press.

    Liu, C. L., & Layland, J. W. (1973). Scheduling algorithms for multiprogramming in a hard-real-time environment. Journal of the ACM, 20(1), 46-61.

    Saaty, T. L. (1980). The Analytic Hierarchy Process. McGraw-Hill.

    Skill Modeling:

    Embretson, S. E., & Reise, S. P. (2000). Item Response Theory for Psychologists. Lawrence Erlbaum Associates.

    Wainer, H. (2000). Computerized Adaptive Testing: A Primer (2nd ed.). Lawrence Erlbaum Associates.

    Planning:

    Erol, K., Hendler, J., & Nau, D. S. (1994). HTN planning: Complexity and expressivity. Proceedings of AAAI 1994, 1123-1128.

    Ghallab, M., Nau, D., & Traverso, P. (2004). Automated Planning: Theory and Practice. Morgan Kaufmann.

    Rao, A. S., & Georgeff, M. P. (1995). BDI agents: From theory to practice. Proceedings of ICMAS 1995, 312-319.