Tejas Bhakta is the founder and CEO of Morph, which builds specialized models and inference systems for coding agents. His work concentrates on the operations around an agent’s reasoning—finding relevant code, applying edits, generating tokens, and detecting failures—that determine whether it can complete useful work quickly and reliably.
From hardware experiments to AI infrastructure
Bhakta’s early projects included a solar-panel inverter and an off-road electric longboard with a motor controller and printed enclosure. His hardware projects involved building physical systems; his experiments with GPU mining in a dorm room brought him into the machinery of parallel computation. He later worked as a machine learning engineer at Tesla on inference optimization for Tesla AI.
At Tesla, he also helped build systems that searched driving data for useful training examples, including obscured cameras and unusual vehicle maneuvers. Finding rare failures required detectors inexpensive enough to examine large amounts of data. That problem recurs in his work on agent failures: an API call can succeed while the agent repeats a mistake or abandons its task. Detecting those failures requires examining behavior, not simply counting execution errors.
His entrepreneurial work included AutoInfra, a natural-language interface for managing AWS infrastructure through Slack. Users could inspect resources and logs, request changes, and approve proposed resolutions to alerts under user-controlled permissions. Morph joined Y Combinator’s Summer 2023 batch. By May 2025, Bhakta’s inference engineering work focused on speculative decoding, batching, and custom CUDA kernels: ways to reduce the time and computation required to serve coding models.
Giving specialized models specific jobs
Morph’s approach divides supporting tasks among specialized models. The division changes how much code the main agent must generate and how much intermediate material it must retain. Bhakta’s writing on coding-agent harnesses identifies a cumulative cost: unsuccessful searches, repeated file reads, and edit retries become additional context the agent must continue processing.
Fast Apply:Fast Apply merges an agent’s proposed changes into an existing file. The main model expresses the intended edit as a short code sketch, marking sections that should remain unchanged; a separate model performs the full-file merge. This separates deciding what to change from reproducing the surrounding code.
WarpGrep:WarpGrep searches code iteratively in a separate context window and returns relevant code to the calling agent. Failed searches and irrelevant files stay out of the main agent’s history. Bhakta co-authored its technical account with Dhruv Bhatia and Dat Quoc. The design gives retrieval room to explore without making the reasoning agent carry every intermediate step.
Coding-specific speculative decoding: Bhakta’s code-generation inference research describes small draft models trained on the coding output of the larger model they accompany. A draft model predicts several tokens, which the larger model checks together. Repeated code structures and copied file contents make coding a useful workload for this approach. Serving it efficiently also requires attention to kernels, caches, and communication between GPUs.
Performance measured across the whole system
Bhakta’s interest in lower-cost GPUs extends his hardware experimentation into Morph’s inference work. GPUs without NVLink can require custom kernels to perform well on the intended workload. His approach to automated GPU optimization gives humans responsibility for identifying the opportunity and agents responsibility for exploring implementation parameters. The engineer might recognize unnecessary data movement or an opportunity to pipeline an operation; automated experiments then search choices such as block and chunk sizes, retaining changes only when they remain correct and improve performance.
For Bhakta, end-to-end inference performance is the meaningful test. An agent can make an isolated kernel look faster by disabling CUDA graphs while slowing the complete model, or produce a kernel that wins only over a narrow range of context lengths. These limits connect his GPU work to his agent-harness designs: an improvement must survive the conditions of the system that uses it. Automated tuning therefore needs accurate hardware and model context, realistic workloads, and permission to reject apparently promising changes. He reports a combined threefold speedup from his team’s kernel and hardware optimizations, while estimating that roughly 80% of autoresearch attempts are unsuccessful.
Making failures visible at scale
Morph’s monitoring work applies the same concern with computation cost to agent behavior. Its Reflexes classifiers detect behaviors such as looping, jailbreak attempts, and user frustration. Bhakta’s shared-backbone inference design uses a custom SGLang backend to encode a conversation once and let multiple small classification heads reuse the transformer’s activations. Multiple detectors can examine the conversation without each repeating the full computation.
His approach to agent failure detection connects that economical monitoring with improvement. Flagged behavior can direct heavier analysis and human attention to troublesome turns, then become evaluation cases, training examples, or reinforcement-learning signals. It carries forward a problem he encountered in driving-data selection: making detection affordable enough to find the unusual cases that deserve closer examination.
Tejas Bhakta of Morph explains how human optimization ideas, agent-tuned GPU kernels, and bare-metal changes combine—and why a faster kernel can still make inference slower.
Autoresearch makes kernel tuning a repeated propose, check, benchmark, and keep-or-revert loop. Humans still supply the larger optimization idea.
Give the agent both target-hardware information and the model’s actual operations; otherwise it can search an implementation that the hardware cannot support or the model cannot use.
Judge improvements in their inference workload. Disabling CUDA graphs or testing only short contexts can make a local kernel win misleading, and a useful kernel may need a limited operating range.