Go back to Market Research
PartnerLinQ supplies cloud software for exchanging business documents, connecting trading partners, and coordinating supply chain workflows. Its EDI platform handles document validation, acknowledgements, transport, monitoring, and reprocessing. Additional applications cover demand planning, inventory visibility, warehouse labor scheduling, and carrier selection. The intended users include integration teams, planners, logistics operators, and their external partners. 1 2 7 8
Overall supply chain score: 4.3/10
| Dimension | Score |
|---|---|
| Supply chain depth | 4.0/10 |
| Decision and optimization substance | 3.6/10 |
| Product and architecture integrity | 4.8/10 |
| Technical transparency | 4.8/10 |
| Vendor seriousness | 4.2/10 |
PartnerLinQ’s strongest proposition is replacing difficult partner integrations with a common operating platform. Its public evidence includes a named Wayfair deployment, an inspectable Microsoft connector, and a customer recruiting specialists to use its mapping agent. These establish a substantive integration business. They also reveal the work behind the promise: mappings, business rules, testing, exception handling, and ongoing partner maintenance. 9 11 12
The broader claim to autonomous supply chain intelligence is much weaker. Forecasting remains organized around consensus quantities and configurable corrections; specialized applications provide local recommendations without a disclosed joint treatment of demand, supply uncertainty, and economic consequences. MCP supplies another access route to data and actions. It does not resolve these numerical or organizational problems, despite PartnerLinQ presenting the protocol as a way to remove integration complexity and automate the entire commercial cycle. 2 4
PartnerLinQ versus Lokad
The main difference concerns what the software takes responsibility for producing. PartnerLinQ organizes information exchange and business processes across companies. Its planning applications extend that foundation with forecasts, alerts, schedules, and recommendations. The customer still defines much of the interpretation and policy connecting these outputs to commercial action.
Lokad’s inventory optimization starts with the recurring decisions themselves: which units to buy, produce, allocate, or move, and their expected economic consequences. Probabilistic projections of demand and supply, including receipt dates, and explicit costs inform those decisions. Supply Chain Scientists maintain the numerical logic and investigate whether it continues to represent the business adequately. That operating model differs from connecting applications and letting planners reconcile their outputs.
When a supplier postpones a delivery, transmitting the revised date is an integration task. Choosing whether to expedite, substitute, or allocate scarce stock requires valuing the alternatives against uncertain demand and receipt dates. The economic question is whether the combined system reduces the effort needed to make and improve those decisions. Faster document exchange can coexist with expensive planning meetings, manual overrides, and policies that make poor inventory commitments. Conversely, numerical optimization depends on reliable transaction data and correct execution. Both vendors should be judged on realized returns after software, implementation, and continuing specialist work.
The integration mechanism is more concrete than the intelligence claim
PartnerLinQ describes a recognizable EDI processing chain: receive a payload, validate its envelope and business structure, transform or enrich it, route it, and associate acknowledgements with the originating transaction. Monitoring follows individual processing steps; operators can replay failed work. Its business rules engine handles conditional routing and cross-reference lookups, while registries and templates support onboarding. 1
This addresses a real problem. Two partners can exchange syntactically valid documents while disagreeing about product identifiers, units, shipment status, or the meaning of an acknowledgement. Reliable processing requires those interpretations to remain consistent as partners change their systems. Templates reduce repeated work; they do not eliminate responsibility for the interpretation.
Microsoft’s public connector documentation exposes a narrower, testable interface. It supplies GET and POST actions, requires connection credentials and contextual identifiers, and describes polling as a possible consumption pattern. The published throttle is 100 calls per minute per connection, not a limit on the entire PartnerLinQ platform. 9
The corresponding API definition identifies an Azure-hosted endpoint and explicit request and response schemas. That makes the integration contract inspectable. It does not expose the transformations behind an arbitrary customer process or the mathematical logic of a planning application. Those are separate layers with separate failure modes. 10
MCP leaves the difficult integration work in place
The MCP whitepaper describes PartnerLinQ as both a provider of operational context and a consumer of Dynamics 365 ERP data. It says this access avoids replicating ERP data and presents protocol adoption as removing custom integration layers, cost, and complexity. Its examples emphasize investigations, explanations, monitoring, and recommendations, culminating in a proposed forecast-to-settlement workflow. 4
The unsupported step is from standardized invocation to standardized business meaning. A protocol does not determine whether an inventory quantity includes reservations, which timestamp governs a commitment, how a supplier identifier maps across companies, or whether two actions can safely execute together. Those decisions remain in application logic and integration contracts. Exposing an existing function to an agent is cheap compared with designing and validating that logic.
There is a direct commercial consequence. A buyer can acquire conversational access to the same exceptions while retaining the same underlying work. The useful productivity test is the number of correctly resolved transactions and economic decisions per total specialist hour, including maintenance. The number of connected agent tools says little about this.
PartnerLinQ’s integration-agent page is more specific: agents propose reusable setup components, help diagnose problems, and support reprocessing or routing with approvals and audit trails. These are plausible ways to accelerate integration work. Their value needs measurement against existing automation and human effort; the MCP label supplies neither. 5
What the planning applications actually decide
Forecast corrections preserve the consensus-planning model
The forecasting application documents hierarchical disaggregation, fixed quantities protected from subsequent adjustments, returns expressed as percentages or units, order-plus-percentage corrections, and historical-peak cleaning. It supports configurable S&OP and S&OE approval queues. These mechanisms describe how people construct and reconcile a forecast. They do not specify a distribution of future demand or a policy that chooses purchases by expected profit. 2
Each correction also creates a modeling obligation. Removing a promotional peak may help estimate a baseline, but the promotion must then reappear correctly when projecting future events. Protecting a quantity from adjustment can preserve an intentional commitment or insulate a bad assumption. A hierarchy reconciles totals; it does not establish substitution relationships between sizes, products, or channels.
The Demand Sensing Control Tower adds short-horizon corrections from recent signals, stockout handling, refill suggestions, and exception views. It also permits reducing the forecast to available stock. The published description supplies no comparative evaluation showing which signals improve decisions after their collection and processing costs. 6
Constraining an expected shipment to stock on hand can be operationally correct. Treating the resulting quantity as underlying demand would conceal lost sales. A system needs to preserve that distinction throughout training, evaluation, and replenishment. Recent observations cannot by themselves reveal demand that could not materialize because inventory was unavailable.
The missing uncertainty is also on the supply side. Neither application explains how uncertain replenishment dates, partial deliveries, or correlated disruptions enter a joint economic decision calculation. A lead-time check or a revised forecast is insufficient when the same demand outlook can justify different purchases depending on delivery reliability and downside exposure.
Labor scheduling has an objective, but its scale claim outruns its disclosure
The Warehouse Labor Optimizer is described as a multi-skilled resource-constrained scheduling application. It matches skills to tasks, prevents double assignments, handles working-time rules, and gives full-time employees priority over temporary staff. Implementation includes calibrating workload rates and labor costs, establishing a cost-per-unit baseline, and piloting a schedule. These are more concrete commitments than generic decision-intelligence language. 7
The same page says its solver scales instantly without performance degradation as employee counts and complexity rise. It supplies no workload, hardware, algorithm, or benchmark supporting that assertion. It also describes workload and absence changes through recalculation and user-selected scenarios, without explaining how uncertain workloads or attendance affect the original staffing decision. 7
The concern is the model, before the solver. A hard preference for one employment category can conflict with a broader cost calculation involving overtime, skill bottlenecks, and downstream delays. An accurate solution to a narrow scheduling problem can still produce an expensive operating policy. The vendor needs a practical way to discover and revise those assumptions, not merely rerun the same formulation faster.
Carrier recommendations use customer-defined trade-offs
The carrier application uses shipment history, charges, margins, and reliability, with customer-adjustable weights for criteria such as cost and delivery time. It presents a recommended carrier with supporting historical information. 8
A weighted reliability score leaves the central economic conversion to the person setting the weights. A late delivery of replenishable merchandise and a late delivery that stops production have very different consequences. History also reflects the loads previously assigned to each carrier; it is not automatically an unbiased estimate of performance on every alternative assignment. The published mechanism does not explain either correction or optimization across a constrained collection of shipments.
Software bill of materials and operational boundaries
The public inventory identifies architectural roles more clearly than underlying packages:
| Component | Documented role and scope |
|---|---|
| Azure and Google Cloud | Supported infrastructure; the Wayfair case specifically identifies Google Cloud. |
| MIDO | PartnerLinQ’s distributed orchestration layer, with queues, scheduling, backpressure, and resource management. |
| Data fabric | Canonical records, metadata, semantic relationships, transformations, and cross-reference services. |
| LinQ.IQ | Agent functions spanning setup, analysis, and actions. |
| Microsoft connector | A specific Azure-hosted integration endpoint with published schemas. |
| GraphQL | Identified in the Wayfair deployment’s EDI/API layer. |
The platform overview supplies the architectural description; the connector and named deployment provide narrower implementation evidence. 3 10 12
Operating across clouds adds deployment, identity, recovery, and data-transfer obligations. A semantic layer adds definitions that must agree with source records; caches add invalidation obligations; orchestration adds queues and retry behavior. Those costs can be justified by replacing several legacy gateways. The public material does not quantify the resulting infrastructure or operating effort.
PartnerLinQ’s current product-engineering vacancy emphasizes customer discovery, production delivery, automated testing, and critical evaluation of AI-generated work. It does not identify the platform’s database, queue, or runtime implementations. Those major dependencies remain undisclosed. 20
Security needs stronger evidence at the execution boundary
PartnerLinQ describes permissions at object, field, and transaction level, encrypted configuration and credentials, transformation lineage, and tenant-level separation. These identify intended control boundaries. Public documentation does not show how the boundaries withstand compromised integrations or agent actions, nor provide recovery-test results. Its list of compliance frameworks does not answer those questions. 3
The inspectable Microsoft connector uses HTTPS and Basic authentication, plus an API access key in a URL query parameter. Context such as tenant, company, process, and environment is supplied in headers. This is the connector definition preserved in the repository’s February 2023 revision and still linked to the current connector offering. 9 10
Putting a credential in a URL creates additional opportunities for accidental retention in request logs. More fundamentally, server authorization must bind the supplied context to the authenticated principal; caller-supplied identifiers are not an isolation mechanism. The public schema does not show that enforcement. It also cannot establish the security of newer agent interfaces.
Planning pages advertise customer-developed algorithms and models but leave their execution environment unspecified. The security question is whether extensions can reach production data, secrets, networks, or other tenants, and which restrictions operate outside the submitted logic. The public extension description gives no usable answer. 2
Configuration maintenance and the productivity evidence
New Balance’s September 2026 integration-analyst vacancy provides a useful description of the customer’s work. It identifies a migration from IBM Sterling EDI and Cleo Harmony MFT to PartnerLinQ, including use of its AI Mapping Agent. Responsibilities include configuring maps and rules, testing with production examples, promoting tested artifacts between environments, onboarding partners, and handling production issues. 11
This is substantive evidence that an agent participates in a real implementation. It also shows why configuration is software maintenance. Generated mappings still need validation against business requirements; dependencies must survive promotion; a partner’s later change can invalidate a previously correct configuration. Reusable assets can lower that cost, but continuing ownership remains necessary.
The testing and promotion responsibilities are particularly relevant. They provide a more credible operating model than an unqualified promise that no-code configuration removes engineering. Total ownership cost must include that customer team, partner coordination, implementation services, and recurring troubleshooting alongside the subscription.
Wayfair’s case study reports that its transition began in 2024 and reduced supplier-onboarding time by more than 85%. Its named support executive describes fewer EDI problems and improved uptime after replacing a highly customized internal platform. The case also distinguishes future expansion and integration ambitions from completed work. 12
Those are relevant outcomes for the integration product. However, elapsed onboarding time is not the same as labor removed, and the case provides neither a staffing baseline nor a net cost calculation. It also does not attribute the reported gain specifically to the current agent framework. The credible conclusion is narrower: a named customer reports a substantial improvement in integration operations.
An unnamed food distributor case describes replacing VAN traffic with direct AS2/SFTP connections where possible, retaining VAN support for remaining partners, and onboarding over 400 partners within weeks. It reports more than 400,000 transactions annually. The savings mechanism is understandable: fewer intermediary charges and conversions. The case supplies no before-and-after cost series. 13
The Collected Group case combines PartnerLinQ with a Dynamics replacement, Visionet implementation, additional fashion software, and business intelligence. It reports lower inventories and costs without figures. That package cannot identify the incremental return of PartnerLinQ’s planning logic. 14
Technology history: continuity in integration, inflation in autonomy
| Period | Public commitment | What can be assessed |
|---|---|---|
| March 2020 | Visionet’s launch announcement couples Azure integration with AI-powered analytics and intelligent automation. | The announcement describes connectivity and transaction scale, but no evaluated AI decision mechanism. |
| January 2022 | A native app ecosystem and “intelligent hyper-automation” promise greater resilience. | The disclosed mechanism remains message processing and automated workflows. |
| 2023 onward | PartnerLinQ becomes a separate business and expands its decision-intelligence positioning. | Brochures introduce ML, digital twins, and control towers without documenting forecast calibration or decision economics. |
| 2024 deployment, current case study | Wayfair replaces its internal EDI platform. | Named operational evidence supports the integration proposition. |
| Current offering | LinQ.IQ and MCP are presented as an autonomous enterprise framework. | Specific setup and monitoring functions are described; end-to-end economic autonomy remains unsupported. |
The dated announcements, company account, brochure, and current product materials establish this progression. 15 16 17 19 4
The pre-2023 announcements identify automated message processing, but provide no contemporary evaluation of autonomous planning judgments. The later Wayfair deployment supplies a measured customer outcome for the integration product.
PartnerLinQ has itself published a lengthy criticism of blockchain and generative-AI hype in traceability, arguing that reliable transaction records and business processes do the essential work. 18 That reasoning applies directly to its MCP proposition. Standard access cannot substitute for validated semantics, complete event capture, or sound decisions. Presenting the new protocol as removing the old integration burden conflicts with the vendor’s more grounded account of what makes traceability work.
The digital-twin language has a similar evidentiary gap. A descriptive representation can organize records; a predictive representation must be tested on the future states it claims to anticipate. The brochure does not identify that evaluation. A richer representation does not make uncertainty disappear, and a detailed but inaccurate projection can spread mistakes across more connected decisions. 19
Economic accountability and model revision
PartnerLinQ offers some measurable starting points: warehouse labor-cost baselines, partner-onboarding time, transaction volumes, and integration incidents. These are useful for testing specific capabilities. They do not establish a common economic contract for the wider promise of autonomous supply chain improvement.
The necessary attribution follows control. The vendor supplies processing and recommendation mechanisms; customers and implementation teams define mappings, rules, objectives, and execution policies. A review of disappointing returns should identify which part failed, what changes, and who performs the repair. The public cases do not define a net-return failure threshold or a remediation obligation.
Holimization supplies the relevant test for the decision applications. If a staffing plan repeatedly fails because workload categories hide congestion, changing solver settings is insufficient. If carrier selections look economical but increase costly disruptions, adjusting a generic reliability weight may only conceal the bad model. The product must support revising the representation, testing alternatives on historical situations, and checking subsequent results.
PartnerLinQ documents transaction replay and forecast versions. Those capabilities help recover processing and compare planning states. The missing public demonstration is a complete revision of the economic decision model with controlled validation before production. Operational observability is valuable, but seeing which transaction failed is only the beginning of understanding why a technically successful decision lost money.
Supply chain score
Supply chain depth
| Criterion | Score |
|---|---|
| Economic framing | 4/10 |
| Decision end-state | 6/10 |
| Conceptual sharpness on supply chain | 5/10 |
| Freedom from obsolete doctrinal centerpieces | 2/10 |
| Robustness against KPI theater | 3/10 |
Average: 4.0/10
Economic framing — 4/10. Labor-cost calibration and carrier margins provide local economic inputs. The application descriptions do not explain how competing decisions share a common expected-profit objective. 7 8
Decision end-state — 6/10. Document routing and scheduling have executable outputs. Much of the planning proposition still ends in quantities, recommendations, and exceptions requiring another policy to determine the commercial action. 1 2
Conceptual sharpness on supply chain — 5/10. Partner-specific document semantics and operational constraints receive concrete treatment. The transition from reliable records to economically justified decisions is poorly specified. 1 8
Freedom from obsolete doctrinal centerpieces — 2/10. Consensus forecasts and approval queues preserve the traditional planning organization. Faster corrections do not remove the recurring reconciliation burden. 2
Robustness against KPI theater — 3/10. The Wayfair result concerns a relevant integration outcome, but neither that case nor the sensing proposition establishes net economic improvement at a defined workload and cost. 12 6
Decision and optimization substance
| Criterion | Score |
|---|---|
| Probabilistic modeling depth | 1/10 |
| Distinctive optimization or ML substance | 3/10 |
| Real-world constraint handling | 6/10 |
| Decision automation and labor productivity | 5/10 |
| Resilience under real operational complexity | 3/10 |
Average: 3.6/10
Probabilistic modeling depth — 1/10. The reviewed planning descriptions do not specify calibrated demand and supply distributions feeding a joint decision calculation. Forecast revisions cannot supply the missing risk valuation. 2 6
Distinctive optimization or ML substance — 3/10. Scheduling and carrier recommendation have identifiable inputs and purposes. Their algorithms, comparative results, and computational limits remain undisclosed. 7 8
Real-world constraint handling — 6/10. Explicit operational restrictions make the local applications more credible than unconstrained recommendations. Their cross-application interactions remain unresolved in public documentation. 7 1
Decision automation and labor productivity — 5/10. Customer evidence supports faster integration operations and actual agent-assisted implementation. Total recurring labor, including the specialists maintaining the configuration, is not measured. 11 12
Resilience under real operational complexity — 3/10. Replay and editable planning states support operational correction. A demonstrated process for diagnosing and replacing inadequate economic models is missing. 1 2
Product and architecture integrity
| Criterion | Score |
|---|---|
| Architectural coherence | 6/10 |
| System-boundary clarity | 6/10 |
| Security seriousness | 3/10 |
| Software parsimony and ownership cost | 4/10 |
| Compatibility with programmatic and agent-assisted operations | 5/10 |
Average: 4.8/10
Architectural coherence — 6/10. The processing chain, common representations, and orchestration have understandable roles. The numerical relationship between the planning applications is less clear. 1 3
System-boundary clarity — 6/10. The connector exposes a specific integration contract, and customer cases identify surrounding applications. The wider autonomy claim obscures who owns the decision logic between those systems. 9 14
Security seriousness — 3/10. Inspectable connector authentication reveals concrete boundaries and credential-handling concerns. Public agent and extension material does not demonstrate containment or recovery under compromise. 10 2
Software parsimony and ownership cost — 4/10. Replacing legacy gateways can simplify operations. Customer implementation evidence shows a continuing configuration and testing workload, without a total cost comparison. 11 13
Compatibility with programmatic and agent-assisted operations — 5/10. Published APIs and agent functions support automation. An interface to tools leaves business semantics and economically sound policy to other layers. 9 5
Technical transparency
| Criterion | Score |
|---|---|
| Public technical documentation | 5/10 |
| Inspectability without vendor mediation | 5/10 |
| Portability and lock-in visibility | 4/10 |
| Implementation-method transparency | 6/10 |
| Evidence density behind technical claims | 4/10 |
Average: 4.8/10
Public technical documentation — 5/10. EDI mechanics and a connector schema are accessible. Decision algorithms and important infrastructure dependencies remain opaque. 1 10
Inspectability without vendor mediation — 5/10. Readers can examine the integration contract and compare it with product claims. They cannot reproduce the planning results from the published descriptions. 10 8
Portability and lock-in visibility — 4/10. Standard document formats lower transport dependence. The public material does not establish portability of customer rules, mappings, semantic definitions, and agent behavior as an executable whole. 1 11
Implementation-method transparency — 6/10. The implementation responsibilities are concrete enough to assess the work required. Effort and failure rates across projects remain unknown. 11 7
Evidence density behind technical claims — 4/10. Named integration evidence is materially stronger than the evidence for forecasting, digital twins, or autonomous decision-making. Their breadth exceeds the disclosed mechanisms and evaluations. 12 19
Vendor seriousness
| Criterion | Score |
|---|---|
| Technical seriousness of public communication | 3/10 |
| Technology roadmap integrity | 5/10 |
| Conceptual sharpness | 5/10 |
| Economic accountability | 4/10 |
| Defensibility in an agentic-software world | 4/10 |
Average: 4.2/10
Technical seriousness of public communication — 3/10. Claims of unrestricted solver scaling and protocol-driven elimination of integration complexity exceed the supplied evidence. The more precise operational descriptions are easier to assess. 7 4
Technology roadmap integrity — 5/10. The historical connectivity proposition has a documented customer continuation. Successive intelligence labels lack an equally clear delivery record for economic decision automation. 15 16 12
Conceptual sharpness — 5/10. The traceability essay correctly locates the hard work in records and processes. The current autonomy narrative does not consistently preserve that distinction. 18 4
Economic accountability — 4/10. Specific operational baselines are possible, but published outcomes do not isolate full costs or define responsibility for failed economic returns. Bundled transformations further weaken attribution. 7 14
Defensibility in an agentic-software world — 4/10. Reliable partner implementations and maintained semantics can retain value. Conversational access and generated setup artifacts are easier to reproduce; their durability depends on demonstrably lower maintenance and decision costs. 1 5
Sources
B2B/EDI Connectivity. Current vendor description of validation, acknowledgements, business rules, monitoring, and replay. Accessed November 4, 2026.
[2] Demand Forecasting Control Tower
Demand Forecasting Control Tower. Current planning features, corrections, approval processes, and extension model. Accessed November 4, 2026.
[3] PartnerLinQ platform architecture
PartnerLinQ platform architecture. Current architectural roles and stated security boundaries. Accessed November 4, 2026.
PartnerLinQ + MCP. Public whitepaper describing MCP participation and claiming broad integration and autonomy benefits. Accessed November 4, 2026.
[5] B2B/EDI Integration Agents
B2B/EDI Integration Agents. Current integration-agent functions and approval model. Accessed November 4, 2026.
[6] Demand Sensing Control Tower
Demand Sensing Control Tower. Current short-horizon forecast and inventory workflow description. Accessed November 4, 2026.
Warehouse Labor Optimizer. Current staffing formulation, implementation baseline, and scalability claim. Accessed November 4, 2026.
[8] Carrier Selection Recommendation
Carrier Selection Recommendation. Current carrier recommendation inputs and adjustable criteria. Accessed November 4, 2026.
[9] Microsoft: PartnerLinq connector (Preview)
Microsoft: PartnerLinq connector (Preview). Current Microsoft-hosted connector documentation, including authentication, operations, and throttling. Accessed November 4, 2026.
[10] Microsoft PowerPlatformConnectors: PartnerLinq API definition
Microsoft PowerPlatformConnectors: PartnerLinq API definition. API definition pinned to commit 32fb330ca4ccdf554bb9673624035eab3a945b14, dated February 15, 2023. Accessed November 4, 2026.
[11] New Balance: Integration Analyst R41253
New Balance: Integration Analyst R41253. Employer-hosted public job data, posted September 25, 2026; specifies actual implementation responsibilities. Accessed November 4, 2026.
[12] Wayfair and PartnerLinQ case study
Wayfair and PartnerLinQ case study. Vendor-hosted case study with a named Wayfair executive and a transition beginning in 2024. Accessed November 4, 2026.
[13] Global Food Distributor Transforms B2B
Global Food Distributor Transforms B2B. Vendor-hosted customer case describing connection migration and transaction volumes. Accessed November 4, 2026.
[14] The Collected Group case study
The Collected Group case study. Vendor-hosted case covering a combined Dynamics, PartnerLinQ, and Visionet transformation. Accessed November 4, 2026.
[15] Visionet launches PartnerLinQ
Visionet launches PartnerLinQ. Visionet announcement dated March 10, 2020 in its body; the page also carries a later submission timestamp. Accessed November 4, 2026.
[16] PartnerLinQ Offers First-to-Market Digitally Optimized Supply Chain Integration System
PartnerLinQ Offers First-to-Market Digitally Optimized Supply Chain Integration System. Visionet press release, January 19, 2022. Accessed November 4, 2026.
[17] Leading the Future of Supply Chain Management Technology
Leading the Future of Supply Chain Management Technology. Company account of its separation from Visionet in 2023. Accessed November 4, 2026.
[18] How Traceability Systems are Powered by Traceability Data
How Traceability Systems are Powered by Traceability Data. Vendor essay criticizing technology panaceas in traceability; publication date is not established here. Accessed November 4, 2026.
[19] The Platform for Orchestrating Change in Modern Supply Chains
The Platform for Orchestrating Change in Modern Supply Chains. Vendor brochure describing company origins, architecture, and decision-intelligence ambitions. Accessed November 4, 2026.
[20] PartnerLinQ: Product Engineer – AI-Native SaaS
PartnerLinQ: Product Engineer – AI-Native SaaS. Employer-authored product-engineering vacancy, available when reviewed. Accessed November 4, 2026.