Founder

Praveen Shahi - AI GTM Engineer

Since 2014 I have worked across sales, marketing, product management, analytics and machine learning - four years of that at Amazon and Meta on global data science and ML projects, and the rest carrying a revenue number.

Today I run Amoris, a founder-led AI GTM agency, and ship LangGraph and n8n orchestration systems. The range is the point. Every specialist a founder hires describes the problem in the shape of their own job, so nobody owns the question of which problem is actually the problem. That question is what I answer.

Book 30 minutes shahi@amoris.in

A decade of finding patterns, designing systems and driving revenue

AmazonMetaGreat LearningLeverage Edu

Why these patterns matter

Most GTM engineers configure tools. I architect the systems.

Ten years carrying a revenue number, then three years shipping production AI. Each place taught a pattern, and every pattern is in what Amoris builds.

Amazon
Infrastructure at scale
Systems built for reliability, cost per call, and the thing that breaks at 2am - not the demo.
Applied: LangGraph reasoning chains with real error handling and state that survives failure.
Meta
Growth loops and measurement
Every funnel instrumented. Nothing shipped on a hunch, everything measured to basis points.
Applied: Clay enrichment waterfalls and qualification logic scored on evidence, not guesses.
Great Learning
Revenue operations at scale
Running a large sales organisation, and opening new markets from scratch across LATAM and Africa.
Applied: An audit method that finds where revenue leaks, and process design that scales without new headcount.
Leverage Edu
Go-to-market and revenue models
Complex buyers, long cycles, and a motion built from zero to repeatable revenue.
Applied: SPIN and MEDDIC playbooks wired into the automation, so outbound argues instead of spamming.

Read the full story

How I work with clients

I run Amoris full time. Engagements start with a paid diagnosis and grow from what it finds - and the working relationship matters as much as the scope, so here is what I take on and what I do not.

What I take on

Diagnosing a motion that is not working, when the internal explanations conflict
Designing and building the GTM automation layer on the stack you already run
Working alongside a founder or a lean GTM team, not in place of them
Long-run systems work once a pilot has shown what actually moved
Remote, across US, EU and APAC time zones

Not a fit

Taking the decision off your desk - you keep it, that is the whole model
Staffing an SDR team or running your outbound day to day
Volume-first outbound where the evidence behind the message does not matter
Handing over a tool and leaving

Four beats, in order.

2014-2023
Systems, then revenue
Four years at Amazon and Meta, on global data science and ML projects. Finding patterns in systems large enough that intuition stops working and design has to take over. That is where I learned how a system is actually put together - and how confidently people misread one.
Then I went and carried a number. Sales and growth leadership across brands at very different stages - building teams, opening new markets from scratch, owning the number rather than advising on it. In every case the job was designing the operating process, not adding headcount to a problem.
Two halves that rarely sit in one person. The system designers have never had to explain a missed quarter. The revenue operators are waiting on an engineering team. Carrying both is what lets me tell a founder which half their problem actually lives in.
2023-2025
The pivot
In 2023 I stopped waiting for engineering. I learned to build.
I shipped orbisojas - a consciousness-and-AI platform with a multi-prompt architecture, real paying clients and live payments - entirely solo. Product, prompts, payment flow, deployment. No engineering team, no hand-off, no ticket queue.
It taught me what production actually costs. Not the demo. The reliability, the cost per call, the thing that breaks at 2am. That is a different education from building a prototype.
2025-2026
Field proof
Then I took it into the field. At MsgKart I built go-to-market from zero - an AI automation SaaS selling to non-technical buyers, which is the hardest version of the problem.
I designed the outbound stack end to end: Clay for waterfall enrichment, LLMs for personalisation, n8n for orchestration. I also built the SPIN and MEDDIC playbook for selling AI to buyers who do not care what a model is.
That is the proof the two halves connect. The stack worked because the GTM judgment shaped it, and the GTM worked because I could build the stack.
2026-now
AI GTM Engineer
Today I run Amoris and ship LangGraph and n8n agent systems for B2B revenue teams. I also publish what I learn - intel-echo, an npm package for auditing where an AI's reasoning exceeded its mandate, came directly out of running these systems in production.
Most GTM engineers configure tools. I architect the systems and know which levers matter. I sell AI, and I build the AI I sell.
That combination is rare, and it is the entire reason this works.

The range that work covered

Operating work before Amoris, across LATAM, Africa and India. Not Amoris client results - Amoris has not run a client engagement yet - and not a forecast of what any engagement produces. It is here to show the breadth of situations the judgement came from.