DEV Community: Alessandro Pireno

Why Your AI Agent Needs to Argue With Itself

Alessandro Pireno — Tue, 24 Mar 2026 11:07:05 +0000

A 600-line bash script, four AI personas, zero shared context. 52 ideas in 4 minutes.

Back when I was running engineering and product teams I used to drag people from all over the office into ideation sessions. Architects, product folks, the security guy who never wanted to be there. We'd cover the walls in sticky notes, draw terrible diagrams on whiteboards, and argue about approaches until something clicked. It took me years to find a version of the IDEO process that kept things loose enough to stay creative but structured enough to actually produce something useful.

Now I run a one-person company. No VP of Engineering. No product team. Nobody to pull into a conference room. But this morning four senior executives independently generated 52 ideas, cross-voted on each other's proposals with mandatory improvement suggestions, merged overlapping concepts, and produced ranked PRDs. While I was taking my kids to school.

They're AI personas. We lost the sticky notes and the bad whiteboard drawings but the workflow still works. And the output is unrecognizable from what a single prompt produces.

The single-prompt trap

You've done this. You ask an LLM for 10 ideas and you get 10 ideas. They're fine. They all sound like they came from the same person because they did. No tension. No cross-pollination. Nobody saying "that's clever but have you considered the security implications?"

The problem isn't intelligence. It's perspective diversity. One LLM instance optimizes for coherence within a single worldview. It won't generate an idea and then attack it from a completely different angle because that would be incoherent within the same generation.

You can't get genuine disagreement from a single context window.

The fix: zero shared context

Run multiple LLM instances. Give each its own process, its own system prompt, the same goal. No persona sees another's output until voting begins.

Phase 1: ideate    4 independent LLM calls (one per persona)
Phase 2: vote      4 independent LLM calls (each sees others' ideas, not their own)
Phase 3: merge     1 facilitator call (consolidates + ranks)
Phase 4: produce   1 call (VP Product drafts PRDs from winners)

That's IDEO's design sprint. Ideate without judgment, converge through structured critique. Automated end-to-end in bash.

Personas that create friction

Each persona is a markdown file. Not "pretend you're an engineer." Specific concerns that collide productively.

VP Engineering cares about architecture purity, test coverage, performance budgets.
VP Product cares about user value, adoption paths, metric impact.
VP Security cares about attack surfaces, data integrity, threat models.
VP DevOps cares about operability, deployment complexity, monitoring.

Same problem. Four different entry points. Engineering proposes a trie-based type classifier. Product proposes a feedback flywheel. Security proposes negative constraints that block misclassification. DevOps proposes a parallelized pipeline with cold-storage caching.

52 ideas from 4 personas. Not 10 variations of the same idea from one.

Voting is where it gets interesting

Phase 2 separates this from running the prompt four times. Each persona votes on other personas' ideas only. You can't vote for your own. Every vote requires a mandatory improvement suggestion.

rules:
  you have exactly 3 votes
  you cannot vote for your own ideas
  for every vote, suggest a specific improvement
  the improvement must make the idea stronger

VP Security votes for VP Engineering's type classifier and adds: include negative suffix tries to prevent type-spoofing. VP Engineering votes for VP Product's feedback flywheel and adds: algorithmically calculate ROC-optimized confidence thresholds from the ground truth.

The ideas get better through voting. Not just ranked.

Real numbers

I ran this on a knowledge extraction problem. Pushing deterministic entity extraction from 47.7% recall toward 60%. Constraints: zero LLM calls, sub-3-second latency, YAML-configurable.

Rank	Idea	Votes	Merged from
1	Deterministic Classification Engine	2	4 ideas across Eng, Prod, Sec
2	The Emergent Flywheel	2	3 ideas across Prod, Eng, DevOps
3	Passive Entity Harvester	1	4 ideas across Eng, Prod, Sec
4	Cross-Sentence Entity Registry	1	1 idea from Prod
5	Vectorized Aho-Corasick Engine	1	1 idea from Eng

52 raw ideas. 15 unique after merge. Top 5 with cross-functional votes. PRD drafts ready to go.

The top idea was independently proposed by three personas from three angles: a trie-based classifier, a subtype pruner, and type-confusion guardrails. The merge revealed they were all solving the same problem from different entry points. The combined concept was stronger than any individual proposal.

No single prompt produces that convergence.

Under the hood

It's a bash script. Heredoc prompts piped to Gemini CLI (or Claude CLI, it auto-detects what's installed). Each phase writes output to a file:

# Phase 1: each persona ideates independently
for PERSONA in $PERSONAS; do
    cat > "$PROMPT_FILE" <<PROMPT
You are adopting the following persona:
$(cat "docs/personas/${PERSONA}.md")

Generate as many ideas as you can (aim for 8-15).
Think from your persona's unique perspective.
No idea is too crazy. Do NOT evaluate, just generate.

=== GOAL ===
$(cat "$GOAL_FILE")
PROMPT

    cat "$PROMPT_FILE" | gemini > "phase1-ideas-${PERSONA}.md"
done

Phase 2 compiles all ideas, builds a document for each persona containing only other personas' ideas, asks for votes. Phase 3 merges and tallies. Phase 4 writes PRDs from the winners.

Runtime: about 4 minutes. Cost: a few cents, or zero on Gemini's free tier.

It's open source

The agent workflow template includes:

ideo-sprint.sh the full IDEO sprint (this article)
vp-review.sh automated VP reviews of sprint plans and dev reports
persona templates with customizable VP definitions
sprint workflow covering plan, review, execute, evaluate lifecycle

Drop scripts/agentic/ and docs/personas/ into any repo. Multi-agent workflow running in your terminal.

The bigger pattern

Honestly the thing I miss most about running teams is the creative friction. Getting smart people in a room who see the same problem differently and letting them go at it. That energy is hard to replicate.

This was my attempt to bring some of that back into a world where I'm building solo with agents. We don't have the sticky notes or the someone-brought-donuts energy but the core of it still works. Give independent perspectives the same problem, let them collide, and see what survives.

I've started applying the same idea beyond brainstorming. Code review where an architect persona and a security persona independently review the same PR. Decision making where personas evaluate a proposal before seeing each other's takes. Risk analysis where domain experts independently flag concerns and then merge.

Always the same pattern. Diverge independently. Converge through structured critique.

Your AI agent doesn't need to be smarter. It needs to argue with itself.

The agent workflow template is open source. Works with Gemini CLI, Claude CLI, or both. Contributions welcome.

Tags: #ai #agents #devtools #opensource

10 Things That Need a Shell: Where the Filesystem Metaphor Could Fix Agent Interfaces

Alessandro Pireno — Wed, 04 Mar 2026 12:11:25 +0000

The Pattern That Worked

I recently shipped DOMShell — an MCP server that maps Chrome's Accessibility Tree to a virtual filesystem. Instead of feeding agents screenshots or raw HTML, it lets them ls, cd, grep, and click their way through web pages.

The result: 2× fewer API calls compared to screenshot-based browsing across controlled testing with Claude (4 tasks, 8 trials). The filesystem metaphor gave the model a spatial map of the page, so it spent less time exploring and more time extracting.

The insight underneath is simple: agents waste most of their cycles on orientation, not action.

The current playbook — pump screenshots into a vision model, dump 50k tokens of raw HTML into the context window, or chain brittle CSS selectors — treats the model as a brute-force parser. It works until it doesn't, and when it fails, it fails silently. You don't get an error. You get a confident wrong answer and a $4 API bill.

When you give agents a navigable, scoped, low-entropy interface instead of a high-entropy dump of raw data, they get dramatically more efficient. Not incrementally — structurally.

That got me thinking: where else are agents hitting the same wall?

The Filesystem Metaphor, Generalized

The pattern has three primitives that LLMs already deeply understand from training data:

Scope (cd) — Narrow your working context to reduce noise
Discover (ls, find, grep) — See what's available within that scope
Act (cat, click, type, call) — Do something with what you found

Every interface below has the same fundamental problem: agents don't have a structured way to scope, discover, and act. They get a flat API or a firehose of data and burn calls trying to orient themselves.

Here are 10 interfaces that could benefit from the shell treatment. I want to build the next one — help me pick which.

1. GraphShell — Knowledge Graph Navigator

The problem: Graph databases (Neo4j, Neptune, TigerGraph) are powerful but agents struggle with schema discovery and pathfinding. Cypher and Gremlin are expressive query languages, but agents don't know what nodes or relationships exist until they explore — and exploration is expensive.

The shell: Nodes become directories. Edges become navigable links with typed relationships. ls shows adjacent nodes with relationship types and properties. cd traverses edges. find --type Person --depth 3 does bounded breadth-first search. path A B computes shortest paths. schema shows the full ontology.

Why it works: Graphs are already hierarchical-ish — they just need scoping. An agent exploring a company knowledge graph could cd Company/Acme → ls --rel EMPLOYS → cd employees/jane → ls --rel MANAGES instead of writing a 6-line Cypher query to get the same traversal. Having spent time building on SurrealDB — a multi-model database with graph capabilities — I watched developers struggle with exactly this: the data was richly connected, but every query required you to already know the shape of the graph. Agents hit the same wall, harder.

The business case: Knowledge graph queries are the backbone of fraud detection, recommendation engines, and supply chain mapping. An agent that can traverse a graph in 4 calls instead of 12 doesn't just save API cost — it makes real-time graph-powered workflows viable for the first time.

2. APIShell — REST/GraphQL Endpoint Navigator

The problem: Agents are terrible at API discovery. They hallucinate endpoints, guess parameter names, and burn calls on 404s. Even with an OpenAPI spec in context, they struggle to chain calls correctly.

The shell: Ingests OpenAPI specs or GraphQL introspection and presents endpoints as a filesystem: /users/, /users/{id}/orders/, /users/{id}/orders/{id}/items/. ls shows available operations and parameters. cat shows schema. call GET /users/123 executes. Agents cd into nested resources and find across the API surface.

Why it works: REST APIs are already hierarchical — resources nest inside resources. The shell makes that nesting navigable instead of requiring the agent to memorize the spec.

The business case: Every agent-powered integration — CRM sync, payment processing, data pipeline orchestration — starts with API discovery. Cut the discovery overhead and you cut the cost of every downstream automation.

3. K8Shell — Kubernetes Cluster Navigator

The problem: kubectl output is verbose, unstructured, and agents constantly run the wrong command or parse output incorrectly. Getting the status of a single deployment requires chaining 3-4 commands.

The shell: Namespaces are top-level directories. Resource types are subdirectories. Individual resources are files. cd production/deployments/api-server then cat shows status, replicas, image version. logs streams container output. find --status CrashLoopBackOff across a whole cluster in one call.

Why it works: Kubernetes already has a natural hierarchy (cluster → namespace → resource type → resource → containers). It's just not exposed as navigable.

The business case: MTTR is the metric that matters. An agent that can find a crashing pod, pull its logs, and identify the root cause in 3 calls instead of 10 turns a 20-minute incident into a 2-minute one. For a startup running $50k/month in compute, finding zombie resources alone could pay for the tooling.

4. CloudShell — AWS/GCP/Azure Resource Navigator

The problem: Cloud consoles are the worst agent interface — hundreds of services, thousands of resources, nested in regions and accounts. An agent needs 10+ API calls just to orient itself in an AWS account.

The shell: /us-east-1/ec2/instances/, /us-east-1/rds/databases/, /global/iam/roles/. ls shows resources with key metadata inline. find --type security-group --port 22 finds open SSH across every region. tree shows the blast radius of a VPC.

Why it works: Cloud resources have natural hierarchy (region → service → resource type → resource) but every cloud provider's API requires you to specify the scope upfront rather than navigate to it.

The business case: Security audits, cost optimization, and compliance checks all require cross-account, cross-region visibility. An agent that can find --type security-group --port 22 across your entire AWS org in one call replaces a week of manual audit work.

5. GitShell — Repository History Navigator

The problem: Git's CLI is powerful but output is unstructured text. Agents struggle with log parsing, diff interpretation, and blame navigation. Merge conflict resolution — where agents currently fail catastrophically — is a chain of poorly-structured interactions.

The shell: Branches are directories. Commits are navigable nodes. cd main/HEAD~5 puts you at a point in time. diff shows changes in structured format. blame function_name traces authorship. find --author=alex --since=2w --path=src/ replaces gnarly git log incantations.

Why it works: Git history is a DAG — it's already a graph structure. The shell linearizes it into something navigable.

The business case: AI-assisted code review and automated PR summaries are already shipping. The bottleneck is agent comprehension of change context — not just what changed, but why and who else touched it. A navigable git history makes those workflows reliable instead of approximate.

6. DataShell — Database Schema & Query Navigator

The problem: Agents writing SQL against unfamiliar databases waste most of their calls on INFORMATION_SCHEMA queries and DESCRIBE TABLE to understand what they're working with. They build a mental model one table at a time.

The shell: Schemas are directories. Tables are subdirectories. Columns are files. cd analytics/fact_orders then ls shows columns with types, nullability, foreign keys. sample 10 shows real data. stats revenue shows distribution. query "SELECT ..." executes.

Why it works: Databases already have three-level hierarchy (schema → table → column). The shell makes it navigable and adds introspection primitives that agents currently cobble together from metadata queries. At Snowflake, I watched analysts spend 30% of their time just figuring out which tables and columns existed before they could write a single query. Agents do the same thing, except they burn tokens instead of hours.

The business case: Text-to-SQL is a $2B+ market growing fast. The accuracy ceiling today is schema comprehension — not query generation. Fix the agent's understanding of the database and the SQL practically writes itself.

7. LogShell — Observability Stack Navigator

The problem: Log exploration (Datadog, Splunk, ELK) is one of the hardest agent tasks. The data is temporal, high-volume, and agents don't know which filters to apply until they see what's there.

The shell: Services are directories. Time ranges are navigable: cd api-server/last-1h. grep ERROR searches within scope. find --level=error --service=payments --since=30m replaces complex query syntax. trace request-id-xyz follows a distributed trace across services. stats shows error rate trends.

Why it works: Observability data has natural hierarchy (service → time range → severity → individual events) but every platform exposes it as a query builder instead of a navigable space.

The business case: On-call engineers spend most of their incident response time on triage, not resolution. An agent that can scope, search, and trace in structured commands turns a 45-minute triage into a 5-minute one — and makes 3am pages survivable.

8. DocShell — Large Document Navigator

The problem: PDFs, legal contracts, SEC filings — anything longer than a context window. Agents currently get truncated chunks and lose spatial awareness of where they are in the document.

The shell: Sections and headings are directories. Paragraphs are files. cd "Article 7/Indemnification" scopes to a section. find --type definition locates defined terms. diff v1.docx v2.docx shows redlines structurally. xref "Force Majeure" finds every cross-reference.

Why it works: Documents already have hierarchical structure (TOC, headings, sections). The shell makes that structure navigable instead of forcing agents to process content linearly.

The business case: Legal review, due diligence, and regulatory compliance all involve agents processing documents that exceed context windows. A navigable document structure means the agent can answer "what does the indemnification clause say?" without ingesting 200 pages.

9. MailShell — Email Thread Navigator

The problem: Email is deceptively hard for agents. Threading, attachments, reply chains, CC dynamics, and the social graph embedded in headers. IMAP and Gmail APIs return flat lists that lose conversational structure.

The shell: Inbox is a directory. Threads are subdirectories. Messages are files. cd thread-xyz enters a conversation. ls --from=nick@connectifi.co --since=1w filters. attachments lists files across a thread. participants shows the social graph. find --has-attachment --unread replaces complex query syntax.

Why it works: Email is already hierarchical (account → folder → thread → message → parts) but no API exposes it that way.

The business case: AI email assistants are everywhere, but they're all working against flat APIs. A shell that preserves thread structure and social context would make "summarize this thread" and "draft a reply" dramatically more reliable — and stop agents from replying to the wrong person in the chain.

10. MeetingShell — Calendar & Transcript Navigator

The problem: Meeting transcripts, action items, and calendar context are scattered across Zoom, Google Meet, Notion, and calendar apps. No single interface connects "what was discussed" with "what was decided" and "who committed to what."

The shell: ls today shows your schedule. cd standup-2026-03-02 enters a meeting's context. transcript shows what was said. actions lists commitments. attendees shows who was there. find --action-owner=me --status=open across all meetings finds outstanding commitments. grep "pricing decision" --since=1m searches all recent transcripts.

Why it works: Meetings have natural hierarchy (calendar → event → transcript → segments → action items) but the data is siloed across 4-5 apps.

The business case: The average knowledge worker spends 31 hours per month in meetings. The institutional memory from those meetings evaporates within days. An agent that can search across all your meeting history and surface outstanding commitments turns meetings from a time sink into a queryable knowledge base.

Which One Should I Build Next?

I'm going to build one of these. Here's how you can help:

🗳️ Vote for your top pick →

Or better yet:

Build one yourself. DOMShell is open source and the MCP server pattern is reusable. Fork it, swap the Chrome extension for a different data source, and the shell primitives carry over.
Tell me I'm wrong. Maybe there's an 11th interface I haven't thought of that's even more broken for agents.
Tell me you've already built it. I'd love to see prior art.

Drop a comment, vote, or reach out. The filesystem metaphor is a 50-year-old idea — it's just taken us this long to realize it's the right abstraction for AI agents too.

Links:

DOMShell: github.com/apireno/DOMShell
npm: npx @apireno/domshell
Full benchmark data: DOMShell vs CiC experiment

Built by Pireno. I do fractional CTO/CPO work helping teams ship AI-native products — if your agents are hitting an orientation wall on a specific stack, let's figure out which shell would unlock the most value.

Why I Built a Filesystem for the Browser

Alessandro Pireno — Thu, 26 Feb 2026 22:04:52 +0000

Why I Built a Filesystem for the Browser

Browser automation for AI agents has an impedance mismatch problem. We feed agents high-entropy noise — raw HTML, pixel screenshots, brittle CSS selectors — and expect them to produce low-entropy, structured actions. The result is fragile, expensive, and full of silent failure modes.

DOMShell fixes this by exposing the browser's Accessibility Tree as a virtual filesystem. Agents navigate pages with ls, cd, grep, click — the same commands they already know from every Unix system in their training data. No new API to learn. No screenshots to parse. No selectors to break.

The Impedance Mismatch

Three approaches dominate browser automation today. All three are engineering mismatches.

Screenshots + vision models. The agent takes a screenshot, sends it to a vision model, gets back pixel coordinates, clicks, takes another screenshot. This burns vision tokens on every action, adds a full round-trip per interaction, and fails silently when coordinates shift. A button at (450, 320) moves to (450, 380) because a cookie banner loaded. The agent clicks empty space and doesn't know it. You debug ghost interactions.

CSS selectors / XPath. Trading pixel fragility for structural fragility. #main > div:nth-child(3) > ul > li:first-child > a breaks when a wrapper div gets added. Even semantic selectors like [data-testid="submit"] depend on the site's developers having added test IDs. Most haven't. And the agent still needs to reason over raw HTML to write the query — thousands of tokens of noise for a single interaction.

Coordinate-based clicks. Resolution-dependent. Viewport-dependent. Zoom-dependent. Responsive-layout-dependent. Every variable the agent can't control becomes a failure mode.

The common problem: all three approaches force the agent to work with a representation that wasn't designed for programmatic navigation.

The Accessibility Tree Is the Right Abstraction

Browsers already solved "navigate this page without looking at it." The Accessibility Tree — the internal representation that screen readers consume — is deterministic, semantic, and compact. Every button knows it's a button. Every link carries its href. Every input has a label and type. No invisible wrapper divs, no CSS noise, no layout-dependent coordinates.

The AX tree is the low-entropy, structured signal that agents need. The question was how to expose it.

The Filesystem Metaphor

The AX tree has a natural hierarchy. Container elements (navigation, main content, sidebars, forms) map to directories. Interactive elements (buttons, links, inputs) map to files. The whole structure maps cleanly to a filesystem — and every LLM already knows how to operate a filesystem.

ls to see what's on a page. cd to scope into a section. cat to inspect an element. grep to search. find to discover by type. click to interact. text to bulk-extract. These commands are in every model's training data. Zero-shot usability.

dom@shell:$ cd %here%
✓ Entered tab 386872589
  Title: Wikipedia
  URL:   https://www.wikipedia.org/

dom@shell:$ ls
[d] main/
[d] contentinfo/

dom@shell:$ cd main
dom@shell:$ tree 2
main/
├── [d] top_languages/
│   ├── [x] english_7141000_articles_link
│   ├── [x] deutsch_3099000_artikel_link
│   ├── [x] français_2740000_articles_link
│   └── ...
├── [d] search/
│   └── [x] search_input
└── [x] read_wikipedia_in_your_language_btn

The page is a directory tree. submit search_input "Artificial intelligence" navigates. The tree auto-refreshes. You're now looking at the article's filesystem.

No screenshots. No coordinates. No selectors.

Aggressive Flattening

The raw AX tree is noisy. Hundreds of wrapper nodes — role=generic, role=none, unnamed divs — exist for CSS layout, not semantics. Without filtering, you get listings of generic_1, generic_2, generic_3 with no indication of what anything is.

DOMShell's VFS mapper (vfs_mapper.ts) recursively flattens through non-semantic nodes, promoting their children up. If a role=generic node has one child, the child replaces it. The result is a clean tree where every visible element has a name derived from its accessible name and role: submit_btn, contact_us_link, email_input. Duplicates get disambiguated with _2, _3.

This is the core design decision. Minimizing node bloat maximizes agent signal-to-noise. Every flattened wrapper node is a token the model doesn't waste reasoning about.

Architecture

Three components, cleanly separated.

Chrome Extension (the kernel). A background service worker runs the shell: command parsing, AX tree traversal via CDP, filesystem mapping, DOM change detection. The side panel is a thin terminal (React + Xterm.js) — no logic, just I/O. The service worker reads the AX tree through chrome.debugger (Chrome DevTools Protocol 1.3), including cross-iframe discovery via Page.getFrameTree.

MCP Server (the bridge). A standalone Node.js HTTP server on localhost:3001 that any MCP-compatible client connects to — Claude Desktop, Claude Code, Cursor, Windsurf, Gemini CLI. Translates MCP tool calls into shell commands, pipes them to the extension over WebSocket (localhost:9876), streams results back. Multiple clients can connect simultaneously.

Security tiers. Read-only by default — agents can browse but not act. Write commands (click, type, scroll, js) require --allow-write. Cookie access (whoami) requires --allow-sensitive. Domain allowlists restrict which sites agents can operate on. Every command is audit-logged with timestamps. Auth tokens gate the WebSocket bridge.

The separation is deliberate. You can use DOMShell interactively without the MCP server. You can let an agent browse your tabs without it being able to click "Delete Account."

Benchmark: 50% Fewer Tool Calls

I ran 8 trials across 4 tasks using Claude Opus 4.6 with both DOMShell and Anthropic's built-in browser automation (Claude in Chrome). The metric was tool call count — directly proportional to latency and API cost.

DOMShell averaged 4.3 calls per task vs Claude in Chrome's 8.6 — a 50% reduction.

The biggest win was content extraction: DOMShell completed it in 2 calls (navigate + extract) where CiC needed 5-6. The filesystem metaphor lets the agent scope to the right section (cd main/article) and bulk-extract (text) in a single call, rather than navigating through read_page results iteratively.

Where CiC holds an edge is raw JavaScript execution — javascript_exec can batch multiple DOM operations into a single call. DOMShell's counter is the for + script + each pipeline, which collapses multi-page workflows into 1-2 calls by iterating over command output and replaying saved scripts across URLs.

The 50% reduction translates directly to cost and latency. For agents running in production — where every tool call is an API round-trip — halving the call count is a meaningful operational improvement.

What's Next

DOMShell is open source (MIT) and free. On the roadmap: a headless mode — a self-contained Chromium process that agents launch directly for CI pipelines and server-side automation where no visible browser is needed.

The for + script + each pipeline is where the compound efficiency gains live. Save a command sequence as a script, replay it across N URLs in a single call. O(2N) tool calls become O(2). For any agent doing research, extraction, or monitoring across multiple pages, that's a step change.

The browser is your filesystem. ls it.

GitHub: github.com/apireno/DOMShell
Project Page: DOMShell
Built by Pireno

Bridging the Valuation Gap: Product Strategy for the AI-Native Era

Alessandro Pireno — Thu, 26 Feb 2026 21:58:01 +0000

The Transition from Wrapped to Native
I’ve spent the last 20 years at the intersection of deep-tech engineering and product leadership—ranging from Applied Physics at Caltech to scaling technical organizations at Snowflake and SurrealDB.

In the current market, we are seeing a clear divide. Most companies are AI-wrapped—placing a thin LLM layer over existing, legacy architectures. The long-term winners will be AI-native: companies that rebuild their core stacks to be fundamentally navigable, deterministic, and actionable by autonomous agents.

The Valuation Gap
I’ve identified a consistent gap in the valuation of technical startups. It’s the friction point between a brilliant engineering breakthrough and a repeatable, scalable GTM strategy. Often, the technical depth is there, but the product strategy hasn't accounted for the shifting unit economics of AI or the fragility of current agentic workflows.

As a Fractional CPO and GTM Advisor, I step into this gap to help founders build for stability and scale.

Architectural Pragmatism
I don’t believe in AI hype. I believe in pattern recognition, latency reduction, and unit economics. My work focuses on:

Semantic Interfaces: Moving beyond brittle, vision-based automation toward structured, semantic representations of data. DOMShell is a prime example—turning the browser into a filesystem because that’s the interface agents were built to understand.

Knowledge Orchestration: Building the layers that allow AI to manage complex, unstructured data without constant manual code updates.

GTM for Deep Tech: Aligning engineering roadmaps with market realities to ensure that technical excellence translates into market dominance.

Execution that Scales
With a background in both Physics and Business (Columbia MBA), I am comfortable navigating both a codebase and a P&L. I help teams move past the demo phase and into production-grade reliability.

Work with Me
I take on a limited number of fractional roles and advisory seats for companies building the next generation of data infrastructure and agentic platforms.

If you’re a founder looking for an experienced partner to help navigate the architectural and strategic challenges of the AI-native landscape, let’s talk.

Website: https://pireno.com

LinkedIn: https://linkedin.com/in/apireno

GitHub: https://github.com/apireno