

Peraton Labs
Developed a first of its kind reinforcement learning agent for IoT malware detection in PyTorch, granting it low level network traversal actions and full state observability to search device environments a brute force scan cannot cover, cutting exploration latency 35% and raising detection coverage 25% across 500K+ daily device events.
- Engineered the agent's feature set from binary signatures, file paths, filenames, and static analysis output, improving malware classification over single signal baselines, delivered inside a classified defense research environment.
- Built large scale ETL pipelines and a heterogeneous graph architecture with graph neural networks and autoencoders to model device to device communication patterns, accelerating policy convergence 40%.
The control question
During the summer, I began work on a new kind of malware detection program. Our program was a first of its kind reinforcement learning agent to intelligently navigate complex IoT device environments. A question came up time and time again: how much control should our agent have? Most technical AI applications deal with very high level functions. The more actions and control you give an agent, the more often it will mess up, but it will also be able to carry out far more tasks than with a small set of high level operations. A simple analogy is the difference between a rigid customer service tree and an LLM chatbot: one is perfect for limited applications, while the other is great for customized requests. For our agent, we wanted it to have access to almost everything. We wanted it to be able to traverse an IoT network with full knowledge of the surrounding state and complete control over what it's able to do. It made learning harder, but that low level control is truly what enables an agent to be effective and flexible.
Implications for robotics
This decision about control in an AI system feels increasingly central to robotics. Most robotics systems today rely on precise, pre programmed sequences or high level planners that assume the world will cooperate. But as robots move into unstructured environments like homes, disaster zones, and dynamic factories, we need agents that can operate at a much more granular level. That means giving up some predictability. It means building systems that learn to control rather than just follow control scripts. And it means accepting that real world intelligence will never be nearly as clean as the text oriented LLM world we're exploring today. The future of agents lies in control.
On unflashy work
The ML work that goes into cybersecurity is so detail oriented and gritty. It's not flashy. There's no cool results that are easy to view, like bounding boxes or generated text. It's an abstract model exploring an abstract space using abstract actions. It's definitely frustrating to not have easily visible output. Especially in the scenario in which I worked, a defense research contract in a classified work environment, there was no product, no public information, and nothing I can show to the world. However, the work is undoubtedly important, and the best work is invisible. That's a broader belief. The most important work that keeps our world's systems running is completely invisible, and massive organizations have critical dependencies on these gritty, high importance problems that need solving.
Why RL for IoT malware
RL approaches to malware detection don't cover the same use case. On a single device, traditional malware detection works reasonably well. But on an IoT network, where devices connect and dynamically transmit malicious data and lie dormant across devices, we can't feasibly explore everything. Thus, it falls upon a well trained agent to explore the space well enough to detect the malware present. "Well enough" is just an improving metric based on what we can already do. It just needs to beat a baseline brute force search at pure speed and discovery of malware, and based on those metrics, we did achieve results.
For startups and founding teams
Karthik Thyagarajan is a founder-engineer studying Computer Science and Artificial Intelligence at Purdue. At Samsung Research America, he co-architected an always-on AI agent runtime for XR glasses. He is currently building Tavi, a voice teammate for engineering standups, and co-founded buildpurdue, a founder community at Purdue. His work spans agent infrastructure, on-device AI, product engineering, and evaluation.
For an early team building AI products, his strongest demonstrated fit is owning a broad technical problem from product decisions through implementation and evaluation. His current interests are live voice and video AI, AI-first wearables, and infrastructure that lets agents discover and use internet services.
Substantial ownership of agent systems
At Samsung Research America (May to August 2026), he co-architected an always-on agent orchestrator in Kotlin and owned half of a 25+ module runtime. His reported on-device router achieved 95% signal suppression and 90% intent-routing accuracy. His work also covered tool permissions, model routing, memory, and phone control, connecting model behavior to a usable device experience.
Builds teams and operating systems around a problem
As buildpurdue's co-founder and co-president, he helped turn an informal gathering into a founder community with a selective cohort, weekly co-working, funding, and founder-led problem-solving workshops. He built much of its web platform and integrated CRM, applications, events, and check-ins. His account describes data on around 500 students and a mailing list of about 1,000.
Makes technical claims testable
He built PARM, an open-source causal benchmark for when an agent should use personal memory: 157 frozen scenarios and 471 executable cases, with deterministic scoring and versioned replay artifacts. Its portfolio account explicitly distinguishes development results from held-out claims. He also built google-tools-mcp, a published MCP server exposing 169 Google Workspace tools through one OAuth flow.
Pursues difficult product problems
He is currently building Tavi, a voice teammate intended to answer codebase questions and handle small action items during engineering standups. The project tackles multi-person turn-taking, when to stay quiet, sandboxed coding, and synthetic meeting evaluations. This is ongoing work, rather than a claim of shipped adoption. His published interests explain the direction behind it.
Co-founder who ships and thinks about distribution
At Repple (November 2025 to June 2026), he co-founded a competitive fitness app released on the App Store and built the entire FastAPI, PostgreSQL, and Supabase backend, including synchronized workouts, ELO matchmaking, and weekly competition logic. His firsthand account also describes marketing before the UI existed, campus distribution, and why local community density mattered to the product.
This brief summarizes Karthik's public portfolio and firsthand accounts. Employment contributions and internal performance metrics are self-reported; linked code and artifacts provide additional evidence where available.