Ajay Prakash

Ajay Prakash contributed to Contextual Agent Playbooks & Tools (CAPT), LinkedIn’s infrastructure for giving coding agents access to internal systems and the engineering knowledge needed to use them. His work addresses a practical limit of enterprise AI: an agent may know how to write code yet lack the company-specific frameworks, procedures, and context needed to complete a trustworthy change.

From Sales Navigator to AI agent platforms

Prakash’s professional profile records master’s study in computer science at the University of Texas at Dallas from 2011 to 2013, focused on machine learning and data science. His QCon biography describes earlier leadership of AI platform and product initiatives for LinkedIn Sales Navigator, followed by work leading its AI agent platform efforts. He was also credited as a LinkedIn software engineer in his recorded CAPT talk.

In Sales Navigator, Prakash and Lukasz Karolewski helped build collaborative prompt engineering playgrounds using Jupyter notebooks. The notebooks ran the same underlying chains used in production, with shared model configurations, prompt templates, and realistic test data. Sales experts could change prompts and inspect the resulting answers directly, while engineers maintained orchestration, infrastructure, and review. This supported features such as AccountIQ, which combines company information, external research, and language models to generate insights for sellers. The playgrounds gave people who understood customers’ questions a direct role in improving model behavior.

Giving coding agents LinkedIn’s organizational context

Beginning in early 2025, Prakash and his colleagues addressed a related problem in software development. Coding agents struggled with LinkedIn’s internal frameworks, experimentation systems, data platforms, and operational practices. Engineers had to supply missing context manually, sometimes spending more effort guiding an agent than doing the work themselves. The team first exposed internal code search through the Model Context Protocol (MCP), then added access to documentation, Jira, Slack, data platforms, and feature flags. Agents could find examples and answer questions, but completing a workflow still required knowledge scattered across documents and conversations, some outdated or contradictory.

CAPT paired tool access with task-specific playbooks: instructions that an agent retrieves through MCP much as it would invoke a tool. Prakash co-authored the CAPT engineering account with Nikhilesh Payyavuala; teams across LinkedIn contributed to the system. A playbook for creating an Airflow DAG, for example, supplies the company’s procedure and directs the agent to the tools needed to carry it out. Experiment cleanup requires a different sequence: establish the winning variant, locate affected code, remove obsolete branches and flags, and validate the remaining behavior. Encoding those steps makes specialized engineering knowledge reusable.

Keeping playbooks focused and current

Prakash emphasizes small, self-contained playbooks that larger workflows can reference. This supports progressive context discovery: the agent fetches a smaller playbook when it needs that knowledge, rather than loading every instruction at the outset. His coding-agent infrastructure talk explains a similarly compact interface for the capability catalog. Three meta-tools let an agent search for relevant tools and playbooks, inspect their schemas, and execute them. This reduces the amount of tool information occupying the context window before useful work begins. Central playbooks cover workflows shared across repositories; repository-local playbooks supply instructions specific to the code being changed. A shared MCP server also handles authentication, telemetry, and distribution of updates.

Keeping those instructions useful requires a review loop. Prakash encourages agents to identify missing steps, discrepancies, and outdated guidance after a task, then propose playbook changes through pull requests. His incident-response example shows how the pieces fit together: an agent retrieves general debugging guidance, follows service-specific instructions, examines logs and metrics, identifies a cause, and proposes mitigation. It acts after confirmation, records incident details, and can prepare a code fix. Proposed updates to the playbooks preserve lessons for subsequent work. His stated standard is code that engineers can trust for correctness and quality; access to newer models and tools alone does not meet that standard.

Tools, interfaces, and harness engineering

• Agent-friendly CLIs: Prakash also explores interfaces beyond MCP. In his writing on agent-friendly command-line tools, he favors non-interactive commands, predictable argument names, structured output, pagination, and previews of mutations. He identifies Skills Manager as a CLI he built to store and install agent skills. His interface choice depends on the agent’s environment: terminal-equipped agents can compose CLI commands, while assistants without shell access may need MCP over HTTP.
• Agent-powered IDEs: He contributes to Stratos, an open-source framework for agent-powered IDEs whose contributors also include Payyavuala. Its desktop interface makes agent threads, tool activity, file changes, and diffs visible across multiple coding-agent providers. In his writing on harness engineering, Prakash describes using Stratos for work in separate worktrees, visual verification of running interfaces, persistent session observations, and iterative critique.

For Prakash, harness engineering encompasses the context, memory, tools, constraints, feedback, and checks surrounding a model. Passing tests can still leave architectural problems, so engineers must make their standards available to agents and build ways to detect and correct weak work. His public argument for that role connects improving a product with improving the agent infrastructure used to build it: teammates can turn well-defined intent into reviewable changes, while engineers retain judgment over consequential architectural and security decisions.