Payments that act on intent.
An iMessage-native agent that watches your recurring subscriptions, decides whether each one deserves to renew, and executes that decision — autonomously — through a Prava payment mandate scoped to the exact merchant, amount, and billing cycle.
Intara is built for anyone paying for subscriptions they have forgotten about, outgrown, or been silently overcharged on. The average consumer maintains twelve recurring subscriptions and actively uses fewer than half. The tools that exist today — Rocket Money, Truebill, banking notifications — surface this problem. None of them fix it. The renew-or-cancel decision, and the negotiation with the merchant, still happens through a human.
Intara closes that gap. It monitors a user's recurring subscriptions, reasons about price, usage, and duplication using verified merchant intelligence, and acts on that judgment through Prava payment mandates enforced at the card-network level. The entire experience lives inside a single iMessage thread. No app install. No dashboard. No human clicking confirm every cycle.
Subscriptions are designed to renew by default, not by decision. Merchants benefit from that inertia — silent price increases, cancellation flows engineered to exhaust users, renewal emails designed to be ignored. Every existing tool in this space informs users about the problem. Intara is built to solve it.
Notification-based products have a structural limitation: they stop at the moment of decision. They tell you a subscription renewed. They do not prevent a bad renewal from happening. They tell you a price increased. They do not cancel or renegotiate on your behalf. The gap between awareness and action is where subscription spend leaks — and it is the gap Intara is designed to close.
Budgeting apps and banking notifications give users a rear-view mirror. By the time a renewal appears in a transaction feed, the money has already moved. Subscription trackers like Rocket Money improve on this with proactive alerts, but their cancellation product relies on human support agents calling merchants — a slow, expensive process that does not scale and cannot act autonomously.
The common failure mode across all existing tools is the same: they inform, then stop. They hand the decision back to the user and wait. Intara does not wait.
Intara is built around a single architectural insight: Prava's payment mandate — scoped to a specific merchant, capped at a specific amount, valid for a single billing cycle — is structurally shaped like a subscription renewal decision. A mandate is not issued until Intara's reasoning clears a renewal. If the renewal does not clear, no mandate is issued and the subscription is cancelled instead.
This is not a spending limit communicated to the merchant. It is a credential enforced at the card-network level. If a merchant attempts to charge above the cap, the payment token does not authorize it. The enforcement happens outside the application layer, which means it cannot be bypassed by a merchant, and it cannot be broken by a bug.
Intara adds a verified merchant intelligence layer through Senso — pricing history, cancellation difficulty, renegotiation success rates — so the reasoning is grounded in real data, not the model's training-time approximation of what a subscription costs.
trigger → detect price change → query Senso for verified merchant context → reason via OpenAI structured output → enforce ceiling deterministically in code → render Linq iMessage card → act: issue Prava mandate / execute cancellation / propose renegotiation → update the same card in place with the outcome
Three days before a subscription renews, Intara triggers a renewal check. It detects the current price, queries Senso for verified merchant intelligence, and passes both to the reasoning agent. The model returns a structured JSON decision — renew, renegotiate, or cancel — with a confidence score and a reasoning summary.
Before any payment mandate is issued, a deterministic ceiling guard runs in code. If the detected price exceeds the user's accepted ceiling, the decision is overridden to cancel regardless of what the model returned. The model reasons about whether a subscription is worth keeping. It never decides how much to authorize.
The outcome is delivered as an iMessage card. The card updates in place as Intara works — checking, deciding, acting — so the user sees a single conversation thread that evolves, not a log of separate messages.
Intara's primary interface is a Linq-powered iMessage thread. The agent sends structured cards at each stage of the renewal loop and updates the same card in place as state changes. Users interact through replies and taps — no app, no browser, no context switch.
A Postgres registry stores each subscription's merchant, price history, accepted ceiling, billing cycle, usage signal, and renewal date. The registry is the source of truth for every renewal decision and the foundation of the audit trail.
The reasoning agent is an OpenAI structured-output call constrained to a strict JSON schema: decision, reasoning_summary, and confidence. The system prompt enforces guardrails — the model is never asked to authorize an amount, only to evaluate whether a subscription deserves renewal. The ceiling enforcement that follows is deterministic and runs in code, separate from the model entirely.
Before each reasoning call, Intara queries Senso for verified merchant intelligence: cancellation difficulty, price-hike history, average market rate, renegotiation success signals. This context is injected into the OpenAI prompt and surfaced on the outcome card so users understand exactly why Intara made the decision it did.
Every renewal goes through a Prava mandate session. The user approves once with their passkey — creating a standing mandate scoped to that merchant, capped at their accepted ceiling. Subsequent same-price renewals within the cap charge automatically. The mandate is mirrored to a local ledger immediately on issuance. Every live mandate is user-visible and revocable with one tap.
Cancellations are executed through merchant-specific flows. For the current build, two demo merchants are supported through a real HTTP simulation, clearly disclosed in the submission. The orchestrator calls a real endpoint, handles the response, and marks the subscription cancelled in the registry before updating the card.
Every renewal check produces a decisions row linking the subscription, detected price, price-hike percentage, model reasoning, decision, mandate reference, and outcome. This table is user-visible and user-exportable. It is both the trust story for users and the evidence layer for judges — a complete, timestamped record of every dollar Intara touched.
Intara operates on the principle of least privilege at every layer.
Raw card data never enters the system. Prava holds the funding source and issues single-use, merchant-scoped payment tokens. Intara holds a mandate reference and an amount cap — nothing that can be reused, transferred, or abused if exfiltrated.
Every mandate is scoped to a single merchant and a single billing cycle. An over-cap charge attempt returns THRESHOLD_EXCEEDED at the card-network level — not a software check, not a database rule, a network-enforced rejection.
The ceiling guard is a pure, synchronous TypeScript function with no external dependencies. It runs after every model response, before any mandate call. It cannot time out, cannot fail, and cannot be bypassed. The model's judgment influences whether Intara attempts a renewal. It has no influence over the amount authorized.
Senso context enriches the reasoning prompt but never gates the payment flow. A Senso API failure degrades gracefully to a local fallback — the renewal decision still executes on the correct path.
Prava's mandate primitive is the architectural foundation of Intara, not a payment method appended at checkout. The mandate's three properties — merchant scope, amount ceiling, duration — map directly onto the three parameters of a subscription renewal decision: who is charging, how much they are allowed to charge, and for how long that authorization is valid.
No other payment infrastructure available to agents today offers this combination of properties enforced at the network level. A Stripe charge is a point-in-time event. A Prava mandate is a bounded, revocable, auditable permission — the correct primitive for an agent acting with standing financial authority on a human's behalf.
- Autonomous subscription renewal decisions grounded in usage, price history, and verified merchant intelligence
- Prava payment mandates enforced at the card-network level — not software limits
- Merchant-specific cancellation execution with a full confirmation trail
- Renegotiation proposals drafted and surfaced to the user for high-value subscriptions where retention discounts are likely
- Senso-powered merchant intelligence surfaced on every outcome card
- Native iMessage experience via Linq — no app install, no dashboard
- Complete audit trail of every decision, mandate, and outcome — user-visible and exportable
- Every live mandate revocable in one tap
intara/ ├── src/ │ ├── db/ │ │ ├── client.ts # Postgres connection pool │ │ ├── schema.sql # subscriptions, decisions, mandates │ │ └── seed.ts # three demo subscription scenarios │ ├── orchestrator/ │ │ ├── loop.ts # render → decide → act pipeline │ │ └── triggers.ts # manual and batch renewal triggers │ ├── reasoning/ │ │ ├── prompt.ts # OpenAI system prompt and JSON schema │ │ ├── ceiling-guard.ts # deterministic cap enforcement │ │ ├── openai-client.ts # structured-output reasoning call │ │ └── merchant-context.ts # Senso merchant intelligence queries │ ├── prava/ │ │ └── client.ts # mandate setup, charge, status, cancel │ ├── linq/ │ │ ├── client.ts # sendCard, updateCard, typing indicator │ │ └── cards.ts # card builder for all six states │ ├── merchants/ │ │ └── simulated/ │ │ ├── index.ts # cancellation flow client │ │ └── server.ts # mock merchant HTTP server │ ├── audit/ │ │ └── trail.ts # decision logging and audit queries │ └── demo.ts # full three-scenario demo runner ├── tests/ │ └── loop.e2e.test.ts ├── docs/ │ └── blueprint.md # full product and technical specification ├── codex.md # agent context file ├── .env.example └── README.md
- Node.js 20+
- TypeScript 5
- A Postgres database (Supabase recommended)
- API keys for Prava, Linq, OpenAI, and Senso
git clone https://github.com/phllp-tanstic/Intara.git
cd intara
npm installcp .env.example .envFill in the following:
DATABASE_URL= PRAVA_SECRET_KEY= PRAVA_PUBLISHABLE_KEY= PRAVA_API_BASE=https://sandbox.api.prava.space LINQ_API_KEY= LINQ_FROM_NUMBER= LINQ_API_BASE=https://api.linqapp.com/api/partner/v3 LINQ_TEST_CHAT_ID= LINQ_TEST_RECIPIENT= OPENAI_API_KEY= SENSO_API_KEY= DEMO_USER_EMAIL=
Apply the schema to your Postgres instance:
# Via Supabase SQL editor or psql:
psql $DATABASE_URL -f src/db/schema.sqlSeed the three demo subscriptions:
npm run seedStart the simulated merchant server in one terminal:
npm run simRun all three scenarios in sequence in a second terminal:
npm run demonpm testnpm run buildIntara is a stateless orchestration service. Each renewal check is an isolated event: load the subscription, query context, reason, act, log the outcome. There is no long-running process holding state between renewals — the database is the only persistent layer.
The orchestrator pipeline has a strict execution order that cannot be violated:
- Load subscription from Postgres
- Query Senso for merchant context
- Send initial card via Linq
- Call OpenAI reasoning agent
- Run ceiling guard — synchronous, no external calls
- Log decision to audit trail
- Act: issue Prava mandate, execute cancellation, or propose renegotiation
- Update Linq card in place with outcome
Steps 5 and 6 always execute in this order regardless of the model's output. The ceiling guard is not a model guardrail — it is a code-level enforcement that runs unconditionally.
Least privilege. Intara holds the minimum data needed to act. Card data stays with Prava. Inbox data is never requested. Usage signals are self-reported or inferred, not scraped.
Deterministic enforcement. The price ceiling is enforced in code, not by the model. A model that reasons incorrectly about whether a subscription is worth keeping cannot cause an unauthorized charge.
Human in the loop where it matters. The first mandate for any subscription requires the user's explicit passkey approval. Subsequent same-price renewals within the approved ceiling can execute automatically. Trust is established once and extended incrementally.
Transparent reasoning. Every decision is logged with the model's stated rationale, the detected price, the price-hike percentage, and the outcome. The audit trail is not an internal log — it is a user-facing asset.
Graceful degradation. Senso failures fall back to local merchant data. Linq update failures are logged without blocking the payment flow. Every external dependency has an explicit failure path.
Honest disclosure. Merchant cancellation flows in this build use two simulated endpoints, clearly labeled. Discovery is seeded rather than parsed from a live inbox or bank feed. The architecture supports both; the hackathon scope does not require both.
Three-scenario demo covering the core decision branches: price-hike cancellation via ceiling guard, unused-service cancellation via OpenAI reasoning, and clean renewal via Prava mandate. Full audit trail. Linq iMessage interface. Senso merchant intelligence on every outcome card.
Real subscription discovery via forwarded receipts and scoped bank-feed integration. Webhook-based Prava mandate confirmation replacing polling. Expanded simulated merchant coverage to the top twenty most-cancelled subscription categories.
Real merchant cancellation API integrations as they become available through Visa's Trusted Agent Protocol and equivalent frameworks. Renegotiation execution — drafting and sending retention requests autonomously, not just proposing them.
Cross-user price-hike detection: when enough users route a merchant through Intara, aggregate price signals become a real-time early-warning system. Duplicate-service detection expands beyond hardcoded pairs to semantic similarity across subscription categories.
B2B variant for SMB SaaS spend management — the same mandate-as-policy mechanism applied to team purchasing authority. Integration with accounting systems for verified savings reporting. Monetization on verified savings events aligns Intara's revenue directly with user outcomes.
All application logic was written during the 48-hour hackathon window. Pre-hackathon work was limited to:
- Repository scaffold with empty module boundaries and schema
- Three seeded subscription scenarios in Supabase
.env.exampleandtsconfig.jsonconfiguration
Everything in src/ — the orchestrator pipeline, reasoning agent, Prava client, Linq client, card builder, Senso integration, audit trail, and demo runner — was implemented during the hackathon.
Contributions are welcome. Open an issue before submitting a pull request for significant changes. All PRs require a passing build and at least one test covering the changed behavior.
MIT
Intara — Payments that act on intent.