Parahelp only gets paid when it closes the ticket
Think about the last time you contacted support for a product you actually pay for.
You were probably not looking for a definition. You knew what you wanted: a refund processed, a seat added, a stuck account unblocked, a charge explained. What you often got instead was a chat widget that could describe the refund policy in fluent prose and then, at the moment something real had to happen, handed you to a queue. The bot answered the question. It did not do the thing.
That gap is the whole problem with the first wave of AI support. The models got very good at retrieving an answer from a help center and phrasing it nicely. But a large share of real support tickets are not questions at all. They are requests for an action inside a system: issue the credit in Stripe, flip the flag in the admin panel, file the bug in Linear, look up why this specific customer's export keeps failing. A tool that can only talk, no matter how well, leaves the hardest and most frequent tickets exactly where they were, waiting on a human.
That is the gap Parahelp is built to close.
Parahelp is an AI support agent for software companies. It plugs into the help desk a team already runs, reads the knowledge base and the internal procedures, connects to the tools where the work actually happens, and resolves complex tickets end to end. When it is confident, it finishes the job. When it is not, it hands off cleanly to a person. The company's own framing is deliberately narrow: not a chatbot, but a support agent that can use all your tools.
Answering is not the same as resolving
The distinction between answering and resolving sounds small until you look at what support teams spend their time on. A meaningful fraction of tickets follow a pattern that no amount of clever text generation can shortcut. A customer asks for a refund. Resolving that means checking whether they are eligible under the current plan, confirming the subscription details, processing the refund in the payment system, and then writing back to explain what happened. Four steps, only one of which is talking.
The first generation of support bots stopped at the talking. They were built on top of a help center, so they were fluent about policy and helpless about execution. The result was a familiar experience: a confident paragraph followed by "let me connect you with someone who can help." For the customer, that is worse than useless, because it raised the expectation of a resolution and then failed to deliver one.
Parahelp's design starts from the opposite end. It assumes the goal is a closed ticket, and it works backwards from there to whatever combination of reading, deciding, and acting that requires. The agent generates a resolution plan for each ticket, pulls the relevant customer and product context, and then executes against that plan inside the actual tools. The knowledge base and the standard operating procedures are the reference material. The integrations are the hands.
A team of agents, not a single bot
The more interesting architectural choice is that Parahelp is not one agent trying to do everything. It runs as a small team with different jobs.
There is a customer-facing agent that handles the end-user tickets as they arrive across a company's support channels. And there is an internal agent that works alongside the support operations team, helping with the behind-the-scenes work of running a queue rather than sitting on the front line. Splitting the two matters because the two roles have genuinely different failure modes. The customer agent has to be careful and legible, because it is speaking for the brand to a paying customer. The internal agent can be more aggressive and exploratory, because a human on the ops team is reviewing its work.
Underneath both sits the connective layer that makes end-to-end resolution possible. Parahelp is designed to live inside the help desks companies already use, including Zendesk, Intercom, and Front, and to reach into the systems where resolutions actually get carried out: Stripe for billing, Slack for coordination, Linear for engineering handoffs, Retool and internal admin panels for account changes. Because it reads a company's own procedures, it learns the specific way that company handles a refund or an escalation rather than applying a generic script. The company says a team can get it running in about a day without pulling in engineers, which matters for the buyer, because the people who feel support pain most acutely are rarely the people who control engineering time.
Getting paid by the resolution
The clearest statement of what Parahelp believes about its own product is in how it charges for it. Most support software is priced by the seat or by a monthly platform fee, which means the vendor gets paid whether or not the tool actually reduces the work. Parahelp prices per resolution. A customer pays when the agent fully closes a ticket on its own, without handing it to a human.
That pricing model is a real commitment, not a marketing flourish. It only makes sense for a company that expects to resolve tickets outright rather than deflect a few easy ones and escalate the rest. A per-resolution price ties the vendor's revenue to the exact outcome the customer is buying, which is the number of tickets a human no longer has to touch. If Parahelp merely answered questions and punted on the hard cases, the model would starve. Choosing it is a way of saying the product stands or falls on whether it finishes the job.
It also aligns the two sides in a way seat licensing never has. Under per-seat pricing, a vendor benefits from a bigger support team; the more agents a company has to hire, the more seats it sells. Under per-resolution pricing, Parahelp benefits when a company needs fewer human touches, which is the same thing the customer wants. The incentive points at automation instead of away from it.
The prompt they gave away
There is a detail in Parahelp's history that tells you a lot about the team. At a point when many startups treat their prompts as trade secrets, Parahelp published a chunk of its own. On the company blog, the founders walked through how they structure the instructions that drive the agent, and shared their manager prompt along with roughly a quarter of their planning prompt.
The content of that post became widely referenced in the prompt engineering world for good reason. It describes a production prompt that runs to several pages, built out of clear role assignment, markdown and XML structure, and explicit step-by-step reasoning. The agent is told, plainly, that it is a manager of a customer service agent, which gives the model a stable identity to reason from. The planning logic breaks a big job into a sequence of smaller tasks and uses code-like conditional blocks, on the theory that a model trained heavily on code follows structured, code-shaped instructions more reliably than loose prose.
Giving that away looks counterintuitive until you notice what Parahelp did not give away. The prompt is the visible tip of the product. The parts that are genuinely hard to copy are the integrations into a customer's messy real systems, the accumulated procedures for handling edge cases across dozens of companies, the routing that decides when to act and when to escalate, and the operational track record that makes a support leader comfortable letting software close tickets unsupervised. Publishing the prompt cost little and signaled a great deal about the team's confidence in the harder work beneath it.
Who is using it, and who is backing it
Support automation is a category where reference customers carry unusual weight, because no support leader wants to be the first to let an agent answer real tickets. Parahelp's customer list is made up of exactly the sort of companies whose own users are demanding and technical. It is live with Perplexity, Replit, Bolt, Framer, HeyGen, and Photoroom, among others. These are fast-growing software companies whose support volume scales with their user base and whose users notice immediately when an answer is wrong. The company reports that it has not lost a customer so far, which is a meaningful signal in a business where a tool that fails quietly still gets ripped out fast.
The financing tracks the traction. Parahelp came out of Y Combinator's Summer 2024 batch and, within roughly thirteen months of launching, raised a $3.2 million seed and an $18 million Series A. The Series A was led by Alt Capital, the fund started by Jack Altman, with participation from Y Combinator, Perplexity's fund, Hidden Capital, ByFounders, and others. It is also a portfolio company of Orange Collective, the fund run by Y Combinator alumni that invests alongside the accelerator. Raising a seed and a Series A that close together is usually a sign that early customers were expanding rather than churning, which is the pattern investors look for underneath the headline numbers.
Founders who have been building together since high school
Parahelp was founded by Anker Ryhl and Mads Liechti, and their partnership goes back much further than the company. The two are childhood friends who started building software together as teenagers, shipping consumer apps while they were still in high school. Anker began programming at thirteen and started his first company not long after.
That history is more relevant than the usual founder-bio trivia. Support automation is a product that lives or dies on relentless attention to edge cases, and a pair of founders who have been writing software together for a decade tends to move fast and stay aligned in exactly the way that grind rewards. The decision to publish their prompt engineering, the willingness to price on the outcome rather than the seat, and the choice to build a system that acts rather than one that only answers all read like the instincts of people who have shipped enough real software to know where the hard part actually is.
Why this became buildable
The reason a company like Parahelp can exist now, and could not have a few years ago, comes down to two capabilities maturing at once. Reading improved first. A model can take a rambling support ticket, cross-reference it against a knowledge base and a customer record, and correctly work out what is being asked, including the cases where the customer describes their problem badly. Acting improved second. The current generation of agentic systems can take that understanding, choose the right tool, and carry out a multi-step task with enough reliability to be trusted with a real customer account.
Support is close to an ideal place for those two capabilities to meet. The work is high volume and repetitive enough to be worth automating, structured enough that a model can learn the procedures, and consequential enough that finishing a ticket has clear value. It also has a built-in safety valve: when the agent is unsure, the right move is simply to hand off to a person, so the failure mode is a human doing the work rather than a customer getting a wrong answer.
Parahelp is a bet that support is about to stop being a headcount problem. For decades, the only way to handle more tickets was to hire more people to handle them, which made support a cost center that grew in lockstep with the customer base. If an agent can resolve the bulk of tickets end to end and escalate the rest with good judgment, that link breaks, and a support organization starts to scale with software instead of with hiring. The companies that get there first will not just spend less answering their customers. They will actually close the tickets they used to leave open.