Jonas A. Menesklou writes about building automation for enterprise workflows and hard-to-test systems, including embedded software, factory equipment, and automotive interfaces.
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.
Key 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.
Check first: Confirm whether they offer partnerships and provide audience analytics or survey results.
Main ideas
The hardest automation problems are not on the web, and that is why no one built tools for them · Enterprise agents should be judged against enterprise conditions, not a clean demo Mac · Buyers want process ownership, not another point tool
Menesklou writes about automation in places where standard web tools fall short: embedded systems, factory equipment, automotive interfaces, and complex enterprise workflows.
In five LinkedIn posts, they explain why testing real hardware still relies on people watching screens, why automation must withstand slow or changing interfaces, and why teams lose release knowledge when experienced engineers leave.
Their work is useful to readers interested in the practical limits of enterprise automation and the shift from selling separate tools to owning a workflow end to end.
Menesklou makes difficult automation problems concrete by contrasting familiar software workflows with conditions in manufacturing and other enterprise settings.
For example, they set a test environment that a software engineer can start in 30 seconds against an embedded test bench that may take two weeks to book and still requires someone to verify the display by hand.
They also name the engineering demands behind enterprise computer use: latency, interface changes between firmware versions, hardware variation, and air-gapped networks.
Another strand of their work focuses on what happens after deployment: when a key engineer leaves, a green test pipeline may conceal failures and decisions that were never documented.
These examples make their writing especially relevant to readers trying to understand why automation for real-world systems is harder than automating a browser, and why process reliability depends on preserving the knowledge behind the tests.
Their posts also resist a simple “more tools” answer: after customer calls, they describe buyers asking for agents that carry work from its trigger through screens, APIs, and databases to a finished artifact.
Buyers should ask for evidence behind these customer-research claims.
Menesklou writes about automation for systems that were never built to be automated — embedded panels, factory HMIs, automotive cockpits, Citrix sessions, point-of-sale terminals.
The through-line in the posts is a market argument: automation investment follows the SaaS market into web and mobile tooling, while the hardest problems sit on test benches and factory floors where no browser, DOM, or cloud sandbox exists.
They build a buyer-side argument on top of that: companies are not asking for better testing, RPA, or work-instruction tools but for an agent that owns a process end to end, with people handling only exceptions.
Two further priorities run through the writing — that the knowledge behind a test suite matters more than the suite itself, and that building for the hardest environments first produces more robust tooling for everything else.
Ask for published measurements supporting these claims.
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.
Read more
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.
A post sets the scale concretely: an accelerator batch produces another browser testing startup, while thousands of German companies run mission-critical software with no browser, no DOM, and no standard framework. Bosch and Siemens appear as example environments, not as clients.
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.
Read more
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.
A post responding to Claude being able to control a Mac from a phone contrasts a clean Mac with Slack and a calendar against a Citrix session with three-second latency, a QNX cockpit, an HMI panel deployed before anyone talked about AI agents, and a POS terminal in 25 countries on different firmware. The named hard requirements are reliability when the screen takes seconds to load, self-healing when a UI changes between firmware versions, one test across 50 hardware variants without rewriting it, and air-gapped operation.
Buyers want process ownership, not another point tool
Menesklou's central commercial thesis comes from customer conversations rather than product analysis.
Read more
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.
The call list is given by industry, not by name: automotive Tier-1s, medical device manufacturers, financial software, industrial automation, enterprise security. Ask for documentation of the customer conversations behind the claim.
Automation is not the asset — the knowledge behind it is
One post reframes test infrastructure as transferred knowledge rather than code.
Read more
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.
The image is the green pipeline whose suite is unknown to its new owner, a pattern Menesklou reports seeing weekly across automotive, manufacturing, and medical devices.
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.
Read more
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.
The same post that describes German manufacturers stuck without a browser, DOM, or standard framework closes on the claim that solving those environments first is how the more robust tool gets built.
Menesklou's posts consistently present this as a stable position rather than a change of view; the posts carry no dates, so it is a current stance.
This is the quickest way to understand Menesklou’s work: why software that runs on real hardware cannot be tested like a web app, and why that gap has lasted so long.
Read more
Menesklou describes a routine embedded engineer’s week: book the test bench, wait two weeks, sit in front of the screen, verify by hand.
Then they contrast it with a colleague at the same company who starts a test environment in 30 seconds by cloning a repository and launching a container.
The post credits automotive and manufacturing with serious simulation investment (SIL, HIL) but points out that the final visual check still has no automation, so someone has to watch the display.
The argument rests on that single contrast, not on product claims.
For brands planning a campaign
Concrete evidence of domain fluency for anyone evaluating Menesklou on embedded, hardware-in-the-loop or device-testing topics. The “last step is still done by hand” framing offers a usable hook for a research brief, webinar or advisory conversation with teams selling into hardware-dependent engineering groups.
Menesklou states their central commercial thesis in their own words: what enterprise buyers say they want, and why they see it as a category shift rather than a tool request.
Read more
After a month of customer calls across automotive Tier-1s, medical device manufacturers, financial software, industrial automation and enterprise security, Menesklou reports that none asked for a better test automation, RPA or work-instruction tool.
Instead, each described an agent that owns a workflow end to end — from the ticket that triggers it, through the screens, APIs and databases it touches, to the artifact it produces — with people stepping in only for exceptions.
They conclude that “computer use agent” undersells what is happening, because the screen is only where the work happens to live.
The customers are described by industry, not named.
For brands planning a campaign
The strongest passage for positioning a platform as end-to-end ownership of workflows rather than another point tool.
A category-definition piece, roundtable or research interview built on this framing would match Menesklou’s public arguments.
Treat the unnamed customer list as illustration, not as documented references.
This shows how Menesklou responds to the current agent wave and what they consider the hard part vendors keep skipping.
Read more
Responding to Anthropic giving Claude the ability to control a Mac from a phone, Menesklou agrees that the next frontier is doing, not just thinking.
They describe enterprise conditions instead: a Citrix session with three-second latency, a digital cockpit running on QNX, an HMI panel on a factory floor deployed before anyone talked about AI agents, and a point-of-sale terminal in 25 countries running different firmware on different hardware.
The challenges they name are reliability when a screen takes seconds to load, self-healing when the interface changes between firmware versions, running one test across 50 hardware variants without rewriting it, and operating air-gapped.
They close on the gap between where attention sits (consumer) and where the need sits (enterprise).
For brands planning a campaign
A timely, quotable frame for vendors whose differentiation is robustness in slow, locked-down or hardware-bound environments. It also serves as a filter: a campaign built on consumer-side agent hype would not match the audience Menesklou writes for.
This explains the market gap behind Menesklou’s case and why it has persisted despite obvious demand.
Read more
Menesklou observes that most venture money in automation funds tools for web and mobile apps, because that is where the SaaS market is, and that every startup batch has another browser-testing company.
In their account, the hardest automation problems are in automotive cockpits, factory floors, medical devices and embedded systems with custom interfaces no outsider has seen.
The post says tools are missing because nobody in San Francisco needed to automate a Bosch infotainment panel or validate a Siemens HMI.
Menesklou points to thousands of German companies running mission-critical software with no browser, no DOM and no standard framework, and argues that solving a Citrix session or embedded panel makes the web the easy case.
Bosch and Siemens appear as example environments, not as clients.
For brands planning a campaign
Useful for a European enterprise-software or industrial-automation vendor whose buyers are manufacturers: the post offers a “hardest problems first” narrative and a geographic angle. Ask for details before treating it as evidence of access to particular accounts; it names no employers, customers or funding relationships.
This goes beyond tooling to ask what happens to a test suite when the person who understood it leaves.
Read more
It is Menesklou’s clearest example of reasoning from observable patterns rather than product features.
Menesklou argues that when a key engineer leaves, three months of release confidence goes with them: the pipeline stays green, but nobody knows which failures are real bugs, which ones everyone quietly reruns until they pass, or which edge cases were added after an undocumented production incident.
The new person inherits a system they cannot fully read.
Menesklou reports seeing this weekly across automotive, manufacturing and medical devices.
Their conclusion: the automation is not the asset — the knowledge behind it is — and most teams store that knowledge in people.
For brands planning a campaign
Opens a services and advisory angle beyond tool sales: test-suite audits, documentation and knowledge transfer. The “green pipeline, unknown suite” image is concrete enough for a research brief or a workshop aimed at engineering leaders rather than tool buyers.
Approach: short argumentative posts built on a reframe5
Automating interfaces that were never built for automation3
End-to-end workflow ownership instead of more point tools2
Consumer agent demos versus enterprise operating conditions2
Test infrastructure as transferred knowledge, not just code1
Where automation funding goes versus where the hard problems live1
Automating interfaces that were never built for automation
The recurring subject is software with no DOM, selectors, or cloud sandbox: embedded panels, QNX digital cockpits, factory HMIs, Citrix sessions, and point-of-sale terminals running different firmware in different countries.
Read more
Jonas A.
Menesklou describes the current alternative in plain terms — book the bench, wait two weeks, watch the screen by hand — and notes that automotive and manufacturing already invest heavily in SIL and HIL simulation, yet final visual verification remains manual.
The argument: solve a Citrix session or an embedded panel, and a web app becomes the easy case, because hard environments demand more robust engineering.
Frames the gap through comparison: a software engineer clones a repo and spins up a container in 30 seconds, while an embedded engineer at the same company books physical hardware and verifies it visually.
For brands planning a campaign
This is the sharpest positioning hook for a testing, RPA, or device-automation vendor targeting embedded, industrial, or regulated customers. A campaign can use the “bench and stopwatch” image directly and should expect the audience to care more about hardware variants, latency, and air-gapped operation than browser coverage.
End-to-end workflow ownership instead of more point tools
After a month of customer calls with automotive Tier-1s, medical device manufacturers, financial software, industrial automation, and enterprise security teams, the posts say none asked for a better test automation, RPA, or work-instruction tool.
Read more
They all described the same thing in different words: an agent that owns a workflow from the triggering ticket, through the screens, APIs, and databases it touches, to the artifact it produces, with humans handling only exceptions. The posts conclude that this is a different category, not a tool request, and that the label “computer use agent” undersells it because the screen is only where the work happens to live.
For brands planning a campaign
A platform that already sells end-to-end agentic automation can use this as supporting argument from a practitioner who talks to buyers. A single-point tool vendor should expect the framing to work against them and may need a different angle — for example, positioning as the reliable component inside a workflow someone else owns.
Test infrastructure as transferred knowledge, not just code
One post explores what happens when a key engineer leaves: three months of release confidence go with them, the pipeline stays green, and the new owner inherits a suite they cannot fully read.
Read more
Nobody knows why half the tests exist, which failures are real bugs, which are quietly rerun until they pass, or which edge cases were added after a production incident that was never written down.
The reframe is deliberate: “The automation did not fail.
The knowledge never transferred.”
The pattern is reported as consistent across automotive, manufacturing, and medical devices.
For brands planning a campaign
Useful for vendors selling test observability, flakiness detection, documentation of test intent, or knowledge capture around CI pipelines. The post offers a ready-made buyer pain — onboarding cost and inherited suites — that a campaign can address without first introducing the problem.
Consumer agent demos versus enterprise operating conditions
The response to a major vendor shipping desktop control for an AI assistant is not dismissal but gap analysis.
Read more
The demo works on a clean Mac with Slack and a calendar; the described enterprise reality is a Citrix session with three-second latency, a cockpit running QNX, an HMI panel deployed before anyone talked about AI agents, and a POS terminal in 25 countries on different hardware and firmware. The named requirements are reliability when the screen takes seconds to load, self-healing when a UI changes between firmware versions, running one test across 50 hardware variants without rewriting it, and operating in air-gapped environments where nothing leaves the network.
For brands planning a campaign
Every consumer agent launch creates a fresh news peg for reactive commentary, quotes, and co-authored posts. Vendors selling reliability, self-healing selectors, or air-gapped deployment can offer those capabilities as answers to the conditions Menesklou names; consumer-assistant vendors should expect comparison.
Where automation funding goes versus where the hard problems live
One post argues that most automation investment follows the SaaS market into web and mobile tooling — another browser testing startup in every accelerator batch — while the hardest problems sit in automotive cockpits, factory floors, medical devices, and custom embedded UIs that outsiders never see.
Read more
The European angle is explicit: Germany has thousands of companies running mission-critical software on systems with no browser, no DOM, and no standard framework, stuck between manual testing and fragile custom scripts not for lack of talent but because the tooling was never built for their world. The closing claim is that solving the hardest environments first produces fundamentally more robust tools.
For brands planning a campaign
Strong fit for a European industrial or DACH-focused vendor, or any automation company wanting to argue that it builds for manufacturing rather than the browser. The line “tools get built where the funding is, problems live where the manufacturing is” works in thought leadership, at events, or on podcasts.
Approach: short argumentative posts built on a reframe
The writing is compact and structured around a turn.
Read more
A post opens with a concrete scene or claim — a bench, a departure, a month of calls, a product launch — stacks short, one-line paragraphs of contrast, then lands a reframe such as “The automation is not the asset.
The knowledge behind it is” or “The screen is just where it happens to live.”
The posts foreground field observation rather than data: “Every embedded engineer I talk to,” “I see this every week,” “Spent the last month in customer calls.”
The corpus contains no technical deep dives, no case studies, and no follow-up data on whether the described approaches worked in production, so claims about outcomes should not be treated as validated.
For brands planning a campaign
Commission formats that leave room for a short, opinionated turn: a co-authored post, a quote, or an interview where they can walk through what customers told them.
Long tutorials, benchmark write-ups, and product walkthroughs would run against the grain.
Because the posts offer anecdotes, brands that need measured data should ask for it explicitly.
The posts disclose no sponsorship, affiliate, client, employment, ownership, investment, or formal partnership.
Read more
Menesklou writes about automation for embedded, automotive, and industrial systems, citing Anthropic, Citrix, Bosch, Siemens, QNX, and Y Combinator as examples in their arguments.
They also refer to building in this space and customer calls with automotive, medical device, financial software, industrial automation, and enterprise security buyers, but do not name their employer or business.
Ask them to clarify any relevant employment or ownership relationship.
Anthropic
Mention
A full post responds to Anthropic shipping computer control for Claude, arguing that clean consumer Macs are the easy case and that Citrix sessions, QNX cockpits, factory HMIs, and multi-country POS terminals are the real test.
Read more
No commercial relationship is stated; this is commentary about where Menesklou says they have been building.
Menesklou writes short, argumentative posts, each built around one reframe, so the work reads best in topical groups rather than chronologically.
Begin with the embedded and industrial-automation posts, where the recurring subject is software with no DOM, no selectors and no cloud sandbox—factory HMIs, automotive cockpits, Citrix sessions, point-of-sale terminals—and the argument that tooling investment follows the SaaS market while the hardest problems sit on test benches.
Next, read the posts on AI agents and workflow automation: enterprise buyers want an agent that owns a workflow end to end rather than another point tool, and consumer desktop-control demos should be measured against very different operating conditions.
The most concentrated idea appears in the post on test-team knowledge transfer: what a suite is for lives in people's heads, and that is the part that leaves when they do.
Finish with the post on where automation funding goes, which frames the European manufacturing angle as a deliberate counterweight.
Two traits recur: a stated preference for building for the hardest environment first, and reliance on customer conversations and field observation rather than published measurements.
Embedded test automationIndustrial automationWorkflow automationAgentic AIComputer use agentsTest knowledge transferAutomotive softwareAutomation market patternsEmbedded systemsEnterprise softwareSoftware verificationShort-form commentaryOpinion and argumentEmbedded engineersEnterprise engineering teams
Both write about connecting AI agents into repeatable, end-to-end workflows rather than using single tools.
Read more
Rehman's two-part 'Agent Factory' posts describe specialist agents researching, specifying, implementing and reviewing work behind approval checkpoints. Menesklou's customer-call post argues that buyers want an agent to own a workflow from trigger to finished artifact—the same shift from point tools to owned processes.
Rehman writes as a vendor explaining a build service, naming the tools (Perplexity, OpenAI, Claude) and distinguishing build costs from running costs.
The work is framed around selling a project.
Menesklou makes a case about markets and operating conditions, grounded in non-web environments and customer conversations rather than a service offer or tool stack.
Both think in terms of agent infrastructure and workflow ownership rather than isolated automation tasks.
Read more
Lloyd lays out a layered 'software factory' stack—definition in code, context, compute, inference, improvement, orchestration, access. Menesklou approaches the same territory from the buyer's side: an agent that carries a workflow through the screens, APIs and databases it touches.
Lloyd's posts promote a specific product and its integrations, with architecture detail, release announcements and pricing-style incentives.
The focus is developer and software-factory infrastructure.
Menesklou presents neither a stack nor a product, focusing instead on embedded, industrial and regulated environments where the constraints are hardware, latency and firmware rather than the software factory.
Both write for engineering teams in regulated, long-lifecycle industries—automotive, embedded and manufacturing—and treat that setting as a distinct discipline rather than a branch of web development.
Read more
Camacho's posts on software-defined vehicles and embedded security testing cover the same sector and share the assumption that verification happens on constrained, hard-to-patch systems.
Camacho focuses specifically on security verification—ISO/SAE 21434, static and dynamic analysis, fuzz testing, penetration testing—and points readers to longer blog guides.
The posts have a vendor-content-marketing feel and use heavy hashtagging.
Menesklou writes about automation and workflow ownership rather than security, in short argumentative posts with no links or long-form companion.
Before a thought-leadership or advisory decision that depends on reaching particular job roles, ask for documented audience survey results or another source identifying those roles.
For a broader reach check, request recent LinkedIn audience analytics for geography, age, and gender.
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.
A strong fit for a B2B enterprise automation or device-testing platform seeking a research or advisory collaboration with engineering, quality, and operations leaders in automotive, manufacturing, medical devices, or regulated enterprise IT.
Read more
The goal: establish the platform as a serious voice in end-to-end workflow ownership where there is no browser, DOM, or cloud sandbox, and produce a co-authored field note or interview that sales teams can use in those accounts.
Menesklou’s recurring material speaks to these conditions: embedded test benches where the last visual check is manual, Citrix sessions with three-second latency, QNX cockpits, HMI panels on factory floors, point-of-sale terminals running different firmware across countries, air-gapped networks, and tests that must run across 50 hardware variants without rewriting.
A customer-call post states the thesis directly: buyers did not ask for another test automation, RPA, or work-instruction tool; they described an agent that owns a workflow from ticket through screens, APIs, and databases to the produced artifact, with people handling exceptions.
That is a natural frame for a platform selling workflow ownership rather than a point tool.
The knowledge-transfer post offers a second, less tool-centric angle for services and advisory work: release confidence leaves with a key engineer, the pipeline stays green, and nobody can explain half the suite.
A campaign can address that problem without having to establish that it exists.
The posts offer field observation, not measured outcomes, case studies, or named customer references; substantiate any performance claims separately.
The audience section shows subject-matter fit but no verified job roles or demographics.
If the campaign depends on a specific title mix, ask for audience survey results or LinkedIn analytics.
No sponsorship menu, rate card, media kit, or inquiry route is documented, so propose a defined research or advisory engagement rather than selecting from a published offering.
When to choose a specialist
A poor fit for a consumer AI assistant or desktop-agent vendor, or a browser-first SaaS testing tool seeking paid social promotion to knowledge workers or front-end product teams.
Read more
The brief calls for short sponsored posts and a product walkthrough showing an agent controlling a Mac or a browser test suite speeding up web releases.
Menesklou’s posts draw the opposite boundary: a clean Mac with Slack and a calendar versus a Citrix session with three-second latency, a QNX cockpit, an HMI panel deployed before anyone talked about AI agents, and a POS terminal in 25 countries on different hardware and firmware.
The argument is that consumer is where attention sits, enterprise is where the need sits, and once you solve a Citrix session or embedded panel, a web app becomes the easy case.
A campaign built on consumer-agent convenience or browser coverage would work against the frame that makes this creator useful to the audience.
The approach section describes short, opinionated reframes with no links, product pitches, technical deep dives, benchmark write-ups, or product walkthroughs; a demo-led or tutorial-led deliverable would fight the grain.
No sponsorship product, placement, rate card, or inquiry route is documented, so a standard paid placement is not supported.
A vendor with a reliability, self-healing, air-gapped, or hardware-variant story could fit a different, enterprise-focused brief.
A worked campaign example
Worked campaign angle: a co-authored research note titled 'The last manual step: where workflow automation still stops in regulated manufacturing.' An industrial automation platform wants a credible entry into automotive, medical-device, and factory engineering accounts without a product tutorial.
Format: one 900- to 1,200-word co-authored article or gated research brief, three short LinkedIn posts from Menesklou’s account, and a 30-minute roundtable or interview with engineering leaders.
Open with the test-bench scene from the work section — book the bench, wait two weeks, sit in front of the screen, verify by hand — then move to the enterprise conditions from the computer-use-agent post: slow Citrix, QNX cockpits, legacy HMIs, POS firmware spread, air-gapped networks, and many hardware variants.
The platform supplies the practical turn: what end-to-end workflow ownership looks like when the screen is simply where the work happens.
End with a diagnostic checklist readers can use: which ticket triggers the workflow, which screens, APIs, and databases it touches, what artifact it must produce, where humans handle exceptions, whether it can run air-gapped, how many hardware variants it must cover, and how it behaves when the interface changes between firmware versions.
Distribute through an organic LinkedIn post from Menesklou, a co-branded page on the platform’s site, and a roundtable invite to the platform’s industrial accounts.
Measure qualified conversations with automotive, manufacturing, and medical-device engineering leaders, plus downloads or completed checklists, not impressions alone.
This approach uses Menesklou’s reframe and examples, leaves room for a short opinionated turn, and avoids a product walkthrough.
If the platform cannot provide a real industrial customer example or measured data, do not manufacture one; keep the piece as field observation.
No partnership terms, pricing, or inquiry route are documented, so define the engagement as a research or advisory project with deliverables, disclosure, and review rights before starting.
Choose Muneeb Ur Rehman when the collaboration needs an implementation partner rather than a field perspective.
Read more
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.
Menesklou's posts focus on general workflows and named model steps: research, specification, implementation, review and tests.
They do not address the environments central to their case: no DOM, Citrix latency, QNX cockpits, air-gapped networks or hardware variants running different firmware.
For audiences in embedded or industrial engineering, ask for domain-specific observation of these conditions; an implementation partner's process post is not a substitute.
Choose Zach Lloyd when the buyer needs a product or platform to run and govern agents, not just a voice to explain the problem.
Read more
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.
The posts advocate a specific commercial product, so a collaboration would tend toward adoption or promotion of that stack rather than neutral field research.
The environments that distinguish Menesklou's brief — latency-bound sessions, embedded panels and air-gapped networks — appear only as generic conditions in the stack description, not as designed targets.
If the fit decision depends on experience in hard, no-browser environments rather than building the orchestration layer, that domain specificity is what the collaboration gives up.
Choose Ricardo Camacho when the collaboration concerns security verification in automotive and embedded systems rather than workflow automation ownership.
Read more
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.
Camacho's material focuses on security testing and standards compliance; it reads as company-published content pointing to a guide and a blog.
It does not address the automation-ownership argument central to a workflow-ownership campaign: an agent runs a workflow from the triggering ticket through screens, APIs and databases to the produced artifact.
If that is the platform's message, a security-verification specialist shifts the conversation to a different problem; decide whether that adjacent topic earns its place.
This profile draws on five LinkedIn posts published between March and June 2026.
They show Menesklou’s views on automation in automotive, manufacturing, medical-device and other enterprise settings, including the challenges of testing unfamiliar interfaces and transferring engineering knowledge.
The posts offer observations and customer-call accounts, not measured performance results.
