{
  "@context": "https://schema.org",
  "dateModified": "2026-08-17",
  "canonicalUrl": "https://www.dipankar.org",
  "identity": {
    "name": "Dipankar Sarkar",
    "location": "St Andrews, Scotland, United Kingdom",
    "role": "Founder, fractional AI CTO, and applied AI systems engineer",
    "positioning": "I make ambitious AI systems dependable in the real world.",
    "summary": "Across 18+ years, I have taken software, machine-learning products, robotics, and distributed systems from research and architecture into production. My current work focuses on governed agents, durable execution, exact evaluation, local inference, and cloud-to-edge systems."
  },
  "metrics": [
    {
      "value": "18+",
      "label": "years building production systems"
    },
    {
      "value": "100M+",
      "label": "user scale for ML systems at Hike"
    },
    {
      "value": "10/10",
      "label": "seeded kernel defects caught in a measured corpus"
    },
    {
      "value": "6",
      "label": "companies founded across 2008–2024"
    }
  ],
  "outcomes": [
    {
      "number": "01",
      "title": "Let agents act without surrendering control",
      "description": "Put identity, purpose, permissions, approval, evidence, and a stop path around tool-using agents before they cross into real side effects.",
      "evidence": "Regulated banking AI, CloseGate, and Regulus",
      "href": "/research/#governed-agents"
    },
    {
      "number": "02",
      "title": "Make failure visible and recovery deliberate",
      "description": "Treat an agent as a distributed system: explicit state, durable checkpoints, idempotent effects, replay, evaluation, and operator-owned recovery.",
      "evidence": "fast-langgraph and production platform delivery",
      "href": "/research/#durable-systems"
    },
    {
      "number": "03",
      "title": "Measure correctness, not plausibility",
      "description": "Use exact and operator-aware oracles where generated code can compile, benchmark well, and still be wrong.",
      "evidence": "gpuemu and two public 2026 preprints",
      "href": "/research/#correctness"
    },
    {
      "number": "04",
      "title": "Move intelligence closer to data and action",
      "description": "Design the boundary between cloud planning, local inference, edge execution, physical constraints, telemetry, and human responsibility.",
      "evidence": "Cognisoc, RobotGPT, and WareMax",
      "href": "/research/#edge-and-physical-ai"
    }
  ],
  "proofFamilies": [
    {
      "id": "governed-agents",
      "status": "Public reference systems + delivery experience",
      "title": "Governed agents",
      "promise": "High-impact agent actions remain permissioned, reviewable, interruptible, and explainable.",
      "detail": "CloseGate demonstrates action tiers, segregation of duties, mandatory approval, materiality routing, and hash-chained audit. Regulus adds identity, purpose, privacy, residency, model-risk tiers, kill switches, and evidence export. Neither system has a published external certification or third-party deployment. At Aveni, I was part of the team in the first FCA Supercharged Sandbox cohort, working on AI for wholesale and compliance innovation.",
      "links": [
        {
          "label": "CloseGate",
          "href": "https://closegate.neullabs.com/"
        },
        {
          "label": "Regulus",
          "href": "https://regulus.neullabs.com/"
        },
        {
          "label": "FCA AI Lab",
          "href": "https://www.fca.org.uk/firms/innovation/ai-lab"
        }
      ]
    },
    {
      "id": "durable-systems",
      "status": "Open source + arXiv preprint",
      "title": "Durable and coordinated agent systems",
      "promise": "Agent work survives crashes, concurrent writers, and the distance between a decision and its side effect.",
      "detail": "fast-langgraph explores durable state and checkpointing. Before the Pull Request studies coordination before code review; in its measured setup, duplicate or conflicting rework fell from 78% to 0%, useful throughput more than tripled, and replicas converged without silently dropped writes.",
      "links": [
        {
          "label": "fast-langgraph",
          "href": "https://github.com/neul-labs/fast-langgraph"
        },
        {
          "label": "Before the Pull Request",
          "href": "https://arxiv.org/abs/2606.19616"
        },
        {
          "label": "grite",
          "href": "https://github.com/neul-labs/grite"
        }
      ]
    },
    {
      "id": "correctness",
      "status": "Open source + arXiv preprints",
      "title": "Exact evaluation for generated code",
      "promise": "A fast generated kernel is useful only after the team can establish that it is correct.",
      "detail": "gpuemu uses operator-aware test generation and reproducible failure artefacts for CUDA and Triton kernels. In the measured corpus, its seeded oracle caught 10 of 10 injected defects while 16 of 16 correct controls stayed clean across five GPU classes. That result does not estimate the defect rate of deployed LLMs.",
      "links": [
        {
          "label": "The Correctness Illusion",
          "href": "https://arxiv.org/abs/2606.20128"
        },
        {
          "label": "Test-Input Generation",
          "href": "https://arxiv.org/abs/2606.27396"
        },
        {
          "label": "gpuemu",
          "href": "https://github.com/Skelf-Research/gpuemu"
        }
      ]
    },
    {
      "id": "edge-and-physical-ai",
      "status": "Delivery experience + public benchmark",
      "title": "Local inference and physical AI",
      "promise": "Keep model placement, physical constraints, review, execution, and recovery explicit from cloud plan to edge action.",
      "detail": "At Orangewood Labs I built RobotGPT, which reduced collaborative-robot programming time by approximately 10× in that specific context, and worked on computer-vision and cloud-to-edge systems. WareMax is a separate deterministic warehouse benchmark for task allocation, reward design, causal delay attribution, and byte-identical replay. Cognisoc explores local inference across multiple language runtimes.",
      "links": [
        {
          "label": "WareMax",
          "href": "https://github.com/Skelf-Research/waremax"
        },
        {
          "label": "Cognisoc",
          "href": "https://github.com/cognisoc"
        }
      ]
    },
    {
      "id": "cloud-operations",
      "status": "Delivery experience",
      "title": "Cloud and Day-2 AI operations",
      "promise": "The deployment is the beginning: ownership, observability, budgets, secrets, retries, evaluation, rollback, and stop conditions make it operable.",
      "detail": "Recent delivery includes agents on Azure AI Foundry and AKS/Kubernetes, custom sandboxing, and MCP in .NET. Earlier work includes Python and AWS document extraction, validation, routing, and LLM workflows. Customer architectures and scale remain confidential.",
      "links": [
        {
          "label": "Neul Labs public work",
          "href": "https://github.com/neul-labs"
        },
        {
          "label": "Personal systems work",
          "href": "https://github.com/dipankar?tab=repositories"
        }
      ]
    },
    {
      "id": "blockchain-infrastructure",
      "status": "Public reference systems",
      "title": "Blockchain infrastructure and safety boundaries",
      "promise": "Make signing policy, cross-chain state, compiler semantics, and agent authority explicit before money or keys move.",
      "detail": "Cryptuon projects cover validator signing policy, atomic multi-rollup actions, commit-reveal timing, EVM and Solana compiler boundaries, and paper-first agent-operated markets. They are public design and implementation artefacts; they do not establish audits, mainnet adoption, returns, or production scale.",
      "links": [
        {
          "label": "nklave",
          "href": "https://github.com/cryptuon/nklave"
        },
        {
          "label": "Tesseract",
          "href": "https://github.com/cryptuon/tesseract"
        },
        {
          "label": "Cryptuon",
          "href": "https://github.com/cryptuon"
        }
      ]
    }
  ],
  "selectedPapers": [
    {
      "year": "2026",
      "status": "arXiv preprint",
      "title": "Test-Input Generation for Tensor Programs: What Actually Finds Kernel Bugs",
      "result": "Seven strategies evaluated on a 26-operator corpus; boundary-only sampling reached 78% recall with 0% false positives on 16 controls.",
      "href": "https://arxiv.org/abs/2606.27396"
    },
    {
      "year": "2026",
      "status": "arXiv preprint",
      "title": "The Correctness Illusion in LLM-Generated GPU Kernels",
      "result": "In the measured corpus, 10/10 seeded defects were caught and 16/16 controls stayed clean across five GPU classes.",
      "href": "https://arxiv.org/abs/2606.20128"
    },
    {
      "year": "2026",
      "status": "arXiv preprint",
      "title": "Before the Pull Request: Mining Multi-Agent Coordination",
      "result": "A controlled study of coordination failures hidden by pull-request history, accompanied by a public code and data corpus.",
      "href": "https://arxiv.org/abs/2606.19616"
    },
    {
      "year": "2020",
      "status": "Accepted at FL-IJCAI 2020",
      "title": "Fed-Focal Loss for Imbalanced Data Classification in Federated Learning",
      "result": "More than nine absolute percentage points improvement on the unbalanced MNIST benchmark, with experiments across four datasets.",
      "href": "https://arxiv.org/abs/2011.06283"
    }
  ],
  "authorship": [
    {
      "year": "2026",
      "title": "AI for Everyday Automation",
      "subtitle": "7 AI Workflows to Save Hours at Work Every Week",
      "format": "Packt book",
      "description": "Connected workflows for email, meetings, research, reports, task tracking, spreadsheets, and professional communication.",
      "href": "/books/ai-for-everyday-automation/"
    },
    {
      "year": "2011",
      "title": "Nginx 1 Web Server Implementation Cookbook",
      "subtitle": "More than 100 recipes for Nginx infrastructure",
      "format": "Packt book",
      "description": "Configuration, application serving, reverse proxies, load balancing, caching, monitoring, and security for Nginx.",
      "href": "/books/nginx-web-server-implementation-cookbook/"
    },
    {
      "year": "2026",
      "title": "The GenAI and Agentic AI Playbooks",
      "subtitle": "21 open chapters in ten languages",
      "format": "Apache-2.0 playbooks",
      "description": "A business-leader guide to GenAI adoption followed by an engineering and operating guide to agent systems.",
      "href": "https://www.whatgenerativeai.com/"
    }
  ],
  "talks": [
    {
      "title": "An AI Agent Walks into Production",
      "subtitle": "State, side effects, recovery, and the stop button",
      "outcome": "A practical architecture for explicit state, idempotent effects, replay, evaluation, and human stop conditions.",
      "audiences": [
        "AI engineering",
        "Platform",
        "SRE"
      ]
    },
    {
      "title": "The Agent That Couldn’t Wire Money",
      "subtitle": "Enforcing least privilege, approvals, and replay across tools",
      "outcome": "An action-tier model, approval-boundary pattern, evidence schema, and adversarial test plan.",
      "audiences": [
        "Agent security",
        "Fintech",
        "Governance"
      ]
    },
    {
      "title": "Your GPU Kernel Passed the Vibe Check. It Is Still Wrong.",
      "subtitle": "Testing generated CUDA and Triton with operator-aware oracles",
      "outcome": "A layered correctness harness and a reproducible way to distinguish plausible output from correct output.",
      "audiences": [
        "ML systems",
        "GPU",
        "Research"
      ]
    },
    {
      "title": "Before the Pull Request",
      "subtitle": "What coordination logs reveal about multi-agent coding",
      "outcome": "A failure taxonomy and minimal protocol for measuring duplicate and conflicting work before code review.",
      "audiences": [
        "Developer tools",
        "Engineering leadership",
        "Agents"
      ]
    },
    {
      "title": "From Prompt to Robot Program",
      "subtitle": "Making physical AI operable from cloud plan to edge execution",
      "outcome": "A systems map for capability grounding, review, permissioned execution, telemetry, recovery, and replay.",
      "audiences": [
        "Robotics",
        "Manufacturing",
        "Warehousing"
      ]
    },
    {
      "title": "Run the Model Where the Data Lives",
      "subtitle": "A polyglot path from cloud API to embedded local inference",
      "outcome": "A decision framework for local versus hosted inference, resource limits, compatibility, and offline operation.",
      "audiences": [
        "Edge AI",
        ".NET",
        "Systems"
      ]
    },
    {
      "title": "Seven AI Workflows That Give the Week Back",
      "subtitle": "From occasional prompts to connected, reviewable work",
      "outcome": "A map for choosing repeatable workflows, connecting tools safely, keeping people in review, and measuring time returned.",
      "audiences": [
        "Business",
        "Operations",
        "AI adoption"
      ]
    },
    {
      "title": "From Generative AI to Agentic AI",
      "subtitle": "What changes when a model can plan, call tools, and retain state",
      "outcome": "A plain-language architecture connecting goals, models, tools, MCP, orchestration, memory, security, evaluation, and production ownership.",
      "audiences": [
        "Leadership",
        "Product",
        "Engineering"
      ]
    }
  ],
  "workshops": [
    {
      "title": "Build a Governed Agent, Not a Hopeful Demo",
      "format": "90–120 minutes or half day",
      "outcome": "Participants add action tiers, human approval, replayable audit, and adversarial policy tests to a tool-using agent."
    },
    {
      "title": "Production Agent Reliability Lab",
      "format": "Two hours, half day, or full day",
      "outcome": "Participants turn a fragile agent loop into explicit state, durable checkpoints, idempotent effects, replay, and stop conditions."
    },
    {
      "title": "Multi-Agent Coordination Before the Pull Request",
      "format": "90–120 minutes",
      "outcome": "Participants expose duplicate work, add task claims and append-only events, reconcile divergent replicas, and mine the log."
    },
    {
      "title": "Build Your Automated Week",
      "format": "90 minutes, half day, or full day",
      "outcome": "Participants choose one recurring task, map its inputs and review points, build an AI-assisted workflow, and define a useful time-and-quality measure."
    }
  ],
  "industries": [
    "Financial services and regulated AI",
    "Robotics, warehousing, and manufacturing",
    "Cloud platforms and developer tooling",
    "Consumer machine learning at scale",
    "Blockchain infrastructure and protocol security",
    "Startups, venture building, and technical diligence"
  ],
  "topicGuides": [
    {
      "slug": "governed-ai-agents",
      "title": "Governed AI Agents: Authority, Approval, and Evidence",
      "directAnswer": "A governed AI agent is not merely a model with a safety prompt. It is a runtime system in which the agent’s identity and purpose are explicit, every tool is classified by the effect it can cause, high-impact actions require policy checks or human approval, and each decision and side effect leaves evidence that can be reviewed and replayed. The control boundary belongs around the action, not only around the text the model produces.",
      "audience": "AI platform teams, financial services, security engineers, governance leaders, and operators deploying tool-using agents.",
      "url": "https://www.dipankar.org/research/governed-ai-agents/",
      "evidence": [
        {
          "label": "CloseGate",
          "status": "Public reference system",
          "text": "A Python and MCP policy layer with 19 tools, action tiers, segregation of duties, materiality and sensitive-account routing, mandatory approval for irreversible actions, and hash-chained replayable audit.",
          "href": "https://closegate.neullabs.com/"
        },
        {
          "label": "Regulus",
          "status": "Public reference system",
          "text": "A runtime-governance architecture for agent identity and purpose, policy, PII, residency, model-risk tiers, kill switches, human oversight, evidence export, and agent-to-agent controls.",
          "href": "https://regulus.neullabs.com/"
        },
        {
          "label": "Regulated banking AI",
          "status": "Delivery experience",
          "text": "At Aveni, Dipankar architected enterprise banking AI with conduct-risk workflows, evidence generation, human review, escalation, evaluation, versioning, and release controls. He was part of the Aveni team in the first FCA Supercharged Sandbox cohort.",
          "href": "https://www.fca.org.uk/firms/innovation/ai-lab"
        }
      ],
      "limitations": [
        "CloseGate and Regulus are public reference systems. Neither has a published independent certification or customer deployment.",
        "Mapping controls to NIST AI RMF or ISO/IEC 42001 does not constitute certification or legal compliance.",
        "The appropriate approval and evidence model depends on the organisation, jurisdiction, action, and accountable human owner."
      ],
      "faqs": [
        {
          "question": "What is the difference between an AI guardrail and agent governance?",
          "answer": "A guardrail usually constrains model input or output. Agent governance also controls identity, authority, tool effects, approval, evidence, recovery, and organisational accountability after a model has made a decision."
        },
        {
          "question": "Should every AI agent action require human approval?",
          "answer": "No. Low-impact, reversible, well-observed actions can be automatic. Approval should be reserved for material, sensitive, ambiguous, or irreversible effects, with policy deciding which class an action belongs to."
        },
        {
          "question": "Where should policy enforcement happen in an MCP system?",
          "answer": "At or immediately before the boundary that can cause the real effect. A policy decision in the prompt is insufficient if the MCP tool or downstream API can still execute a broader action."
        },
        {
          "question": "What evidence should a governed agent retain?",
          "answer": "At minimum: workload identity, declared purpose, policy version and inputs, decision, approval if any, exact tool request, redacted response or receipt, state transition, and recovery or reconciliation outcome."
        }
      ]
    },
    {
      "slug": "production-agent-reliability",
      "title": "Production AI Agent Reliability: State, Side Effects, and Recovery",
      "directAnswer": "A production AI agent should be designed as a long-running distributed system, not as a chat loop. Its state must be explicit and durable; external effects must be idempotent or reconciled; retries must know whether an earlier attempt succeeded; model and tool changes must be observable; and the system must know when to stop for a person. Reliability is the ability to explain and recover the work, not merely to keep the process running.",
      "audience": "Agent engineers, platform teams, SREs, architects, and technical leaders moving AI workflows from prototype to production.",
      "url": "https://www.dipankar.org/research/production-agent-reliability/",
      "evidence": [
        {
          "label": "fast-langgraph",
          "status": "Public open-source system",
          "text": "Durable agent state and checkpointing with project-published benchmarks of up to 700× faster checkpoint operations and 10–50× faster state management. These are operation-level results, not total application speed.",
          "href": "https://github.com/neul-labs/fast-langgraph"
        },
        {
          "label": "Azure and Kubernetes",
          "status": "Delivery experience",
          "text": "Recent work includes agentic AI services using Azure AI Foundry and AKS/Kubernetes, plus custom sandboxing and MCP in .NET."
        },
        {
          "label": "AWS document workflows",
          "status": "Delivery experience",
          "text": "Earlier systems handled extraction, classification, validation, routing, and LLM integration with CRM and operational workflows."
        }
      ],
      "limitations": [
        "A checkpoint does not by itself provide exactly-once external effects.",
        "The fast-langgraph benchmark figures describe measured checkpoint and state-management operations, not an end-to-end application speedup.",
        "No customer identity, confidential architecture, deployment scale, or certification is implied by the delivery summary."
      ],
      "faqs": [
        {
          "question": "Why do AI agents duplicate side effects?",
          "answer": "A process can fail after the external system accepted a request but before local state recorded success. A blind retry then repeats the effect. Idempotency keys, durable receipts, and reconciliation close that crash window."
        },
        {
          "question": "What should an AI agent checkpoint contain?",
          "answer": "Enough state to resume deterministically: goal, inputs, workflow position, model and prompt versions, tool requests and receipts, policy decisions, approvals, budgets, and outstanding reconciliation work."
        },
        {
          "question": "Is agent observability the same as logging prompts?",
          "answer": "No. Operational observability must connect decisions to state transitions, tool effects, policy, latency, cost, retries, quality evaluations, and the accountable operator action."
        },
        {
          "question": "When should an AI agent stop for a human?",
          "answer": "When authority is missing, ambiguity is material, evidence conflicts, budgets or retry limits are exceeded, an irreversible effect is proposed, or recovery cannot establish the external state safely."
        }
      ]
    },
    {
      "slug": "ai-generated-code-correctness",
      "title": "AI-Generated Code Correctness: Test the Semantics, Not the Vibe",
      "directAnswer": "Compilation and benchmark speed do not establish that AI-generated code is correct. For numerical kernels, the test oracle must understand the operator’s semantics, generate inputs that expose the likely defect, compare against a trustworthy reference with appropriate tolerances, and preserve a reproducible failure. The evaluator must also be tested against known-correct controls so stronger test inputs do not merely create false positives.",
      "audience": "ML systems engineers, GPU programmers, code-generation researchers, evaluation teams, and engineering leaders adopting coding agents.",
      "url": "https://www.dipankar.org/research/ai-generated-code-correctness/",
      "evidence": [
        {
          "label": "The Correctness Illusion in LLM-Generated GPU Kernels",
          "status": "2026 arXiv preprint",
          "text": "In the measured corpus, the seeded oracle detected 10/10 injected LLM-style transcription defects, 16/16 correct controls stayed clean, and verdicts matched across five GPU classes.",
          "href": "https://arxiv.org/abs/2606.20128"
        },
        {
          "label": "Test-Input Generation for Tensor Programs",
          "status": "2026 arXiv preprint",
          "text": "Seven strategies were evaluated on a 26-operator corpus. Boundary-only sampling achieved 78% recall with 0% false positives on 16 controls, while more adversarial values increased both recall and false positives.",
          "href": "https://arxiv.org/abs/2606.27396"
        },
        {
          "label": "gpuemu",
          "status": "Public open-source system",
          "text": "Operator-aware correctness tooling and the executable basis for the measured studies.",
          "href": "https://github.com/Skelf-Research/gpuemu"
        }
      ],
      "limitations": [
        "The measured corpus does not estimate the defect rate of any deployed language model or coding product.",
        "Both GPU-kernel studies are 2026 arXiv preprints; no peer-reviewed venue is recorded for them.",
        "Passing a finite test suite does not prove a generated kernel correct for every possible input or platform."
      ],
      "faqs": [
        {
          "question": "Why can an incorrect GPU kernel still look fast?",
          "answer": "A benchmark measures how quickly the implementation runs, not whether it computes the intended function. Skipped work, incorrect indexing, or unstable approximations can make a wrong kernel appear faster."
        },
        {
          "question": "What is an operator-aware test oracle?",
          "answer": "It is an evaluator that uses the mathematical and shape semantics of the particular operator to generate inputs, choose invariants and references, and interpret numerical tolerances."
        },
        {
          "question": "Why are random inputs insufficient for tensor-program testing?",
          "answer": "Ordinary random values rarely exercise ties, cancellation, extreme scales, boundary indices, non-contiguous memory, or degenerate dimensions where transcription and optimisation bugs tend to surface."
        },
        {
          "question": "Does 10/10 defects caught prove all generated kernels are safe?",
          "answer": "No. It establishes performance on a specific seeded corpus. It does not estimate real-world prevalence or prove complete detection."
        }
      ]
    },
    {
      "slug": "multi-agent-software-engineering",
      "title": "Multi-Agent Software Engineering Before the Pull Request",
      "directAnswer": "Pull requests reveal the final code but hide much of the cost of concurrent coding agents: repeated discovery, duplicate implementation, conflicting edits, abandoned branches, lock starvation, and races to declare completion. A useful multi-agent engineering system records task claims and append-only coordination events before the pull request, allows replicas to reconcile deterministically, and measures useful throughput rather than raw agent activity.",
      "audience": "Developer-tool teams, engineering leaders, coding-agent builders, distributed-systems practitioners, and researchers studying AI-assisted software delivery.",
      "url": "https://www.dipankar.org/research/multi-agent-software-engineering/",
      "evidence": [
        {
          "label": "Before the Pull Request",
          "status": "2026 arXiv preprint",
          "text": "In the measured setup, duplicate or conflicting rework fell from 78% to 0%, useful throughput more than tripled, and the append-only log converged without silently dropped writes.",
          "href": "https://arxiv.org/abs/2606.19616"
        },
        {
          "label": "grite",
          "status": "Public open-source system",
          "text": "A git-native coordination implementation accompanying the paper and released corpus.",
          "href": "https://github.com/neul-labs/grite"
        },
        {
          "label": "grite corpus",
          "status": "Public research corpus",
          "text": "The released artefacts support inspection of coordination traces and the measured setup.",
          "href": "https://github.com/sarkar-dipankar/grite-corpus"
        }
      ],
      "limitations": [
        "The controlled results do not establish that every coding team or agent framework will achieve the same improvement.",
        "Coordination overhead can exceed its value for very small, independent, or short-lived tasks.",
        "A convergent event log does not make the underlying code correct; testing and review remain separate obligations."
      ],
      "faqs": [
        {
          "question": "Why are pull requests insufficient for observing coding-agent work?",
          "answer": "They capture proposed code after substantial work has happened. They usually omit repeated discovery, abandoned attempts, duplicate task ownership, and coordination messages that explain why the work became expensive."
        },
        {
          "question": "What is a task claim in multi-agent coding?",
          "answer": "A task claim is an explicit, time-bounded coordination event stating that an agent intends to work on a defined scope. It reduces accidental duplication without requiring a permanent central lock."
        },
        {
          "question": "What should multi-agent engineering teams measure?",
          "answer": "Useful completed work, duplicate and conflicting effort, claim wait time, reconciliation cost, abandoned work, human interventions, and whether every valid coordination event survives convergence."
        },
        {
          "question": "Does more agent activity mean more engineering throughput?",
          "answer": "No. Parallel activity can increase duplication and conflict. Throughput should count useful, integrated work after subtracting the effort needed to resolve overlap and errors."
        }
      ]
    },
    {
      "slug": "local-inference-systems",
      "title": "Local and Embedded AI Inference Across Language Boundaries",
      "directAnswer": "Local inference is valuable when privacy, latency, offline operation, data gravity, predictable control, or integration with an existing runtime matters more than the convenience and frontier capability of a hosted API. The design problem includes model format, quantisation, memory and KV-cache behaviour, hardware backend, language binding, batching, observability, and update strategy. Removing an HTTP boundary can simplify one risk while moving model lifecycle and resource ownership into the application.",
      "audience": "AI platform teams, edge and mobile engineers, .NET and systems developers, privacy-sensitive organisations, and architects choosing between hosted and local models.",
      "url": "https://www.dipankar.org/research/local-inference-systems/",
      "evidence": [
        {
          "label": "Cognisoc",
          "status": "Public open-source portfolio",
          "text": "Polyglot local and server inference work across Python, Rust, C/C++, Node.js, Go, .NET, Dart, and Zig, with OpenAI- and Anthropic-compatible interfaces and in-process execution.",
          "href": "https://github.com/cognisoc"
        },
        {
          "label": "mullama",
          "status": "Public open-source system",
          "text": "Local and distributed inference with multiple hardware backends, resource limits, eviction, metrics, RAG, and Kubernetes recipes.",
          "href": "https://github.com/cognisoc/mullama"
        },
        {
          "label": "unillm",
          "status": "Public open-source system",
          "text": "A CPU, CUDA, and Metal inference runtime supporting multiple model-loading formats, hybrid KV cache, and continuous batching.",
          "href": "https://github.com/cognisoc/unillm"
        }
      ],
      "limitations": [
        "Local inference can increase cost or latency when hardware, model size, batching, or operational overhead are a poor fit.",
        "Model, architecture, device, and language support must be verified against each project’s current compatibility record.",
        "The Cognisoc portfolio has no published universal performance multiplier and is not a complete replacement for cloud inference."
      ],
      "faqs": [
        {
          "question": "When should an organisation run an AI model locally?",
          "answer": "When privacy, offline availability, data locality, predictable control, device integration, or a measured latency requirement outweighs the operational simplicity and capability of a hosted model API."
        },
        {
          "question": "Does local inference guarantee privacy?",
          "answer": "No. It removes one external data boundary, but prompts, caches, logs, model files, telemetry, backups, and surrounding applications still need a privacy and security design."
        },
        {
          "question": "What is in-process LLM inference?",
          "answer": "The application loads and invokes the model through a native or foreign-function interface in the same process rather than sending requests to a separate HTTP service."
        },
        {
          "question": "What should teams benchmark before choosing local inference?",
          "answer": "Task quality, time to first token, throughput under realistic concurrency, memory use, energy or device impact, model-load time, failure recovery, and operational effort on the actual target hardware."
        }
      ]
    },
    {
      "slug": "physical-ai-and-robotics",
      "title": "Physical AI and Robotics: From Language Plan to Safe Edge Execution",
      "directAnswer": "A language model should not be treated as the robot controller. In an operable physical-AI system, the model proposes a plan using declared capabilities and constraints; deterministic software validates and translates it; a person or policy approves material actions; the edge system executes within established control and safety boundaries; and telemetry supports recovery when the physical world disagrees with the plan. Learning is useful where it improves a measurable decision, not where deterministic control is required.",
      "audience": "Robotics, warehouse and logistics operators, manufacturing leaders, industrial-AI teams, edge engineers, and applied-ML researchers.",
      "url": "https://www.dipankar.org/research/physical-ai-and-robotics/",
      "evidence": [
        {
          "label": "RobotGPT",
          "status": "Delivery experience",
          "text": "At Orangewood Labs, Dipankar built a language interface for collaborative-robot task planning that reduced programming time by approximately 10× in that specific context, alongside computer-vision and cloud-to-edge systems."
        },
        {
          "label": "WareMax",
          "status": "Public research benchmark",
          "text": "A deterministic warehouse-robotics environment for SMDP task allocation, reward design, causal delay attribution, heuristic comparisons, multi-seed evaluation, and byte-identical replay.",
          "href": "https://github.com/Skelf-Research/waremax"
        },
        {
          "label": "Cloud-to-edge leadership",
          "status": "Delivery experience",
          "text": "Led machine-learning, backend, edge, and product engineering work around collaborative robotics."
        }
      ],
      "limitations": [
        "The approximately 10× RobotGPT result belongs to its specific collaborative-robot programming context and is not a universal robotics speedup.",
        "WareMax is a benchmark and simulation artefact, not evidence of a field deployment.",
        "No functional-safety certification is published. A language model should not directly control safety-critical motion."
      ],
      "faqs": [
        {
          "question": "Should an LLM directly control a robot?",
          "answer": "Not for deterministic or safety-critical control. A model can help interpret intent and propose plans, while validated software, policy, robot controllers, and safety systems retain execution authority."
        },
        {
          "question": "What is the role of an LLM in industrial robotics?",
          "answer": "Useful roles include intent interpretation, capability-aware planning, explanation, exception triage, documentation, and program drafting—provided plans are validated and constrained before execution."
        },
        {
          "question": "Why does deterministic replay matter in warehouse robotics research?",
          "answer": "It lets researchers reproduce delays and decisions exactly, compare policies against the same conditions, audit reward attribution, and distinguish algorithmic effects from simulation variation."
        },
        {
          "question": "What makes a physical-AI system operable?",
          "answer": "Explicit capabilities and constraints, inspectable plans, deterministic validation, clear approval and stop boundaries, edge ownership, physical telemetry, reconciliation, and a recovery runbook."
        }
      ]
    },
    {
      "slug": "agent-compatible-tools",
      "title": "Agent-Compatible Tools: Interfaces for Humans and AI Systems",
      "directAnswer": "A tool becomes agent-compatible when its capabilities and consequences are machine-readable without becoming less legible to people. It needs typed inputs, predictable structured output, stable error categories, runtime discovery, scoped credentials, redacted logs, rate-limit and retry metadata, dry-run or proposal modes, explicit approval before high-impact writes, and an audit record tied to the exact action. A pleasant human CLI is not automatically a safe agent interface.",
      "audience": "Developer-tool teams, platform engineers, API designers, MCP implementers, security engineers, and organisations exposing operational systems to agents.",
      "url": "https://www.dipankar.org/research/agent-compatible-tools/",
      "evidence": [
        {
          "label": "hubspot-cli",
          "status": "Public reference implementation",
          "text": "A Rust CRM CLI with structured JSON, stable error and exit semantics, discovery, dry-run, profiles, MCP, and stated secret-handling controls. The repository has no published adoption record or security audit.",
          "href": "https://github.com/dipankar/hubspot-cli"
        },
        {
          "label": "apollo-io-cli",
          "status": "Public reference implementation",
          "text": "A Rust interface exposing human subcommands and JSON-in/JSON-out operations across a large API surface.",
          "href": "https://github.com/dipankar/apollo-io-cli"
        },
        {
          "label": "dial-coder",
          "status": "Public reference implementation",
          "text": "A coding-agent design with risk-selected modes, multiple review roles, approvals, destructive-operation blocking, and optional container execution.",
          "href": "https://github.com/dipankar/dial-coder"
        }
      ],
      "limitations": [
        "Repository design and README statements are not independent evidence of adoption or security effectiveness.",
        "Examples and demonstrations should use mocks or disposable sandbox accounts, never production CRM or customer credentials.",
        "MCP compatibility does not by itself make a tool safe; authority and side effects still require an application-specific control design."
      ],
      "faqs": [
        {
          "question": "What makes a CLI safe for AI agents?",
          "answer": "Typed inputs, predictable machine-readable output, stable failures, discovery, scoped credentials, redacted logs, dry-run, explicit approval for high-impact writes, idempotency, receipts, and auditability."
        },
        {
          "question": "Why are stable error codes important for agents?",
          "answer": "Without them, a model may treat missing permission, malformed input, rate limiting, and uncertain completion as interchangeable text and choose an unsafe retry or fallback."
        },
        {
          "question": "Is an MCP server automatically agent-safe?",
          "answer": "No. MCP standardises how capabilities are exposed, not whether their credentials are scoped, their effects are authorised, or their failures and audit records are operationally safe."
        },
        {
          "question": "How should a tool handle destructive actions?",
          "answer": "Classify them explicitly, show the exact proposed effect, require appropriate authority or human approval, use idempotency and receipts, and support reconciliation or compensation when possible."
        }
      ]
    },
    {
      "slug": "blockchain-agent-security",
      "title": "Blockchain and Agent Security: Control the Key, State, and Effect",
      "directAnswer": "Blockchain automation is an authority problem before it is a prediction or interface problem. Validator clients should not reach a signing key without a stateful allow-or-refuse policy. Cross-rollup actions need explicit commitments, deadlines, finality assumptions, refund paths, and idempotent relaying. Compiler tools must expose semantic gaps across account and state models. Market agents should default to research, proposal, or paper mode, with human approval and reconciliation before any live effect.",
      "audience": "Blockchain infrastructure teams, validator operators, protocol and compiler engineers, fintech architects, applied cryptographers, and agent-security practitioners.",
      "url": "https://www.dipankar.org/research/blockchain-agent-security/",
      "evidence": [
        {
          "label": "nklave",
          "status": "Public Rust reference system",
          "text": "A signing-policy boundary with Web3Signer-compatible paths, EIP-3076 interchange, Ethereum and CometBFT rule paths, explicit allow/refuse decisions, append-only records, and checkpoints.",
          "href": "https://github.com/cryptuon/nklave"
        },
        {
          "label": "Tesseract and commit-reveal",
          "status": "Public protocol references",
          "text": "Vyper, Rust, and Python artefacts for atomic multi-rollup actions, commitments, deadlines, refunds, and information timing.",
          "href": "https://github.com/cryptuon/tesseract"
        },
        {
          "label": "SolScript and supervised market agents",
          "status": "Public reference systems",
          "text": "Compiler experiments and paper/shadow-first agent interfaces for examining semantic translation and human authority boundaries.",
          "href": "https://github.com/cryptuon"
        }
      ],
      "limitations": [
        "The cited systems have no published external audit, mainnet deployment, production-scale record, or universal attack-prevention result.",
        "No investment performance, liquidity, customer deployment, or regulatory approval is recorded. The material is not financial advice.",
        "Demonstrations should use local chains, testnets, mock assets, paper mode, and disposable keys."
      ],
      "faqs": [
        {
          "question": "Why is key custody insufficient for validator security?",
          "answer": "A key can be well protected yet still sign conflicting or slashable messages requested by a faulty or compromised client. The boundary must also enforce stateful signing policy."
        },
        {
          "question": "What makes a cross-rollup action atomic?",
          "answer": "Every participating action either reaches the committed outcome under stated finality and timing assumptions or follows a safe timeout and refund path, with relaying and retries designed to be idempotent."
        },
        {
          "question": "Should an AI agent place blockchain or market transactions directly?",
          "answer": "Not by default. A safer architecture separates research and proposal from risk evaluation, human approval, execution, reconciliation, and shutdown, beginning in deterministic paper or shadow mode."
        },
        {
          "question": "Can Solidity be translated directly to Solana without semantic review?",
          "answer": "No. Syntax translation does not resolve the differences in accounts, persistent state, authority, program-derived addresses, errors, events, and runtime behaviour. Generated output needs an explicit semantic and security review."
        }
      ]
    }
  ],
  "claimPolicy": {
    "summary": "Keep every quantitative or status claim attached to its exact context, source, and limitation.",
    "archiveBoundary": "Historical writing is a dated archive and is not automatically evidence for current claims.",
    "adoptionBoundary": "Public repositories and preprints do not by themselves establish adoption, certification, audit, or independent validation."
  },
  "discovery": {
    "llms": "https://www.dipankar.org/llms.txt",
    "llmsFull": "https://www.dipankar.org/llms-full.txt",
    "sitemap": "https://www.dipankar.org/sitemap-index.xml"
  }
}