HALO workflow-first sourcing: live products

Status: complete (live-product lane + user-requested GitHub discovery addendum) Research date: 2026-08-29 Owner: KELLMAN-WEB Scope: live product sites and first-party documentation, plus a separately labelled GitHub repository discovery addendum requested during the campaign; repo/ remains read-only and no repository code was copied into HALO.

Executive verdict

The clarified target changes the ranking: HALO should be compared first with products that already provide a multi-persona shell, extensible data model, permissions, modules, and automation. There is still no single creator-agency product that is a safe replacement for HALO's existing creator records, Drive taxonomy, customs flow, referral logic, and gamification. The most useful products fall into four layers:

1. System-class candidates: Twenty is the strongest practical open platform to pilot

against HALO's React/TypeScript shape; Salesforce/Agentforce is the enterprise-grade reference architecture; Odoo/ERPNext are the ERP re-platform options; Airtable Omni, NocoBase, and Directus are modular data/workflow platforms; SuiteDash is the most relevant white-label portal; Mattermost/Zulip/Discord are chatter-workspace sidecars.

1. A workflow benchmark / selective pilot: Influs is the clearest small-agency

reference for a daily command centre, deliverables, approvals, creator portal, and margin visibility. Influno is the more ambitious money-and-trust benchmark, but its public evidence is currently a product page rather than a documentation surface.

1. Bounded capability integrations: Granola for meeting memory, Frame.io or Filestage

for asset review, Stripe Connect/Trolley/Deel for money and tax rails, 1Password for secrets, MaestroQA for scorecards, and n8n for guarded automation.

1. Pattern donors, not embedded code: AFFiNE for linked operational knowledge,

Attio for relationship/context modeling, Linear for issue/cycle semantics, and Vanta for evidence/control workflows.

The urgent security conclusion remains separate from product fit: HALO's plaintext credential vault should be replaced or isolated with a dedicated secrets product before any workflow expansion. The product candidate with the clearest fit is 1Password Business; Vaultwarden/Passbolt were not re-researched in this web lane.

The GitHub correction is now explicit. A high-throughput repository search pass used 67 workflow/category query strings and returned 1,889 result rows representing 1,781 unique repositories before screening. Thirty repositories were then promoted for repository README/license review and gh api metadata verification; the rest were left as discovery noise or follow-up backlog. This is a candidate-generation corpus, not a claim that HALO should adopt 30 codebases. The strongest new codebase signals are erxes, Open Mercato, Huly, Operately, Comp AI CRM, ERPNext/Odoo, NocoBase/Directus, ITFlow, and the creator-specific InfluenceX/InfluenceFlow projects. The product decision remains workflow-first: buy/integrate/embed/study each bounded capability, and re-platform only when one platform can own an entire journey without creating dual truth.

Claims below are vendor/product claims supported by a direct official URL. “High” confidence means the capability and boundary were explicit in a first-party product or documentation page reviewed on 2026-08-29. “Medium” means the capability is explicit but the public evidence is primarily a marketing page, the product is young/demo-led, or the exact integration surface needs a live trial. No external page instructions were treated as authoritative.

Search vocabulary reconstructed from the eight operator journeys

System-class candidate families

These candidates were evaluated as possible operating systems, not as feature donors. For each, the decision is explicit: substantial adoption, sidecar/module behind a HALO identity/navigation layer, bounded pattern study, or rejection because it would create a second irreconcilable operating system. “Live” here means an accessible first-party product or documentation surface reviewed on 2026-08-29; it does not mean a vendor's marketing claims have been independently load-tested.

S1. Twenty — extensible open-source CRM platform

Decision: sidecar pilot first; possible substantial adoption only after a deliberate re-platform decision.

Twenty is the closest system-class match to HALO's current technical shape. Its official docs describe custom objects and fields, relationships, views and pipelines, workflows, AI agents, dashboards, notes/tasks, CSV/API migration, webhooks, and role-based permissions. It also advertises cloud or self-hosting and a TypeScript/React extension path. See What is Twenty ↗, Twenty's documentation ↗, the extension/product overview ↗, and Twenty's terms ↗.

HALO fit: pilot Creator, Brand, Campaign, Deliverable, Staff, and Referral Partner objects; connect relationships; give owner/manager/chatter/creator/referral personas different role and field access; test AI actions against approved records. Twenty's objects/views/workflows/agents are closer to the requested multi-module shell than a collection of UI components.

Boundary / conflict: self-hosting Twenty would introduce a second datastore, auth system, workflow runtime, and UI shell beside Convex/React. Embedding Twenty's UI behind HALO navigation may still leave two authorities. Do not sync every record. Choose one bounded relationship module or explicitly decide to re-platform; otherwise study its object/permission/app primitives and keep HALO authoritative.

License/provenance: Twenty's official terms say the source is mostly AGPLv3, with certain MIT packages and commercial files; the repository license includes an application exception for applications interacting through published interfaces, but modifying Twenty itself remains subject to AGPL obligations. This is not a generic MIT drop-in. The verified repository metadata is:

These values came from gh api repos/twentyhq/twenty; its root LICENSE ↗ was inspected after GitHub returned NOASSERTION. Stack / freshness: official docs describe a self-hostable Docker/Kubernetes path, GraphQL/REST APIs, webhooks, and TypeScript extension SDKs; docs were live on 2026-08-29 and the repository was pushed the same day. Confidence: High for system-class primitives and license boundary; Medium for production maturity and migration effort.

S2. Attio — relationship operating system with AI actions

Decision: sidecar for relationship memory or pattern study; do not adopt as a second HALO-wide system of record.

Attio is now evaluated as a system-class CRM, not merely as a notes tool. Its official help center exposes custom objects/relationships, email and calendar sync, notes, tasks, communication and call intelligence, workflows, reporting, API/SDK, and MCP. Its MCP documentation explicitly allows permissioned AI search, record/note/task updates, and email/meeting search. See Attio 101 ↗, Attio MCP ↗, and Attio's developer platform ↗.

HALO fit: a strong owner/manager relationship spine: Creator, Brand, Campaign, and Promise objects with linked meeting/email context, next-action tasks, and an AI assistant that can operate within existing permissions. It is a credible sidecar if HALO keeps creator money, documents, KYC, content, and portal authority elsewhere.

Boundary / conflict: Attio's GTM orientation and vendor datastore/auth would become a second operating system if it owns the same creators and campaigns as HALO. If piloted, choose one relationship slice and define the canonical ID, sync direction, retention, and offboarding/export before connecting AI write actions. Proprietary SaaS; no code reuse. Official help/docs were live 2026-08-29. Confidence: High for multi-object relationship/AI primitives; Medium for HALO-wide fit.

S3. Salesforce Customer 360 + Agentforce — enterprise reference architecture

Decision: study/reference architecture; reject as a near-term HALO re-platform and do not introduce it as an unbounded sidecar.

Salesforce's official Agentforce platform page describes a unified platform spanning applications, data/metadata, agents, MuleSoft integration/automation, security, analytics, custom apps/portals, and an ecosystem. Agentforce supports RAG over structured and unstructured data, multi-step workflows, MCP/A2A, observability, and governed actions. See Agentforce 360 Platform ↗, Customer 360 applications ↗, and Agentforce security/shared responsibility ↗.

HALO fit: Salesforce is the benchmark for how multiple personas, object-level and field-level access, portals, workflows, analytics, and AI agents can live in one metadata system. The useful design lessons are object relationships over sync jobs, explicit permission sets, approval-gated agent actions, setup audit trail, and a platform shell that connects internal and external experiences.

Boundary / conflict: licenses, implementation weight, vendor lock-in, and a second identity/data model make substantial adoption disproportionate for the present HALO codebase. Salesforce's own docs emphasize shared responsibility: admins still configure permissions, sharing, filters, and guardrails. It is therefore not a magic security substitute for HALO's server-side authorization work. Proprietary commercial platform; no code reuse. Official pages/docs were live 2026-08-29. Confidence: High for system-class reference patterns; High for “do not re-platform now.”

S4. Odoo — broad ERP/CRM/operations suite

Decision: evaluate only as a full re-platform option; reject as a HALO sidecar.

Odoo is the ERP-class candidate: its official product materials enumerate CRM, sales, contacts, projects, documents, accounting, payroll, employees, recruitment, attendance, approvals, quality, eLearning, marketing automation, live chat, dashboards, and more. Its official all-apps page ↗ and accounting documentation ↗ show the breadth and multi-company/accounting orientation.

HALO fit: if the business wants a conventional ERP backbone for employees, expenses, accounting, invoicing, approvals, and CRM, Odoo has the coherent module shell HALO lacks. It is a serious alternative to hand-building commodity back-office modules.

Boundary / conflict: Odoo would own identities, accounting, document/workflow semantics, and likely the UI. A partial integration would create dual creator, campaign, contract, invoice, and staff truth. It does not natively encode HALO's creator/fan vertical, Drive taxonomy, referral economics, or gamification. Adopt only after mapping one complete onboarding-to-payout journey and accepting a re-platform; do not mount it beside Convex for a few screens. Commercial/open-core terms and app-level licensing must be checked for the exact edition before reuse. Official product/docs were live 2026-08-29. Confidence: High for module breadth; Medium for creator-agency fit and migration cost.

S5. ERPNext / Frappe — self-hostable ERP and business system

Decision: full re-platform candidate for finance/HR; otherwise study or reject as a sidecar.

ERPNext's official documentation presents Accounting, Human Resource (leave, attendance, expenses, salary/payroll, recruitment, performance), CRM, assets, and other core modules. Its documentation home ↗ and role-based permissions guide ↗ describe a customizable business system with role/document/field permission levels. Frappe's ERPNext scaling material ↗ describes the product as free/open source.

HALO fit: stronger than a point payroll donor when the real requirement is one multi-persona business backbone for accounting, HR, CRM, projects, and approvals. The permission-level model is useful for creator-sensitive fields and staff roles.

Boundary / conflict: ERPNext's document/ERP worldview would compete with Convex's creator, referral, Drive, and customs models. A sidecar just for payroll/accounting would duplicate users and money truth. Consider only if HALO intentionally moves its financial and staff authority to ERPNext and retains creator-specific services through a clean API boundary. Open-source/provenance and app licenses still require review before embedding code. Official docs were live 2026-08-29. Confidence: High for module/permission breadth; Medium for vertical fit and migration.

S6. Airtable + Omni — modular data, interfaces, and AI app builder

Decision: pilot as a non-authoritative operations prototype or study; reject as the long-term money/identity core.

Airtable's official Omni page describes conversational AI that creates production-ready apps with data, automations, and interfaces. It specifically names meeting notes/call transcripts, campaign planners, marketing workflows, contract extraction, brand/compliance review, and operational dashboards. Official docs also describe managed app/component libraries, permissions, automation triggers/actions, and production sandboxes. See Airtable Omni ↗, managed apps/components ↗, and automations ↗.

HALO fit: fast validation of persona-specific interfaces over Creator/Campaign/ Deliverable tables; reusable module templates; AI extraction from contracts and notes; approval-before-publish automations; and a safe “sandbox before production” habit.

Boundary / conflict: Airtable is a vendor-hosted database/UI/auth boundary with plan, seat, automation, and AI-governance constraints. It is not a double-entry ledger, secrets vault, or creator portal with HALO's exact authorization model. A sidecar can be useful for a temporary ops experiment, but dual-writing creators, money, or contracts would reproduce HALO's split-brain problem. Proprietary SaaS; no code reuse. Official pages/docs were updated/live in August 2026. Confidence: High for rapid modular prototyping; Medium for scale, cost, and security fit.

S7. NocoBase — self-hosted data-model/plugin/workflow platform

Decision: sidecar/module prototype; do not replace HALO wholesale without a schema and authorization migration plan.

NocoBase's official site/docs describe a data-model-driven platform that decouples data from UI, supports external databases and APIs, provides plugin composition, workflows, permissions, audit logs, file management, departments, email, and AI employees. It advertises a TypeScript/Node.js/React/Koa stack and Docker self-hosting. See NocoBase ↗ and the getting-started documentation ↗.

HALO fit: a plausible place to prototype referral/partner operations, internal approvals, staff administration, or a creator-facing data boundary while retaining HALO's bespoke services. Its plugin/data/UI separation is exactly the sort of extensible module model the clarified brief asks us to investigate.

Boundary / conflict: introducing another database and auth layer beside Convex is the primary risk. The “everything is a plugin” model does not automatically guarantee transactional consistency with HALO's ledger or Drive. Verify tenancy, field-level permissions, audit immutability, API/webhook behavior, backups, and plugin licenses. The site says core/foundational code is open source, but each plugin and edition needs a provenance check before reuse. Official pages/docs were live 2026-08-29. Confidence: High for platform shape; Medium for production security and migration fit.

S8. Directus — API/data control plane with permissions and flows

Decision: sidecar for a bounded module or backend pattern study; reject as a second HALO-wide UI/data authority.

Directus describes its architecture as a GUI powered by an API, with dynamically generated REST and GraphQL endpoints, role/policy permissions, data/asset storage, dashboards, and low-code Flows for task automation. See Directus architecture ↗, permissions ↗, and user/role management ↗.

HALO fit: a clean pattern for schema-first collections, explicit policies, API-first external portals, and workflow automation. It could host a bounded referral intake, portal, or evidence module if a single source of truth and identity bridge are defined.

Boundary / conflict: Directus does not supply HALO's creator-domain semantics, gamification, Drive reconciliation, or payout liability model. Its public role and API surface must be configured carefully; any public role is a real data boundary. Adding it without tenant/identity ownership would make the current Convex problem worse. The official docs describe it as open source; review current edition/license terms before embedding. Official docs were live 2026-08-29. Confidence: High for API/policy/flow pattern; Medium for sidecar viability.

S9. SuiteDash — white-label portal and all-in-one SMB operations suite

Decision: sidecar pilot for external portal UX only; reject as HALO's internal core.

SuiteDash's official site describes a branded client portal, CRM, forms, onboarding, appointments, proposals, contracts/e-signature, project/task management, invoicing, time/billing, wiki/intranet, file sharing, dashboards, secure messaging, LMS, support tickets, staff management, and chat. See SuiteDash's white-label platform ↗, the product page ↗, and support documentation ↗.

HALO fit: it is the clearest live product to inspect for multi-persona external experiences: a creator/model or brand can see only assigned work, documents, approvals, messages, and invoices in a branded portal. It could be tested for the “creator sees their work without seeing agency internals” job.

Boundary / conflict: SuiteDash's breadth means it duplicates nearly all HALO modules, but its hosted datastore, identity, workflow semantics, and vendor UX would sit beside Convex. “White label” changes branding, not data authority. Use a non-sensitive portal pilot only; require API/export, audit, retention, and deletion evidence before sharing creator KYC, credentials, or money. Proprietary SaaS; no code reuse. Official pages/docs were live 2026-08-29. Confidence: High for advertised portal breadth; Medium for HALO integration and trust fit.

S10. Mattermost — chat plus repeatable operational playbooks

Decision: sidecar for chatter teams and operational communication; do not make chat the authoritative CRM or money system.

Mattermost's official docs describe channels, collaborative Playbooks, checklists, workflow automation, monitoring/status dashboards, granular team/channel/playbook permissions, exports, and self-hosted/private-cloud deployment. The workflow automation docs ↗ frame Playbooks as repeatable team processes integrated with communication; collaboration docs ↗ describe role/visibility controls and export behavior.

HALO fit: a real chatter-team sidecar for shift handoff, content escalation, incident response, and “what needs attention?” channels, with a playbook checklist attached to a repeatable workflow. It is materially stronger than a free-form Discord server for operational accountability.

Boundary / conflict: a chat history is not a creator relationship timeline, QA scorecard, ledger, or approval record. Link messages/playbook runs to HALO IDs and copy only approved decisions/actions into HALO. Mattermost has open/core and commercial feature boundaries; review the current plans/edition boundary ↗ and enterprise gating (the docs note some permission functionality is Enterprise-only). Official docs were live 2026-08-29. Confidence: High for chatter/playbook pattern; Medium for portal and identity bridge.

S11. Zulip and Discord — communication patterns, not the HALO operating system

Decision: study narrow primitives; reject as the primary multi-module shell.

Zulip's official docs show stream/channel permissions, topic-required conversations, private-history controls, API access, and bots with channel-scoped permissions. See channel permissions ↗, features ↗, and bot permissions ↗. Discord's official developer docs show server/channel management, role hierarchy, and channel-level permission overrides; see server and channel management ↗.

The useful patterns are topic-based conversation (Zulip) and role/channel overrides (Discord). Neither provides HALO's creator lifecycle, documents, ledger, contracts, governance, or cross-module source-of-truth model. Discord's consumer/community posture and bot permission hazards make it especially unsuitable for KYC, credentials, or money. Zulip is more structured but still a chat sidecar. Proprietary/open-source/commercial terms vary by product and edition; no code reuse is recommended here. Official docs were live 2026-08-29. Confidence: High for the narrow communication patterns; High for rejection as HALO core.

GitHub repository discovery addendum (user-requested scope expansion)

This section is deliberately separate from the live-product ranking above. The original lane was scoped to live products and first-party docs; during the campaign the user correctly asked for a serious repository discovery pass as well. GitHub repositories are therefore candidate generators and code/pattern sources here, not proof that HALO should adopt or copy any of them. No repository was cloned into HALO and no file under repo/ was changed.

Search method and coverage receipt

• The authenticated GitHub CLI identity was checked with gh auth status; the token was

present in the keyring and was not printed or exposed. gh version was 2.89.0.

• An initial gh search repos burst reached the GitHub Search API's 30-request window

(search.remaining: 0) while the normal core API remained available. This is why the pass did not pretend that a personal token means unlimited search.

• I then used the linked GitHub repository-search connector for high-throughput candidate

generation, followed by gh api repos/OWNER/NAME for every promoted repository. The connector searches repository names/descriptions; it is not a complete code-index or quality verdict.

• The final combined pass used 67 workflow/category query strings, returned **1,889

result rows, and deduplicated to 1,781 unique repositories**. Queries covered multi-tenant CRM, agency/PSA, ERP, client portals, creator/talent/ATS, AI CRM and business OS, work management, chat, low-code builders, automation, knowledge, content review, payments/ledger, contracts, compliance, identity, and meeting intelligence.

• 30 repositories were promoted for README and license inspection. Promotion required

an actual product/system signal, non-archived status or an explicit reason to retain a caveat, and a plausible HALO workflow or pattern. The other 1,751 unique hits remain unpromoted search backlog/noise; they are not silently counted as recommendations.

The user-supplied anysearch-ai/anysearch-skill repository ↗ was also inspected as a search-tool lead. Its README describes general web search, vertical search, parallel batch search, and full-page extraction; it is not the GitHub repository-search API used for this pass. Its README proposes registering a separate service and writing an API key to .env; that registration and any local credential write were intentionally not performed. Its verification metadata is included below as method evidence, not as a HALO product candidate.

Ranked repository candidates

The action labels are intentionally strict: adopt means a serious re-platform or primary-subsystem experiment; integrate means a bounded sidecar with explicit IDs and authority; study means mine the model/UI/workflow pattern; reject means the license, maturity, boundary, or product shape makes it unsafe as a current HALO choice. “Confidence” describes the evidence for the stated capability and boundary, not the vendor's unverified quality claims.

What this search changes in the recommendation

The GitHub pass did not uncover a magical “OFM HALO” replacement. It did uncover a much more actionable composition shortlist:

1. Open Mercato or erxes are the first system-class architecture spikes. Open Mercato

has the cleaner MIT/multi-tenant/custom-entity story; erxes has the more complete business-module and inbox/operations story, but its AGPL/source-available boundary is materially harder for a commercial SaaS.

1. Comp AI CRM + Operately supply the most interesting AI-native owner/relationship

and execution-cadence patterns. Treat their evidence ledger, durable work queue, check-ins, and agent interfaces as patterns to test, not as permission to automate creator or fan actions.

1. ITFlow + AgencyOS + InfluenceX are the most useful agency-adjacent code signals:

service-business documentation/portal/billing, an actual agency scaffold, and a creator campaign state machine with review-gated outreach. Their different licenses, maturity, and domain assumptions must stay visible.

1. ERPNext/Odoo/Akaunting/Lago are finance/back-office references, not shortcuts to

HALO's creator-liability ledger. The domain model must still explain attribution, split ownership, reversals, tax evidence, and departure/export.

1. Mattermost/Zulip/Chatwoot/n8n/Activepieces/Windmill/Dify are sidecars or patterns.

Buzz remains the fixed collaboration plane; any sidecar must use stable IDs, scoped tools, and an idempotent server-side adapter.

GitHub verification and license ledger

The following values are the required gh api repos/OWNER/NAME receipt for every promoted repository. NOASSERTION is GitHub's metadata result, not a license verdict; for those rows the repository license source was opened and summarized in the notes below. Dates are the API's pushed_at values in UTC, not a promise of release quality.

The search-tool repository is a separate method receipt:

NOASSERTION source inspections

• erxes LICENSE.md ↗: content

outside the ee area is AGPLv3; enterprise plugins have a separate license and the file says erxes may not be hosted as a competing SaaS.

• Operately LICENSE ↗: the

base is Apache 2.0, while the ee directory has a separate Enterprise Edition license.

• Odoo LICENSE ↗: Odoo is LGPLv3, with

external libraries/contributions subject to their own notices.

• NocoBase LICENSE-APACHE.txt ↗

is Apache 2.0, but its LICENSE.txt ↗ is a current NocoBase License Agreement distinguishing Community Edition, Commercial Edition, plugins, and upper-layer applications. Treat the repository as mixed/licensed, not as a blank Apache foundation.

• Directus license ↗ is the

Monospace Sustainable Core License (MSCL-1.0-GPL), not a generic MIT/Apache grant.

• Mattermost LICENSE.txt ↗

says compiled Mattermost releases are MIT, source is AGPLv3 or commercial, and admin tools/configuration files are Apache 2.0.

• Activepieces LICENSE ↗

makes content outside the EE directories MIT and gives EE content a separate license.

• Windmill LICENSE-AGPL ↗

is AGPLv3; the README also describes commercial support/licenses.

• n8n LICENSE.md ↗ uses the

Sustainable Use License, leaves .ee files under a separate enterprise license, and states that non-main branches are not licensed. This is not standard open-source reuse.

• Dify LICENSE ↗ is a modified

Apache 2.0 license with a multi-tenant-service restriction, frontend/logo conditions, and a right for the producer to change the agreement.

• OpenCATS LICENSE.md ↗

identifies MPL 2.0 for OpenCATS code and a separate CATS Public License for original circa-2007 code.

• Akaunting LICENSE.txt ↗

is BSL and limits the public production grant to two users/one company/1,000 invoices, while barring rebranding and accounting services under the stated additional grant.

• Chatwoot LICENSE ↗ makes

non-enterprise/ content MIT and puts the enterprise directory under a separate license.

• Mautic LICENSE.txt ↗ states GPLv3

with other compatible notices for bundled works.

• Outline LICENSE ↗ is BSL 1.1,

explicitly not an open-source license at present; it restricts a commercial Document Service and lists a future Apache change date.

Negative findings from GitHub

• Repository search is excellent for breadth but weak at distinguishing a maintained

SaaS from a tutorial, fork, portfolio, or generated demo. The 1,781 unique result count is a search-recall measurement, not a quality score.

• The most creator-specific search hits were usually small demos or templates. The one

codebase with the clearest campaign/review/approval/RBAC shape was InfluenceX; it still does not prove lawful platform integration, adult consent handling, or a production liability ledger.

• No open repository found in this pass combined creator lifecycle, age/identity/consent,

rights/usage, account access, content provenance, platform-safe messaging, payouts, audit, and multi-persona tenancy in one credible system.

• High stars correlate with ecosystem/activity, not HALO fit. A 4-star creator-specific

state machine can be more useful than a 200k-star automation engine, while a 50k-star ERP can still create a second source of truth.

• “Open source” was frequently marketing shorthand. NOASSERTION metadata, BSL,

Sustainable Use, modified Apache, AGPL enterprise splits, and no-competing-SaaS clauses materially change buy/integrate/fork decisions.

Repository proof plan before any adoption

1. Select only three experiments: Open Mercato or erxes for a system-class shell,

InfluenceX for creator acquisition/campaign state, and Activepieces or Windmill for guarded automation. Keep the current HALO/Convex identity and financial records authoritative during all tests.

1. Use synthetic creators, brands, campaigns, contracts, consent documents, content

hashes, payout events, and staff roles. Do not connect live creator accounts, platform credentials, scraped data, real payment rails, or real contracts.

1. Prove one complete journey: lead→qualification→consent/contract→roster→campaign→

deliverable→approval→renewal/offboarding. Measure authority, permission decisions, event provenance, idempotent retries, export/restore, and deletion/retention behavior.

1. For every candidate, run a license review against the exact edition and deployment

shape. A repository badge or GitHub SPDX field is not enough when the repo contains enterprise directories, BSL terms, or a custom service restriction.

1. Stop if a candidate requires mirroring sensitive creator records into a second

uncontrolled datastore, grants an agent unreviewed write authority, cannot export signed/consent/rights evidence, or makes offboarding/revocation non-reversible.

Ranked bounded capability candidates

Rank is workflow leverage for HALO, not a star or brand ranking. “Adopt” means use the product as a bounded operating tool; “integrate” means keep HALO as system of record and connect the capability; “study” means copy the pattern only; “buy” means use a vendor service for a commodity/trust boundary; “pilot” means verify the product with real HALO work before committing.

1. Influs — talent operations for creator agencies

Recommendation: pilot / buy selectively. Journeys: owner command centre, creator lifecycle, content operations, money and trust, creator portal. Concrete pattern: the product explicitly puts due-today work, awaiting approvals, and outstanding creator payments on the opening surface; its workflow is roster → campaign → deliverable → payment → creator portal. It also keeps campaign versions, deadlines, approval history, deal value, creator payouts, and margin in the same campaign context. That is the closest public match to HALO's missing “what needs me?” operating surface. See the official Influs product page ↗.

Boundary / duplication: it overlaps heavily with HALO's onboarding, creator records, content pipeline, and payment tracking. The page states that Influs tracks pending, overdue, and paid status but does not move money. Therefore it cannot replace a creator-liability ledger, payout control, Drive taxonomy, or HALO-specific customs and gamification. Use a sandbox roster and one campaign to test whether its portal and approval state are better than a focused HALO slice; do not import a second source of truth by default.

Stack / integration boundary: vendor-hosted SaaS with CSV roster import and a creator-facing portal; the reviewed page does not expose a public API or implementation stack. Treat CSV/export and vendor-supported integration as the known boundary until confirmed in a trial.

License / freshness: proprietary commercial SaaS; no code reuse. Official page was live and reviewed 2026-08-29, with public pricing, trial, and product workflow. Confidence: High for advertised workflow; Medium for production depth and integration.

2. Influno — connected creator/studio/agency operations

Recommendation: study the model; request a controlled pilot if access is available. Journeys: money and trust, creator lifecycle, content operations, governance, owner command centre. Concrete pattern: Influno's public product page connects deals, contracts, invoices, payments, payouts/splits, content, collaboration, portals, roles, and analytics. Its money model specifically claims per-deal/client split rules, batch approval, branded creator statements, and reconciliation to a double-entry ledger. It also describes workspace isolation, deny-by-default roles/2FA, immutable audit logging, data portability, and “automation drafts; it never moves money without you.” See the official Influno product page ↗.

Boundary / duplication: this is the best external benchmark for correcting HALO's contradictory float/commission calculations and missing statements, but a page cannot prove that its ledger, controls, or payout rails withstand disputes. Keep the rule: HALO's ledger is authoritative; a payment provider executes; an external product is a pilot or pattern source until reconciliation and export are demonstrated.

Stack / integration boundary: vendor-hosted product; the reviewed page advertises the connected modules but not a public API, SDK, or underlying stack. Ask for ledger export, webhook/API, audit-log export, and dispute/reversal behavior before integration.

License / freshness: proprietary commercial SaaS; no code reuse. Official page was live and reviewed 2026-08-29; public evidence is primarily the product page. Confidence: Medium. Strong conceptual fit, insufficient public operational evidence for adoption without a trial.

3. AFFiNE — local-first docs, whiteboards, databases, and knowledge base

Recommendation: bounded internal pilot / pattern study; do not embed its backend into HALO without a licensing review. Journeys: owner command centre, communication/relationship memory, creator lifecycle, content operations, team SOPs, automation/RAG. Concrete pattern: AFFiNE makes a page both a document and a whiteboard, links docs, databases, and visual plans, supports local-first/offline use, and offers workspace search plus bi-directional linking. Its official knowledge-base page explicitly names meeting notes, project specs, decisions, internal documentation, onboarding guides, and AI grounded in workspace content. Its official MCP page ↗ describes workspace-scoped, revocable credentials and search over documents and whiteboards. These are directly relevant to creator records, meeting notes, briefs, SOPs, handoffs, and institutional memory.

License caveat (must not be elided): the official self-host page ↗ and official knowledge-base page ↗ describe AFFiNE as open source and self-hostable, but the verified repository metadata reports license.spdx_id: NOASSERTION, not a single permissive license. The root LICENSE ↗ states that content outside packages/backend and packages/common/native is MIT, third-party components retain their own licenses, and backend content is governed by a separate license. The backend license ↗ is an AFFiNE Enterprise Edition license requiring a valid subscription for production; it also says CE/client-served portions are MPL-2.0. This is a mixed-license product, not “MIT all the way down.”

Verified repository metadata:

These values came from gh api repos/toeverything/AFFiNE; the license sources were then inspected because GitHub returned NOASSERTION.

Boundary / duplication: AFFiNE is a knowledge layer, not a creator CRM, ledger, contract system, credential vault, or authoritative approval engine. A sensible pilot would use sanitized SOPs, meeting notes, a creator-record template, and one brief/hand-off workflow, measuring findability and export. Keep sensitive credentials, money, KYC, and contract authority in HALO or dedicated systems. Stack / freshness: official site advertises desktop/mobile/browser and Docker self-hosting; official releases ↗ show active releases, and the repository was pushed 2026-08-28. Confidence: High for product boundary and licensing caveat; Medium for HALO fit until the pilot proves permissions, export, and operational search quality.

4. Granola — meeting intelligence and follow-up memory

Recommendation: buy/integrate as a capture layer, with approved write-back to HALO. Journeys: owner command centre, communication/relationship memory, team handoffs, automation/intelligence. Concrete pattern: Granola Chat queries one meeting, selected meetings, folders, or all meeting notes; it can find decisions, recap action items, generate follow-ups, and surface recurring themes across meetings. Its docs also show a review step before follow-up emails, Slack messages, or calendar events are created. See chat across meetings ↗ and the Granola docs ↗.

Boundary / duplication: Granola explicitly says it does not know HALO's emails, offline tasks, or personal to-do lists; it answers from meeting data and uploaded files. That makes it useful for capture, not a complete owner command centre. The write-back contract should be: transcript/notes → human-approved summary → HALO decision/action with owner, due date, related creator/brand/team record, and source link. Do not let a summary silently mutate money, permissions, contracts, or creator status.

Stack / integration boundary: desktop/mobile SaaS with calendar and workspace scopes; the reviewed docs expose sharing, export, and workflow concepts but no public HALO-specific API guarantee. Confirm export/API/webhook capability and retention before buying for sensitive creator conversations.

License / freshness: proprietary SaaS; no code reuse. Official docs and linked status, security, and updates surfaces were live on 2026-08-29. Confidence: High for meeting-memory pattern; Medium for integration and retention fit.

5. Attio — relationship/context model with notes, tasks, and workflows

Recommendation: study; integrate only if it is deliberately the relationship system of record. Journeys: creator discovery/lifecycle, communication memory, owner command centre, automation. Concrete pattern: Attio's official help center exposes custom objects, relationships, email/calendar sync, notes, tasks, communication intelligence, call intelligence, workflows, reporting, and a developer platform/API/SDK/MCP. Its data model explicitly allows custom objects for data that does not fit a fixed CRM schema. See Attio 101 ↗, the data model ↗, and relationship attributes ↗.

Concrete HALO pattern: model Creator, Brand, Staff member, Campaign, and Promise as linked records; put email/calendar and meeting context on the relationship timeline; make next actions first-class tasks rather than free-text notes.

Boundary / duplication: Attio is a GTM CRM, not HALO's compliance, content Drive, ledger, payroll, or creator portal. Running Attio beside HALO without an explicit owner for creator identity will create split-brain relationship history. Prefer copying the data-model pattern or integrating one narrow object/timeline, not mirroring every record.

Stack / freshness: vendor SaaS with documented API/SDK/MCP/developer surface; the public docs do not establish implementation stack. Official help center was live and reviewed 2026-08-29. Proprietary; no code reuse. Confidence: High for data-model/workflow pattern; Medium for HALO integration design.

6. Adobe Frame.io / Workfront unified review

Recommendation: buy/integrate for professional media review, or study its approval contract; keep HALO's Drive taxonomy. Journeys: content operations, client/creator approvals, provenance, governance. Concrete pattern: Adobe's current Workfront documentation describes a Frame.io viewer with markup, comments, frame-accurate time-stamped video feedback, version history and comparison, mobile review, multi-stage approval, and a unified change-tracking audit log. See unified review and approval ↗ and the August 2026 storage/rollout documentation ↗.

Concrete HALO pattern: separate “uploaded” from “in review,” “needs work,” “approved,” and “published”; bind comments to an immutable asset version; require an explicit named decision; make the next version a child of the prior version instead of overwriting it.

Boundary / duplication: Frame.io is a review/media surface, not a creator roster, contract/payout system, or Drive-backed agency taxonomy. Adobe documents permission flowing from Workfront into Frame.io and notes that viewer comments are not included in the Workfront audit log. HALO must decide where the authoritative approval decision and full comment/provenance record live before integrating.

Stack / freshness: proprietary Adobe cloud product with documented API standards and Adobe cloud storage; current documentation was updated August 19, 2026. Confidence: High for review pattern and boundary; Medium for cost/fit at HALO scale.

7. Stripe Connect — payment routing and payout execution

Recommendation: integrate as a money-movement rail, never as HALO's ledger. Journeys: money/trust, creator onboarding/KYC boundary, disputes, automation. Concrete pattern: Stripe Connect supports connected-account onboarding and verification, payment routing, application fees, multi-party transfers, payout timing, manual/instant payouts, cross-border availability, and payout webhooks such as payout.created, payout.paid, and payout.failed. See How Connect works ↗, payouts to connected accounts ↗, and Connect features ↗.

Concrete HALO pattern: treat each inbound collection, fee, creator share, reversal, and payout as an append-only event with an idempotency key; let a human approve payout batches; reconcile Stripe events back to a HALO double-entry liability ledger. Use Stripe for execution and regulated account/payment controls, not for creator-specific business truth or historical statements.

Boundary / caveat: Connect's country, account-type, risk, tax, merchant-of-record, chargeback, and cross-border rules are configuration- and jurisdiction-dependent. Stripe lists Vietnam and Thailand among supported country contexts in the reviewed docs, but that does not establish HALO's eligibility or legal model. Legal/payment review is required.

Stack / freshness: proprietary API/SaaS with hosted or embedded onboarding and webhooks; official docs were live and reviewed 2026-08-29. Confidence: High for technical payment boundary; Medium for legal/business-model fit.

8. Trolley — payouts and tax-form operations

Recommendation: buy/integrate for tax-form collection and filing support; keep the liability ledger and approval logic in HALO. Journeys: money/trust, creator onboarding, governance. Concrete pattern: Trolley's official IRS compliance page states that it collects and stores W-8/W-9 forms and generates 1099 and 1042-S forms for e-filing. See Trolley IRS compliance ↗.

Boundary / duplication: this addresses a specific commodity HALO should not recreate, but tax-form support is not a universal answer for every creator's country, entity type, or platform-income classification. Confirm supported jurisdictions, data residency, recipient onboarding, correction/reissue workflows, and export. Do not call a tax-form vendor a substitute for split calculations, dispute history, or reconciliation.

Stack / freshness: proprietary SaaS/API boundary is vendor-controlled; official page was live and reviewed 2026-08-29. Confidence: High for the documented US tax-form capability; Medium for global/adult-creator fit.

9. Deel — contractor onboarding, compliance, and global payments

Recommendation: buy/integrate for staff/contractor operations where its legal coverage fits; do not assume it handles HALO's creator-revenue splits. Journeys: team operations, creator/staff onboarding, money/trust, governance. Concrete pattern: Deel's developer docs describe an embedded contractor onboarding flow covering invitation, contract signing, identity verification, payout-method setup, and onboarding tracking; its APIs can submit hours/receipts for approval and trigger milestone payouts in multiple currencies. See Deel developer documentation ↗, worker onboarding ↗, and payroll ↗.

Boundary / caveat: the onboarding doc explicitly says W-8/W-9 and equivalent tax-form completion is handled in Deel-hosted UI rather than the API. That is a meaningful product boundary. Deel is a stronger candidate for employees/contractors and compliance-heavy engagements than for agency-vs-creator campaign splits and statements. License / freshness: proprietary SaaS/API; official docs were live and reviewed 2026-08-29. Confidence: High for documented onboarding/API boundary; Medium for HALO creator use case.

10. 1Password Business — secrets, access, and offboarding

Recommendation: buy now for the credential-vault boundary. Journeys: governance/safety, creator account access, team onboarding/offboarding, incident response. Concrete pattern: 1Password Business documents fine-grained vault permissions, team policies, 2FA enforcement, automated provisioning, security reports, and an audit log of actions and changes. See About 1Password Business ↗ and business security practices ↗.

Concrete HALO move: remove passwords from Convex records and the client bundle; use role/group-controlled vaults, short-lived access where possible, provisioning/deprovisioning, and audit export. HALO should store a reference/ownership record, not the secret. Rotate existing credentials separately; buying a vault does not remediate previously exposed secrets.

Boundary / duplication: 1Password is not creator CRM, KYC, payment ledger, or a replacement for server-side authorization. It is a high-value narrow buy because HALO's current vault is a trust boundary, not because it improves the visible UI. Proprietary SaaS; no code reuse. Official support page was live and reviewed 2026-08-29. Confidence: High.

11. Filestage — external review and approval workflow

Recommendation: pilot/buy for document and asset approvals if Frame.io is too media- heavy; otherwise study the approval state machine. Journeys: content operations, client portal, governance. Concrete pattern: Filestage's official help center organizes the flow around projects, roles and permissions, versions, reviewer decisions, feedback, due dates, and reviewer dashboards. Its reviewer-sharing docs support external reviewers without accounts and optional password protection. See Filestage getting started ↗ and reviewer permissions ↗.

Boundary / duplication: this is a review surface, not a creator record or agency ledger. The useful HALO abstraction is a review object with reviewer group, version, decision, due date, and resolved comments. Keep Google Drive as storage only if HALO can preserve the review/version link and authoritative decision in its own record. License / freshness: proprietary SaaS; official help content was live 2026-08-29. Confidence: High for documented review boundary; Medium for HALO's media mix and API fit.

12. MaestroQA — scorecards, calibration, coaching

Recommendation: study first; buy only for a real chatter/support QA program. Journeys: team operations, communication quality, gamification, governance. Concrete pattern: MaestroQA documents rubrics, agent/grader QA workflows, calibration sessions, coaching, integrations, and AI classifiers. Its calibration workflow uses the same scorecard and a shared session to align graders and provide actionable feedback. See MaestroQA help center ↗ and calibration workflows ↗.

Concrete HALO pattern: separate raw interaction evidence, rubric version, grader score, calibration score, coaching action, and reward/commission consequence. This gives HALO's gamification system a trustworthy measurement layer instead of letting XP stand in for quality.

Boundary / duplication: contact-center QA is not automatically creator-agency QA; adapt the rubric and protect conversation consent/retention. Proprietary SaaS; official docs and feature page were live/reviewed 2026-08-29. Confidence: High for scorecard/calibration pattern; Medium for vertical fit.

13. n8n — workflow automation with human approval

Recommendation: integrate as an orchestration rail, with HALO owning authorization, idempotency, audit, and durable business state. Journeys: automation/intelligence, owner exceptions, content handoffs, notifications, governance. Concrete pattern: n8n documents app-to-app workflows, self-host/cloud options, AI agents, and human-in-the-loop tool approvals. Its human-review flow pauses an agent, shows the requested tool and parameters to a reviewer, then approves or denies before execution. See n8n docs ↗ and human-in-the-loop tool calls ↗.

Concrete HALO pattern: AI proposes → deterministic validator checks → human approves the exact payload → n8n executes → HALO records result and reconciliation. Approval must expire, be bound to a version/idempotency key, and never grant the workflow broad vault, payment, or delete authority.

Boundary / caveat: n8n describes itself as fair-code licensed, not a blanket permissive open-source component. Do not embed its internals into HALO without reviewing the current license and commercial terms. A workflow canvas is also not automatically a durable ledger or policy engine. Official docs were live/reviewed 2026-08-29. Confidence: High for HITL pattern; Medium for safe production integration.

14. Vanta — evidence/control/audit workflow

Recommendation: study its evidence model; buy only when HALO's compliance program and audit scope justify a dedicated GRC vendor. Journeys: governance/safety, access review, vendor review, incident evidence, audit. Concrete pattern: Vanta describes continuous evidence collection, control monitoring, framework mapping, issue management, auditor views, evidence status, approvals, and vendor-security workflows. Its help center emphasizes that auditors see scoped evidence, personnel, computers, access reviews, and integrations without changing the customer's scope. See automated compliance ↗, audit workflow ↗, and vendor security reviews ↗.

Concrete HALO pattern: each control has an owner, scope, evidence source, collection cadence, reviewer, status, exception, and remediation task. Reuse evidence instead of asking the team to rebuild a compliance folder each audit cycle.

Boundary / duplication: Vanta is not identity enforcement, a secrets vault, or a substitute for an incident-response process. It may be overkill for a small internal agency; implement a small append-only evidence/control model first. Proprietary SaaS; official pages/help content were live/reviewed 2026-08-29. Confidence: High for evidence/control pattern; Medium for current HALO ROI.

15. Linear — issue/cycle semantics for team operations

Recommendation: study, do not adopt as a second task system yet. Journeys: owner command centre, team operations, content handoffs, automation. Concrete pattern: Linear's official conceptual model makes an issue belong to a team, move through ordered workflow statuses, carry an assignee, project, cycle, label, priority, and comments. See Linear's conceptual model ↗. This is a useful compact vocabulary for HALO tasks: team ownership, status transitions, priority, cycle/timebox, and discussion attached to the work item.

Boundary / duplication: HALO already has domain-specific tasks, quests, payroll, Drive, and creator workflows. Adopting Linear would duplicate task truth and would not solve creator money, contracts, KYC, or content provenance. Copy the transition/event semantics into HALO only where a real owner and history are missing. Proprietary SaaS; official docs were live/reviewed 2026-08-29. Confidence: High for workflow pattern; High for “do not add a second task system” fit.

Important rejects and “not yet” candidates

These are recorded to prevent the next hunt from repeating the screen-label trap. A candidate can be interesting and still fail the current HALO decision.

Cross-product design rules worth carrying into HALO

1. One record, many linked events. Creator, brand, campaign, asset, meeting, money

event, decision, and task should be linked; no product's dashboard should become the only history.

1. Separate status from authority. “Paid” in a campaign tracker is not a payout;

“approved” in a media tool is not a ledger settlement; “authenticated” is not authorized.

1. Make review state explicit. Use version, reviewer, decision, timestamp, due date,

and resolved feedback. Never overwrite an asset or approval history.

1. Human approval is a durable object. Bind it to the exact proposed payload,

requester, approver, expiry, idempotency key, and execution result. A Slack button or n8n pause alone is not an audit trail.

1. Keep vendors at the rails. Stripe/Trolley/Deel can execute or document regulated

operations; HALO still needs an authoritative liability ledger, statements, disputes, and export.

1. Treat knowledge as scoped and portable. AFFiNE/Granola/Attio patterns are useful

only if HALO can preserve permissions, source links, retention, and an exit path.

1. Pilot with real journeys, not feature checklists. Run one creator onboarding, one

campaign brief-to-approval, one meeting-to-follow-up, one payout/dispute, and one team QA calibration. Record what became authoritative, what duplicated, what exported, and what still required manual reconciliation.

Recommended next experiment order

This is a research handoff, not permission to mutate the live app.

1. Containment: rotate exposed credentials and move the vault to a dedicated secret

manager; 1Password is the strongest web-verified buy candidate in this pass.

1. Workflow slice: pilot Influs or a local HALO “daily priorities” surface against

one campaign, while preserving HALO's creator and Drive records.

1. Memory slice: test Granola or an equivalent meeting capture flow with explicit

human-approved write-back to a HALO decision/action record; test AFFiNE separately with sanitized SOPs and export.

1. Approval slice: compare Frame.io and Filestage on one real content type; require

immutable version/decision provenance before connecting publishing.

1. Money slice: model HALO's double-entry creator liability ledger first, then test

Stripe Connect/Trolley/Deel against payout, reversal, tax, and export cases.

1. Automation slice: use n8n only after authorization, idempotency, approval, and

audit contracts exist; use Vanta/MaestroQA patterns to formalize evidence and quality.

Evidence receipt

• Fresh web research ran across system-class CRM/ERP, modular data platforms, portals,

chatter workspaces, AI-native operating systems, creator-agency operations, meeting intelligence, knowledge/workspace, creative review, payments/tax, secrets, QA, compliance, and automation vocabulary.

• Every promoted product above has at least one direct official product or documentation

URL in its entry.

• The GitHub addendum cites 30 promoted candidate repositories plus the user-supplied

anysearch-ai/anysearch-skill method repository. Every one was verified first with gh api repos/OWNER/NAME; the required metadata and NOASSERTION license-source inspections are recorded above. The earlier AFFiNE and Twenty verification remains in the system-class/bounded entries.

• No files under repo/ were edited; no deploy, PR/issue, or Convex seed/reset/migrate

mutation was run.