# Jonas A. Menesklou

Jonas A. Menesklou writes about building automation for enterprise workflows and hard-to-test systems, including embedded software, factory equipment, and automotive interfaces.

- Profile: https://b2binfluencer.marketing/creators/jonas-a-menesklou/
- LinkedIn: https://www.linkedin.com/in/menesklou
- Topics: artificial-intelligence, agentic-ai, workflow-automation, industrial-automation
- Based on 12 dated posts, latest 2026-10-09

## Summary

They are most useful for explaining why enterprise automation and device testing are harder than browser automation.

- Best for: B2B enterprise automation or device-testing platforms seeking research or advisory collaboration.
- Not for: Consumer AI assistant, desktop-agent, or browser-first SaaS testing vendors seeking paid social promotion.
- Check first: Confirm whether they offer partnerships and provide audience analytics or survey results.

### Takeaways

- Embedded test benches may take two weeks to book and still need manual display checks.
- Enterprise agents should be judged against enterprise conditions, not a clean demo Mac.
- Buyers want process ownership, not another test automation, RPA, or work-instruction tool.

## Main ideas

- **The hardest automation problems are not on the web, and that is why no one built tools for them**: The recurring priority in these posts is the gap between where automation funding goes and where the difficult work sits. Menesklou's reasoning is a market one: capital follows the SaaS market, so browser and mobile testing attract the startups, while embedded systems, factory floors, medical devices, and automotive cockpits go unserved because nobody in San Francisco needed to automate a Bosch infotainment panel or validate a Siemens HMI. That leaves German manufacturers and similar teams stuck between manual testing and fragile custom scripts — in their account, not for lack of talent but because the tooling was never built for their world.
- **Enterprise agents should be judged against enterprise conditions, not a clean demo Mac**: Menesklou treats the arrival of desktop-controlling AI agents as a real shift — the biggest labs now agree the frontier is doing, not just thinking — and argues the demos are aimed at the wrong environment. They cite operating conditions they say are simply the default in automotive, manufacturing, and enterprise IT: latency, firmware variation across hardware, and networks that nothing may leave. Reliability under those conditions is the actual engineering problem, and it is where they say the need sits while attention stays on consumers.
- **Buyers want process ownership, not another point tool**: Menesklou's central commercial thesis comes from customer conversations rather than product analysis. After a month of calls across automotive Tier-1s, medical device manufacturers, financial software, industrial automation, and enterprise security, they report that none of the customers asked for better test automation, RPA, or work-instruction tools. Instead, customers described the same thing in different words: an agent that owns a process from the ticket that triggers it, through the screens, APIs, and databases it touches, to the artifact it produces, with humans showing up only to handle exceptions. Menesklou concludes that this is a different category, and that the label 'computer use agent' undersells it because the screen is only where the work happens to live.
- **Automation is not the asset — the knowledge behind it is**: One post reframes test infrastructure as transferred knowledge rather than code. The argument: when a key engineer leaves, months of release confidence go with them, the pipeline stays green, and the new owner inherits a suite nobody can fully read. Nobody knows which failures are real bugs, which are quietly rerun until they pass, or which edge cases were added after an incident nobody wrote down. Menesklou's deliberate reframe is that the automation did not fail — the knowledge never transferred — and that most teams store that knowledge in the worst possible place: people.
- **Solving the hardest environment first produces better tools everywhere else**: Menesklou's engineering argument is that once you build automation for a Citrix session or an embedded panel, a web app becomes the easy case, because the hard environments force a more fundamentally robust design. That reasoning ties the embedded focus to the rest of the writing: difficult constraints become a design advantage rather than a niche. Ask for shipped results, benchmarks, or outcomes from teams that have followed this approach.

## Work to read

- [Embedded test benches still end with someone watching the screen](https://www.linkedin.com/posts/menesklou_every-embedded-engineer-i-talk-to-has-the-activity-7443335092732694528-3EcW)
- [Customers describe workflow ownership, not a better automation tool](https://www.linkedin.com/posts/menesklou_spent-the-last-month-in-customer-calls-activity-7466171921009770496-MFpM)
- [Consumer AI agents on a clean Mac versus enterprise conditions](https://www.linkedin.com/posts/menesklou_anthropic-just-shipped-the-ability-for-claude-activity-7442967420731863042-Qwex)
- [Why automation tooling gets built for the web, not the factory floor](https://www.linkedin.com/posts/menesklou_most-vc-money-in-automation-goes-to-tools-activity-7437863263138254848-8rx1)
- [Test knowledge lives in one person’s head](https://www.linkedin.com/posts/menesklou_every-time-a-key-engineer-leaves-three-months-activity-7468691659401183232-duxF)

## Brand relationships

- **Anthropic** (mention)

## Partnerships

Jonas A. Menesklou has no documented partnership offering. Across five LinkedIn posts published between March and June 2026, they share first-person industry commentary on automation and testing: embedded benches, Citrix and cockpit environments, knowledge loss when engineers leave, and the shift from tools to end-to-end workflow ownership. The posts describe no sponsorship product, advertising placement, paid collaboration, rate card, media kit, partnership terms or inquiry route. For a B2B enterprise automation or testing platform, there is no published menu to buy from; propose a relationship directly. The strongest starting point appears to be a research or advisory conversation about workflow automation in industrial, automotive and medical-device environments—the subjects the posts repeatedly cover and the audience they appear to reach. Before proceeding, ask whether they accept sponsorships or paid work and request their terms, pricing and deliverables.

## Alternatives

- Muneeb Ur Rehman: Choose Muneeb Ur Rehman when the collaboration needs an implementation partner rather than a field perspective. Two posts describe a service in which Tech Monkeys builds and connects specialist agents into a repeatable workflow, with a defined starting scope and a split between build cost (workflow design, development, integrations, testing, deployment) and running cost (AI usage, hosting, connected services), plus usage tracking, spending limits and approval steps. A platform seeking a partner to stand up an agent factory for its own operations, or co-produce content on how one is assembled, gets hands-on build detail here. The example workflows are shaped around business processes: extending a web app into a mobile companion, turning documents and emails into reviewed CRM updates, researching a product change through specification and tested code, and generating reports from operational data.
- Zach Lloyd: Choose Zach Lloyd when the buyer needs a product or platform to run and govern agents, not just a voice to explain the problem. Two posts outline what a software-factory stack contains — factories-as-code, a context layer, compute, inference, improvement infrastructure, orchestration and access — and announce that Warp Factories now supports Microsoft Teams and Azure DevOps. They cover mentioning agents from work items and pull requests, giving each factory its own identity for Git and pull request operations, scoping repository access, and shipping pull requests back through Azure DevOps, with integrations and triggers defined in version-controlled configuration. A platform assessing a collaboration for an enterprise already running on Teams and Azure DevOps, or seeking content grounded in model choice, benchmarking and cost-per-PR measurement, gets a concrete implementation surface here. The posts also attach a free-usage offer to the product for eligible teams.
- Ricardo Camacho: Choose Ricardo Camacho when the collaboration concerns security verification in automotive and embedded systems rather than workflow automation ownership. Two posts cover software-defined vehicles — millions of lines of code, interconnected ECUs, OTA updates and ADAS — and the shift from reacting to vulnerabilities to engineering security across the whole lifecycle, naming ISO/SAE 21434 as the framework. The second post presents embedded security testing as three complementary techniques (static analysis, dynamic analysis and fuzz testing, penetration testing), alongside secure coding, CI/CD security gates and continuous validation. Both posts point to fuller material, a blog and a guide, and carry a vendor tag. For automotive, medical-device or industrial engineering teams seeking the security and compliance dimension of device work, this is closer to the subject.

---
AI-assisted summary of public posts. Audience demographics are not available. Engagement appears only where we checked recent posts. Method: https://b2binfluencer.marketing/methodology/