Eragon is betting enterprise software collapses into a prompt

Eragon, a startup founded last August by former Salesforce product lead Josh Sirota, has raised $12 million at a $100 million post-money valuation behind a blunt thesis: a lot of enterprise software no longer needs to look like traditional software.

The product pitch is a prompt-first operating layer for work. Instead of moving through CRM screens, finance tools, dashboards, and onboarding systems, a user types the task. Agents call the relevant tools, query the right datasets, and run the workflow.

Plenty of companies are pitching some version of that now. Eragon stands out because of where it wants to sit in the stack. The company is aiming for a layer that spans SaaS tools, runs inside the customer’s cloud, and owns enough of the model stack to tune behavior around a company’s data and policies.

That’s a much bigger swing than an AI assistant bolted onto one product.

Why this moment makes sense

The timing matches a broader shift. Nvidia used GTC to talk openly about Agentic-as-a-Service, and Jensen Huang put the point plainly: every SaaS company is moving in that direction.

There’s marketing baked into that, obviously. Still, the core argument holds up. Enterprise buyers have already seen copilots from Microsoft, Salesforce, Google, AWS, and everyone else. Those tools work reasonably well inside one product boundary. They get shakier when a task spans six systems and drags in permissions, approvals, data checks, and audit logs.

That’s the opening Eragon is chasing.

For technical teams, this matters because cross-system orchestration has always been the ugly part of enterprise software. The interface looked polished. The real work lived in glue code, Zapier flows, internal admin panels, and brittle scripts that nobody wants to touch now. A prompt-first interface tries to hide that complexity without giving up control of it.

Promising idea. Risky one.

What Eragon is building

Eragon says it post-trains open models such as Qwen and Kimi on customer data, then deploys those models inside the customer’s own cloud environment. It connects to email, business datasets, and operational systems, and supports workflows such as provisioning users and resources from a plain-English request.

That deployment choice matters more than the prompt box.

Running inside the customer’s VPC gives security teams a reason to take the meeting. Data residency, compliance, and egress issues still exist, but they become tractable. In regulated environments, that’s often the line between an interesting demo and a real pilot.

The other notable claim is ownership of the model weights. Early customer comments in the reporting lean on that point, and fairly so. If a company fine-tunes a model on years of internal process data, support history, sales workflows, and operational edge cases, that model starts to look like a real internal asset. It still drifts. It still needs evals and upgrades. But it may be cheaper to run, easier to govern, and harder for a competitor to copy than a thin wrapper over a public API.

It also creates real operational overhead. If you own the model, you own the maintenance.

The stack under the product

You can make a decent guess at Eragon’s system design from the product shape, even without a published reference architecture.

Start with the models. Post-training open weights like Qwen or Kimi usually implies some combination of full fine-tuning where budgets allow, and more often LoRA or QLoRA adapters to keep cost and iteration time under control. Inference at enterprise scale likely lands on something like vLLM, Triton, or TensorRT-LLM, because GPU waste gets expensive fast.

Then there’s orchestration. A product like this lives or dies on tool calling. The model is only one part of the system. The harder problem is turning intent into reliable multi-step execution across email, CRM, ticketing, finance, IAM, and data warehouses. That usually means function calling, OpenAPI-described tools, policy checks before writes, and some kind of graph controller or router to manage state. LangGraph-style flow control fits well because enterprise tasks branch, pause for approvals, retry, and fail in annoying ways.

Retrieval is another obvious piece. If the system is expected to reason over internal docs, historical records, and company-specific workflows, retrieval needs metadata filtering and access controls that map to real permissions. A plain vector index won’t cut it. If ABAC or RBAC checks happen only after retrieval in the application layer, that’s already a bad security model.

Observability is where a lot of agent demos break once they hit production. Enterprises need traces for prompts, tool calls, approvals, failures, costs, and side effects. OpenTelemetry fits naturally here. So do immutable audit logs, prompt redaction, and DLP scanning on both inputs and traces. If an agent can touch ERP, billing, or identity systems, basic logging is nowhere near enough.

The hard part is permissions

Eragon’s strongest selling point is also where these systems can fail fastest.

A natural-language interface compresses dozens of workflows into one entry point. That’s useful. It also hides risk. Buttons in enterprise software usually exist for a reason. They narrow scope, encode assumptions, and limit blast radius. If a prompt replaces that surface, the policy layer underneath has to be serious.

For real deployments, that means:

• separate read and write scopes for each tool
• least-privilege IAM roles by default
• human approval for money movement, vendor onboarding, access grants, and customer-impacting changes
• immutable logs for every action, including request, response hash, actor, and approval state
• hard controls around external calls, prompt injection, and data exfiltration

This is where a lot of agent platform rhetoric starts to thin out. The demo is easy to picture. “Create a customer workspace, invite the team, provision analytics access, and send the welcome email.” Fine. Production raises uglier questions. Who approved the workspace template? Which IAM role got attached? What happened when Salesforce had stale account metadata? Did the invoice matcher grab the wrong PO because OCR invented a digit?

Those aren’t edge cases. They’re the work.

Why a horizontal layer could win

The incumbents still have distribution and data gravity. Microsoft can wire Copilot into tools people already use. Salesforce can sell AI inside the CRM it already owns. AWS can make the infrastructure case from the bottom up.

Their products still tend to inherit the boundaries of their own suites.

That leaves room for a horizontal control layer. A lot of real work happens between systems, not inside one. Sales ops, RevOps, IT onboarding, invoice approval, support escalation, customer provisioning, NOC triage. These are process chains. Someone has to coordinate identity, system access, business rules, and data pulls across products that were never designed to share one execution model.

A startup has some advantage here because it doesn’t need to defend an old UI. It can build around prompts, tools, policy engines, and model routing from the start.

The execution risk is brutal, though. A cross-system orchestrator is hard to build. One that security teams trust is harder. One that doesn’t collapse into expensive prompt spaghetti is harder again.

What technical buyers should check

The fundraising story is one thing. The engineering checklist matters more.

If you’re looking at Eragon or anything similar, start with narrow workflows. Good candidates have real value, clear boundaries, and obvious approval steps. Lead triage. Invoice matching. Support escalation routing. Access onboarding. Pipeline risk summaries with write-back only after review.

Then ask boring questions. Those are the useful ones.

Model and deployment

• Can you swap models without rewriting the app layer?
• Are adapters versioned and tied to eval results?
• What’s the latency budget for multi-step tasks?
• How do upgrades work when a better base model arrives?

Security and governance

• Does retrieval enforce access control before context assembly?
• Are traces redacted?
• How are service accounts scoped?
• Can an agent write to production systems without an explicit approval state?

Reliability

• Is there shadow mode for new workflows?
• Are there golden datasets and task-level evals?
• Can deterministic substeps be cached?
• Is there a replayable run viewer for failures?

Cost

• What’s the per-task inference profile?
• Is batching in place?
• Are there team-level cost caps and alerting?
• Do you have a path to distill or shrink models for common tasks?

These questions sound mundane because they are mundane. That’s also why they matter. If a vendor gets slippery here, the product probably isn’t ready.

The part worth taking seriously

Sirota’s line that “software is dead” is too neat. Enterprise software is alive and staying form-heavy and approval-heavy for a long time, mostly because accountability matters more than elegance in regulated workflows.

Still, the interface layer is changing quickly.

A prompt is becoming a credible front door for work, especially when the task spans multiple systems and the old interface was mostly ceremony wrapped around an API call and a few policy checks. The companies that win here won’t be the ones with the slickest chat box. They’ll be the ones that make agent execution auditable, governable, and cheap enough to replace old workflow glue.

Eragon is early, well-funded, and pointed at a real pain point. That’s enough reason to watch it. The hard part comes after the prompt.