Questions, answered.

AI is software that can help read, write, summarize, classify, reason over patterns, and suggest next steps. It is useful, but it is not magic and it is not automatically right.

In Sociail, AI is meant to help inside shared work. The important part is not only the model answer; it is the room context, the people involved, the approval path, and the record of what happened.

An AI model is the underlying engine that turns input into output: for example, answering a question, drafting text, extracting details, or comparing information.

Sociail is not just a model wrapper. The product is the shared workspace around the model: roles, context, memory boundaries, approvals, receipts, and support.

An AI agent is an AI system with a role, context, instructions, and sometimes tools it can use to take steps toward a goal.

Sociail uses the friendlier phrase AI teammate when the agent is visible in the room, has a clear role, works near people, and stays bounded by approvals and trust controls.

Human in the loop, often shortened to HITL, means a person stays involved where judgment, review, approval, correction, or accountability matters.

In Sociail, that means consequential AI-assisted work should have visible ownership, review states, and approval paths instead of hidden automation that quietly crosses a boundary.

Context is the surrounding information that helps AI or a person understand what is going on: the room, the people, the goal, recent decisions, relevant artifacts, constraints, and what has already been tried.

A lot of AI frustration comes from missing context. Sociail is built around shared context so people and AI teammates can work from the same visible starting point instead of everyone rebuilding the situation alone.

A prompt is the instruction, question, or request you give to AI. It can be as simple as “summarize this” or as specific as “draft a follow-up using these three decisions and keep the tone direct.”

Sociail should reduce the need for perfect prompting because the room already carries useful context, roles, artifacts, and boundaries.

An AI teammate is Sociail’s human-friendly term for AI help with a visible role, name, context, boundaries, and expected kind of help.

The word teammate does not mean the AI is a person. It means the AI works in the same shared room, close enough to the work that humans can see, correct, approve, or reject what it does.

AI memory means selected information can carry forward so the same work does not have to be explained from scratch every time.

Good memory should be visible, scoped, correctable, and revocable. In Sociail, memory is treated as part of the trust model, not as hidden background learning.

A hallucination is when AI gives an answer that sounds confident but is wrong, unsupported, or made up.

The practical answer is not to pretend hallucinations never happen. Sociail is designed to keep sources, approvals, receipts, and human review close to important work so claims can be checked before they become decisions.

A receipt is a visible record of meaningful AI-assisted work: what happened, what context was used, what was produced, and what still needs human review or approval.

Receipts make AI work easier to inspect later. They help a team trust the process without treating the model response as a black box.

Sociail is request-led during Early Access. Start from the Early Access page or the persona page that best matches your workflow, then tell us what you want to prove in the first room.

A human reviews every request. We prioritize teams where a shared AI room can be useful, supported, and tested against a real workflow.

Yes. The current path is request-led. We review fit, open the right workspace path, and keep the trial or pilot scoped to a real workflow instead of a generic sandbox.

Pro Trial, Pro, Pro Plus, Teams, and Enterprise paths are explained on Pricing. Pro Plus, Teams, and Enterprise remain request-led while Early Access is being tuned.

Approved teams are onboarded selectively as fit and support capacity allow. We would rather land the first room well than rush a team into a weak setup.

If there is a timing constraint, say so in your request. We will be direct about whether the current window is a fit.

Because the first proof needs to be real. Sociail is not just another account to activate; it works best when a team brings a workflow, a decision owner, and a useful artifact to produce.

Request-led access lets us learn from serious teams while keeping product support, trust boundaries, and infrastructure costs under control.

A room is a shared workspace for a specific piece of work: a customer conversation, launch plan, hiring loop, monthly update, or operating decision.

Humans, AI teammates, context, artifacts, decisions, and receipts stay together so the work can be continued and reviewed instead of reconstructed from scattered tabs.

They are example Sociail AI teammate roles: Archer for context and research, Forge for build and workflow support, Muse for writing and communication, and Ledger for records and follow-through.

The point is not theatrical naming. It is role clarity. Teams trust AI participation more when the job, boundary, and expected output are visible. The names should make the work inspectable, not turn the roles into rigid product modules.

Real work does not divide into AI and non-AI. It divides into roles: research, drafting, review, engineering, records, follow-up, and decisions.

Named roles make the work easier to inspect. A teammate can ask what Archer found, what Ledger recorded, or what still needs human approval.

Private AI chats are useful for individual prompting. Sociail is designed for shared work: rooms, visible context, AI teammate roles, durable artifacts, and reviewable receipts.

If your team only needs occasional drafting help, a lighter tool may be enough. Sociail is for work that benefits from continuity, accountability, and shared context over time.

Sociail is designed for async preparation where the workflow allows it: pulling together context, drafting artifacts, preparing follow-ups, or organizing evidence for review.

That does not mean broad autonomous action. Consequential steps should remain bounded by visible approvals and human authority.

The public pricing ladder is Free during Early Access, Pro Trial, Pro at $20/month after fit is reviewed, and request-led Pro Plus, Teams, and Enterprise paths. Teams has a tentative 3-seat Early Access minimum.

Because Early Access is request-led, pricing and packaging are kept close to the workflow being tested rather than pushed through a one-size-fits-all checkout path. Packaging may evolve before general availability, but the direction is simple: teams pay for the human users in Sociail and the AI teammates they hire into the room.

Annual terms may be available as paid plans mature. During Early Access, the main question is whether Sociail creates enough proof in the first workflow to justify continuing.

If annual billing matters for procurement, mention it in the request and we will route it through the right review path.

Card-based billing is the default path for individual paid plans as they open. Team pilots and larger deployments can be reviewed for invoice-based billing.

Do not send card details through public forms. Use the pricing or help path and we will route payment conversations safely.

Yes. The product and packaging are designed to let teams start narrow and expand when proof is real.

During Early Access, plan changes are handled through support or pilot review so usage, team size, and AI costs stay visible before anyone is surprised.

Refund handling depends on the paid path and agreement in place. The operating principle is simple: no surprise billing and no adversarial cancellation path.

If Sociail is not working for your workflow, tell us quickly. Early Access is designed around honest proof, not lock-in.

Sociail uses encryption in transit and at rest, least-privilege operational access, event records, provider review, and scoped workspace controls.

Security coverage expands as Early Access surfaces mature. The Security page is the source of truth for the current public posture.

Sociail does not train general AI or foundation models on customer workspace content.

External provider routing is governed separately: provider routes must pass policy, retention, and provider no-training checks before customer context may be sent. Teams with stricter needs should raise them before onboarding.

AI can sound confident while being wrong, incomplete, outdated, or missing context. It can hallucinate facts, summarize poorly, misread intent, or suggest an action that needs human judgment.

Sociail’s posture is not “AI is always right.” The product is designed around shared context, visible sources where available, approvals, receipts, and human review for consequential work.

Not yet. Sociail is working toward SOC 2 Type II readiness, but the formal report is not currently issued.

We publish what is in place now and what is still working-toward so procurement teams can evaluate the actual posture instead of a marketing shortcut.

Sociail is GDPR-aware and privacy-forward during Early Access: we do not sell customer data, we support common privacy rights, and we review DPA, data-processing, residency, and procurement requirements before onboarding.

Sociail is currently US-hosted. If GDPR, UK GDPR, CCPA/CPRA, SCCs, or a signed DPA are gating requirements for your team, route that through Help before onboarding so we can confirm fit instead of over-promising.

The current Early Access posture is US-hosted. Data residency options are roadmap items, not current self-serve promises.

If residency is a hard requirement, mention it before onboarding so we can confirm whether Sociail is appropriate for your team right now.

Only through scoped integrations and workspace permissions that are explicitly connected. Sociail should not silently crawl unrelated systems.

The design goal is visible, revocable access: what context was used, what output was prepared, and what still needs human review.

Sociail collects what is needed to operate the service: account details, workspace content you provide, usage and diagnostic events, support requests, and payment records handled by payment providers when billing applies.

Public forms should not include passwords, card numbers, credentials, or sensitive workspace secrets.

No. Sociail does not sell customer data. The business model is product access and paid plans, not advertising or data resale.

Export and deletion paths are part of the control model. During Early Access, some requests may be routed through Help while self-serve controls mature.

Receipts and audit records may need special handling so teams can keep a reviewable history without retaining unnecessary content.

Yes. Account and workspace deletion requests can be routed through Help during Early Access while self-serve controls mature.

Some records may need retention handling for billing, fraud prevention, security, or legal obligations, but the operating posture is to avoid keeping unnecessary customer content.

Workspace owners can invite team members as part of onboarding and workspace setup. During Early Access, this may be coordinated with the Sociail team to keep the first room focused.

The best first setup is usually one real workflow, one accountable owner, and a small group of people who can judge whether the room helps.

The product architecture is designed for workspace-scoped context. Multiple workspace participation is a natural direction, but Early Access setup should stay focused on the first proof loop.

If your use case depends on multiple workspaces, include that in your request so we can evaluate fit before onboarding.

Sociail is built as a responsive web experience first. Mobile access is useful for review and lightweight participation, while heavier workflows are expected to start on desktop.

Native mobile apps are not the primary Early Access promise.

Integrations are being sequenced carefully around the workflows Sociail can support safely. Sociail is being built to work near the tools teams already use: email, calendar, chat, tickets, CRM, browser, and code workflows.

Early Access starts selectively through request-led design pilots, with approved context, prepared drafts, bounded actions, and visible human review before broader tool access. For a specific tool such as Google Drive, Slack, GitHub, Linear, Salesforce, or HubSpot, ask before onboarding; we will distinguish current support from roadmap intent.

Ready means available now for approved Early Access teams. Preview means working and visible, with rollout still limited. Pilot means available only in approved proof or design-partner workflows.

Planned means the direction is intentional, but it is not a current product promise. The labels are there so roadmap ambition does not blur into broad availability.

CRM workflows are a strong fit for Sociail’s shared-room model, but native CRM support should be treated as workflow-specific during Early Access.

If CRM update, handoff, or follow-up tracking is your main use case, tell us which CRM and what action needs to stay human-approved.

Not as a primary Early Access promise. Webhooks and automation-platform connectors are roadmap candidates once core room behavior, receipts, and approval paths are stable.

The web workspace targets current modern browsers. Browser Control is Chrome-first while the extension path matures.

If browser compatibility is a blocker for your team, include the target browser and operating system in your request.

Public component status is available on the Status page. During Early Access, we surface website, platform, and dependency health as the coverage matures.

AI latency can also depend on external model providers, which may have their own incidents.

A public API is not the main Early Access surface. Programmatic work is being sequenced through managed integrations, Browser Control, and workflow-specific pilots first.

If you are building an integration, describe the workflow and the approval boundary you need.

Not as a customer-controlled self-serve option today. Sociail uses reviewed provider routes and product-level guardrails so AI behavior stays consistent with the room model.

If your team has model, data retention, or compliance constraints, raise them before onboarding.

Sociail is founder-led by Mustafa Sualp, previously founder of AEFIS and part of the HelioCampus story after acquisition.

The team is intentionally small and AI-leveraged while the product is being shaped with close Early Access feedback.

Sociail is preparing for a deliberate funding path while staying focused on product proof, design partners, and paid Early Access motion.

Strategic investor conversations are welcome when they understand the category, the infrastructure depth, and the need for disciplined trust boundaries.

We hire slowly and deliberately. Open roles and general-interest notes belong on the Careers page.

If the work resonates and you do not see a role, send a concise note about what you would build and why Sociail’s bet matters to you.