Skip to main content
Xintel turns a public X account into a structured intelligence profile that evolves over time. It draws on the account’s full public surface — profile and org affiliation, every post format (originals, replies, quotes, reposts, long-form notes, Articles), inbound mentions, X’s own topic/entity annotations on that content, expanded outbound links, and a network graph derived locally from all of it combined — measures it in depth, and uses AI to explain what the numbers mean. Then it repeats the process, so you see how the account is shifting, not just how it looks today. The same profile also models how the account writes, so you can draft in a voice that matches it instead of a generic one. That is the product in one line: measure an account, explain it, track how it changes, and write like it.

​
What you learn from a handle

From that full public surface, Xintel builds a picture you can act on — not a screenshot of a feed.
  • How the account performs — what lands, what doesn’t, and how engagement and amplification actually distribute across posts.
  • How it posts — bursty or steady, which hours and weekdays matter, where the long silences are.
  • What it is made of — originals vs replies vs quotes vs reposts; media and links; language mix.
  • Who it talks to — the accounts it mentions, quotes, and replies to most, derived from the posts themselves.
  • What it cares about — recurring subjects and the domains it links out to.
  • How it sounds — a register: cadence, diction, stance, rhetoric, texture, and the devices it leans on.
None of the quantitative layer is guessed by a model. It is computed from the gathered data. The AI’s job is interpretation — what the numbers mean, where the contradictions are, and how the story is changing.

​
Working in the app

Intel has three tabs that form one loop: Add a handle in Others and Xintel gathers it: profile, outbound posts, inbound mentions, then a local network graph. You do not need to connect X to analyze a public account. Connecting X is optional and additive — it unlocks your own accounts, publishing, richer connection fields, and likes/bookmarks on the You tab. See OAuth is additive. Gathered data stays encrypted on your device. When the deployment has a shared library configured, the public parts of a gather can be published so others on the same deployment can pull them — and so agents can buy finished reports. Device-private fields (cost, watch state, per-account synthesis settings) never leave your machine. Day-to-day use is covered in Using the app. Setup and billing live in Connections & billing.

​
Reports you can trust over time

A report is an immutable snapshot with two layers:
  • Analytics — computed in code from the corpus you hold: fundamentals, composition, engagement, cadence, topics, information diet, network, and style features.
  • Narrative — the AI’s reading of those facts: executive summary, strategic assessment, themes, a voice/register profile, audience read, contradictions, notable posts, engagement hooks, and conclusions.
Once written, a report’s numbers do not drift when you gather more posts later. Each new report is appended. From the second report onward it also carries a change summary — measured volume added, metric shifts, composition and cadence drift, topics emerging or fading, and accounts entering or leaving the network — plus a short narrative of what that change means. Across several reports, a handle becomes a time series. The register from those reports is what lets the Post composer draft in a matching voice. The sections below explain how that works end to end: how a profile is built, what is measured versus interpreted, how history stays honest, where data lives, how access is paid for, and what people versus agents actually receive.

​
How a profile is built

There is no background crawler. Work is orchestrated in the client when you gather, refresh, watch a target, or generate a report.
  1. Resolve auth. If you are connected to X for that context, gathers use your OAuth user token through the app’s proxy. Otherwise public reads use the deployment’s app bearer on an allowlisted path — username lookup, user by id, tweets, mentions, affiliates, and tweet-by-ids. No writes, DMs, bookmarks, or /users/me on the public path.
  2. Pull the corpus. Profile first, then outbound posts and inbound mentions in parallel. Posts are incremental when you already hold own posts (since_id from the max own post id, so empty incremental pulls are avoided). A mentions failure is non-fatal: the timeline still lands. Self gathers additionally pull likes and bookmarks when OAuth is available.
  3. Normalize and derive edges. Raw X payloads become internal profile and post shapes. Network edges (mention / reply / quote / retweet weights) are derived locally from the post graph — free, deterministic, no extra API call.
  4. Persist. The dossier updates the on-device encrypted store and a client cost meter. If shared library KV is configured, a best-effort push publishes the public corpus (profile, posts, edges, report history). Self data never enters that shared bucket.
  5. Report (separate step). Generation uses the stored corpus. It may re-hydrate X Articles before synthesis; it does not re-run a full gather. Analytics are computed, optional deltas against the prior snapshot are computed, then Venice streams a structured narrative grounded in packed post transcript plus the analytics JSON.
X data comes through the X API. Inference runs on Venice AI. Xintel does not re-document either — follow those links for their specifics.

​
What is computed vs synthesized

This split is the trust model. Computed in code (ReportAnalytics and style features) — exact and repeatable for the same corpus:
  • Fundamentals (account age, velocity, follower ratios, listed count, pinned post)
  • Composition (kind mix, media/link rates, language mix) and scope (own vs inbound counts)
  • Engagement distributions and rates (impressions, likes, reposts, replies, quotes, bookmarks; engagement / bookmark / amplification rates; best and worst posts; performance by kind)
  • Cadence (burst vs steady, variance, hourly and weekday histograms, peak windows, longest gap)
  • Topics and entities from context annotations; information diet from expanded link hosts
  • Network top-mentioned / quoted / replied
  • Deterministic style features used as inputs to register and compose — never invented by the model
Synthesized by Venice (ReportNarrative) — interpretation grounded in those frozen facts and a packed transcript:
  • Executive summary and strategic assessment
  • Weighted themes with evidence
  • Register sheet (cadence, diction, stance, rhetoric, texture, format flex, constraints) plus devices
  • Narrative arcs, audience read, contradictions, notable posts, engagement hooks, analyst conclusions
The model does not invent the metric layer. It explains it. Model, temperature, context cap, and which prior reports to include as context are configurable per target when you generate.

​
Snapshots, deltas, and gates

Each report is an IntelReportSnapshot: a self-contained artifact with id, creation time, model and synthesis settings, meta (post count, date range, post ids analyzed, token cost), frozen analytics, narrative, optional changeSummary, and a pointer to the previous report. Because snapshots are append-only, historical analytics stay frozen even if live post metrics later change. The change summary on later reports is measured first — volume added (own and inbound), date ranges of new material, metric shifts with percent deltas, composition and cadence drift lines, emerging / fading / sustained topics, network appeared / disappeared — then given a short narrative interpretation. The baseline (first) report has no change summary. A deliberate gate prevents stale churn: you must refresh the profile after the last report before generating another, so consecutive narratives are not copies of the same stale state.

​
Local corpus, shared library, and privacy

For people, the source of truth is the device. Full dossiers live in encrypted browser storage bound to that device. Purging and privacy controls live in the app settings. The shared library (Upstash Redis / KV when configured) is optional and best-effort. Without it, local use still works; the shelf and agent inventory are simply empty. With it:
  • Published bundles include the public corpus only. Cost meters, watch flags, and synthesis settings are stripped before push.
  • Pulls merge last-write-wins by gather time. Report histories are unioned by report id, so a thinner push cannot erase reports another client already contributed.
  • The library is what agents browse and buy from — but only after a human (or first-party sync) has gathered and generated into it.
Self / You-tab data stays private by design. Disconnecting X does not wipe the intel cache; that is a separate privacy action.

​
Access modes and cost shape

People use the app three ways, and can layer X on top:
  • Alpha (free) — the deployment’s shared Venice key fronts inference while Alpha is on; short-lived app token; no login or wallet.
  • BYOK — your own Venice key (and optionally your own X developer credentials); bills your account.
  • Credits — prepaid USDC over SIWE, debited for paid in-app actions.
X OAuth never gates Alpha or BYOK. Agents never use the human Credits session — see Alpha (free) / BYOK / x402. Public gathers burn the deployment’s X owner key on allowlisted reads; owner-key routes are protected so anonymous clients cannot drain them. The in-app cost meter estimates gather spend for the UI ledger; server floors and x402 debiting are separate. Full setup: Connections & billing.

​
What people get, and what agents buy

One report library, two interfaces — covered in depth in Humans vs agents. People work in the app with the full corpus: profiles, feeds, networks, report history, generation, compose, and dashboards. That is the high-resolution product. Agents use plain HTTP. Browsing is free: the shared handle list and per-handle report menus (ids, dates, model, post counts). Paying with x402 unlocks report bodies — IntelReportSnapshot[] — at a default of $0.01 USDC per report (unit × N for a selection). A report body is not a profile export. It draws on the account’s full public surface — profile and org affiliation, every post format (originals, replies, quotes, reposts, long-form notes, Articles), inbound mentions, X’s own topic/entity annotations, expanded outbound links, and a network graph derived locally from all of it — and is frozen into a dossier an agent can reason over directly, with no gather, no metric computation, and no synthesis pass of its own:
  • Computed facts — engagement distribution (best/worst posts, percentile thresholds, rate by post type), cadence (burst vs steady, hourly/weekday rhythm, longest silences), composition, topics, outbound domains, and a network derived from the post graph itself — who the account actually mentions, quotes, and replies to, not who it follows.
  • Grounded narrative — executive summary, strategic assessment, weighted themes with cited evidence, a voice/register profile detailed enough to draft convincingly in it, narrative arcs, audience read, contradictions, notable posts, engagement hooks, analyst conclusions.
  • Change summary, from the second report on a handle — measured volume added, metric shifts with percent deltas, topics emerging / fading / sustained, accounts entering or leaving the network, and a narrative of what the shift means. This is what turns a one-off snapshot into a time series an agent can track a target through, not just describe it once.
Agents never receive profile, posts, or network edges directly, and cannot generate new reports through this API — they buy finished intelligence that a team already chose to publish. But what they buy is the analysis, not a redacted version of the raw data. The complete agent purchase flow is on Buy a report; the default route is the CLI. Schema and parameters live in Reports; unit economics in Pricing.

​
Names

Xintel is the product. AiSpace is the team that builds it. Venice, X, and Cursor are the tools underneath — dependencies, not co-brands.

​
AiSpace

Xintel is an AiSpace product. The app and these docs share the aispace.bot domain.