Inspiration
Modern GTM teams have more data, enrichment, scraping, CRM automation, and outbound infrastructure than ever.
But most of those systems become useful only after someone has already decided what deserves attention: which account, customer complaint, hiring signal, technical issue, market change, or opportunity should trigger action.
That creates a missing layer between market evidence and execution.
SignalOps was originally built as a policy-driven workbench for that layer. Its job is to preserve exactly what was observed, keep observation separate from interpretation, score relevance, enforce permission boundaries, and persist the resulting action state.
Before the SerpApi integration, we had already run the deterministic SignalOps layer against 20 real public LangChain GitHub issue surfaces:
- 20 surfaces processed
- 20 durable events created
- 19 routed to
public_reply - 1 routed to
save - 0 routed to DM
- 0 routed to call
That test demonstrated an important property of the system: high relevance does not automatically grant permission to take a higher-risk action. Even a high-scoring signal could not bypass policy. Private escalation required prior public engagement.
The limitation was that evidence still had to be supplied to SignalOps manually.
That became the hackathon opportunity: connect a live search layer to the deterministic decision system without collapsing raw evidence, AI interpretation, and execution policy into one opaque workflow.
What it does
SignalOps × SerpApi turns live public-web evidence into policy-governed action decisions.
The complete workflow is:
live SerpApi result
→ provenance-bearing observed evidence
→ separate bounded AI inference
→ deterministic SignalOps policy
→ durable external identity
→ append-only outcome receipt
SerpApi is responsible for acquiring fresh public evidence.
SignalOps then preserves the original observation separately from any AI-generated interpretation. The AI layer can classify, summarize, or infer relevance, but it does not get final authority over what action is allowed.
That decision remains deterministic and policy-driven.
For every signal, the system can answer questions such as:
- What exactly did we observe?
- Where did the evidence come from?
- What did the model infer from it?
- How relevant is it?
- What actions are permitted?
- Has this entity already been seen?
- What decision was ultimately made?
- Can we reconstruct that decision later?
Instead of turning search results directly into outreach, SignalOps creates a durable, auditable decision trail between evidence and execution.
How we built it
We designed the system around a strict separation of concerns.
1. Live evidence acquisition
SerpApi retrieves live public search results and gives SignalOps a structured source of external evidence.
Each observation is stored with provenance so that the system retains the original evidence rather than only keeping an AI-produced summary.
2. Observation and inference are stored separately
The raw observation is treated as a fact about what the system encountered.
AI interpretation is stored as a separate bounded inference layer.
This distinction matters because an inferred statement such as “this account may have a technical pain point” is fundamentally different from the observed evidence that produced that conclusion.
SignalOps preserves both.
3. AI interprets; policy decides
The model can help classify the evidence, extract useful context, and estimate relevance.
It cannot independently authorize actions.
The resulting structured signal is passed into the deterministic SignalOps policy engine, where explicit rules determine whether the appropriate state is something like:
save
public_reply
dm
call
Permission constraints remain enforceable regardless of model confidence or signal score.
4. Durable identity and deduplication
Signals receive durable external identities so the system can recognize repeated observations of the same underlying entity or event rather than treating every search result as a brand-new opportunity.
This creates state across runs and makes the workflow useful as an operational system rather than a one-shot AI demo.
5. Append-only outcome receipts
Every resulting decision is persisted as an append-only outcome receipt.
That gives us an audit trail showing what evidence entered the system, how it was interpreted, what policy was applied, and what action state resulted.
The final architecture keeps search, interpretation, policy, identity, and persistence distinct instead of hiding them inside a single agent prompt.
Challenges we ran into
The hardest problem was not retrieving search results or asking an LLM to interpret them.
It was deciding what the model should be allowed to influence.
A naive implementation could take a SerpApi result, ask an LLM whether it looks promising, and immediately trigger outreach. That is easy to build, but it makes the model responsible for evidence interpretation, business relevance, permission, and action selection all at once.
We wanted the opposite.
We had to preserve a clean boundary between:
- observed facts and inferred meaning
- relevance and permission
- discovery and execution
- new evidence and previously seen entities
- model judgment and deterministic policy
Another challenge was making live web evidence durable. Search results are transient, rankings change, and the same underlying signal can appear through multiple surfaces. We therefore needed provenance and external identity to be first-class parts of the system.
We also had to resist making the AI layer too powerful. The most useful architecture turned out to be one where AI provides structured interpretation while deterministic code retains final control over operational decisions.
Accomplishments that we're proud of
We are especially proud that the SerpApi integration extends SignalOps without weakening its original guarantees.
The system now begins with live market evidence instead of manually supplied inputs, while still preserving the separation between observation, inference, and permission.
We also validated the underlying policy engine on real public data before adding the search integration. Across 20 public LangChain GitHub issue surfaces, SignalOps produced:
- 20 durable events
- 19
public_replydecisions - 1
savedecision - 0 DMs
- 0 calls
Those results showed that the policy layer behaves independently from raw relevance. A strong signal is not automatically permission for aggressive outreach.
We are also proud that every decision leaves behind a durable receipt. SignalOps is not just producing an answer in a chat window; it is building operational memory that can be inspected, replayed, and audited.
Most importantly, the project demonstrates a different role for AI in GTM infrastructure: not an autonomous system that decides everything, but a bounded interpretation layer inside a deterministic operational system.
What we learned
The biggest lesson was that finding a signal and being allowed to act on it are two different problems.
Modern AI systems are very good at interpreting messy external information, but interpretation alone is not enough for reliable operational automation.
We learned that useful AI systems need explicit boundaries around what was observed, what was inferred, and what actions are permitted.
We also learned that provenance becomes much more important once live search enters the system. When evidence comes from the open web, retaining the source and original observation is essential for debugging, trust, and later review.
Another lesson was that deterministic systems and AI systems are complementary rather than competing approaches.
AI is valuable where ambiguity exists: understanding language, classifying context, and extracting meaning.
Deterministic policy is valuable where consistency matters: permissions, routing rules, state transitions, deduplication, and auditability.
SerpApi gave SignalOps the missing acquisition layer. The result is a system that can move from live evidence to bounded interpretation to policy-governed action without treating an LLM output as the final source of truth.
Built With
- agentic-ai
- ai-agents
- api-integration
- decision-systems
- docker
- fastapi
- github
- github-actions
- google-cloud
- google-cloud-run
- gpt-5.6
- gtm
- market-intelligence
- oidc
- openai-responses-api
- provenance
- pytest
- python
- responsible-ai
- rest-api
- serpapi
- sqlite
- state-machines
- workflow-automation
- workload-identity-federation
Log in or sign up for Devpost to join the conversation.