TL;DR
EAMOS (Enterprise Agentic Meeting Operating System) is a factory that interviews you and renders the fully governed material and the regie for an enterprise meeting β a board deck, a read-alone pre-read, an infographic, a KPI table, a mind map, an interview quiz, a target-architecture diagram, plus the facilitation agenda / script / minutes. Everything is gate-enforced, grounded, and human-gated: it frames and structures, it does not fabricate β missing data is rendered labeled (β¨β¦ β to verifyβ©) and collected into a review appendix.
It covers 7 meeting archetypes (review/QBR Β· decision/steering Β· post-mortem Β· planning Β· retrospective Β· discovery Β· 1:1) Γ audience-altitude / function / company-context overlays, projected into 7 deliverable IR families from one grounded source. Phase pipeline: intake β structure β draft β review β facilitate β follow-up. EAMOS is the second instance of the EADOS pattern β same machine, different output (meeting material, not repositories).
We have just shipped v0.1.0 and we are now actively looking for testers and feedback. If you run enterprise meetings, care about decision rigor / agentic workflows / reproducible deliverables, we would love to have you kick the tires and tell us what breaks, what confuses you, and what is missing.
π Language: this issue is in English to reach the widest audience, but you are welcome to reply in any language. EAMOS itself separates three languages β the interview runs in the maintainer's language, the deliverables render in a chosen output_lang, and system artifacts stay English on disk β so multilingual feedback is right at home.
π Access (pre-GTM): the repository is currently private. While it is, the release downloads below require repo access β ping here to be added as a collaborator. The public curl | sh install activates when the repository is made public (a separate go-to-market decision).
Why this issue exists
EAMOS has reached a level of maturity (M1βM8 + Hardening delivered, the full Solution-Discovery capability, a guided cross-platform installer, 8 structural gates, a dependency-free 49-test suite) where the most valuable thing we can get is real-world usage by people who are not the author. Automated tests and a single maintainer's dogfooding only go so far. We want to know how EAMOS behaves:
- on operating systems and shells we do not use daily;
- across archetypes, function packs, and output languages we have not exercised end-to-end;
- in the hands of someone reading the docs for the first time, with no prior context.
Your friction is our roadmap.
Who we are looking for
You do not need to be an expert in the project. We specifically want a mix of:
- π§ͺ First-time users β you have never seen EAMOS before. Your "I got stuck here" moments are gold.
- π’ Enterprise facilitators & architects β you run QBRs, steering/decision meetings, post-mortems, retros. Judge whether the rendered deck/pack is right for your meeting and your audience altitude (C-level / VP / manager / IC).
- π€ Agentic-workflow practitioners β you run Claude Code, Cursor, Codex, Gemini or similar and can tell us whether the
AGENTS.md contract actually steers your agent to prepare a meeting well.
- πͺππ§ Cross-platform testers β Windows (PowerShell/CMD), macOS, Linux. The installer ships for all three; we want it verified on all three.
- π Multilingual reviewers β render a deck in a non-English
output_lang and tell us whether the localization holds up.
- π Docs & onboarding reviewers β you read README / AGENTS.md / CLAUDE.md and tell us where the explanation falls down.
What we would love you to test
Pick one or more β you do not have to do all of them.
1. The guided installer (cross-platform)
The installer downloads the governed factory bundle into a repository. It is fail-closed: it verifies the release SHA256SUMS before extracting and refuses an unverified bundle (no blind curl | sh), and it is additive / no-clobber.
# macOS / Linux
curl -fsSL https://github.com/danielPoloWork/pgs-eamos/releases/latest/download/setup.sh -o setup.sh && sh setup.sh
# Windows (PowerShell) β or double-click setup.bat from the release
Invoke-WebRequest https://github.com/danielPoloWork/pgs-eamos/releases/latest/download/setup.ps1 -OutFile setup.ps1; powershell -ExecutionPolicy Bypass -File setup.ps1
What to report: Did it run on your OS/shell? Was the checksum verification clear? Did it clobber anything it shouldn't? Were the messages understandable? Any UnicodeEncodeError / mojibake on your console? (We hit exactly this on a Windows cp1252 console β extra-curious whether you do too.)
2. Preparing a meeting for your context
Run the interview and prepare a real meeting: pick an archetype (review/QBR, decision/steering, post-mortem, planning, retrospective, discovery, 1:1), an altitude (c-level / vp / manager / ic), a function pack (finance / engineering / pre-work), and an output language; then render the bundle (render.py β emit_md / emit_pptx / emit_docx / emit_svg / emit_xlsx). The deterministic core (emit_md / emit_svg) needs no dependencies; the .pptx / .docx / .xlsx hops are the cosmetic last step.
What to report: Is the structure right for that meeting type and altitude? Does it say too much / too little for the audience? Are missing facts clearly labeled and collected into the review appendix β never silently invented? Anything an enterprise meeting in your world would need that's missing?
3. The deliverable families & grounding
The same grounded content projects into 7 IR families β deck, read-alone pre-read, infographic, KPI table, mind map, interview quiz, and the target-architecture (topology) diagram.
What to report: Does a value stay identical across every projection (deck vs pre-read vs table)? Does the computed weighted-scorecard total add up (it's deterministic, formula-free)? Does the topology diagram read like a real systems-and-integrations picture?
4. The Solution-Discovery / vendor-selection capability
Drive a build-vs-buy decision end-to-end: capability-first intake (L0/L1/L2 + a problem classification + an adaptive question tree that goes deeper only when warranted) β the pre-work pack (use-case matrix Β· MoSCoW Β· architectural constraints) β the computed scorecard β the no-action baseline β the Phase-G decision contract (residual risks + next step) β the topology diagram β the advisor (tools/advisor.py: deterministic pattern matching over past decisions + what-if scorecard simulation).
What to report: Does the flow feel like a real procurement decision? Does the adaptive questioning ask the right depth? Does what-if change the ranking in a way that makes sense?
5. Facilitation & follow-up (the regie + the moat)
facilitate.py prep produces a timeboxed agenda + a facilitation script grounded from the deck (with the RACI roster and the discovery-decision timebox template); facilitate.py followup turns human-captured outcomes into minutes + a decision log + action items and carries them into the series store so the next instance opens knowing the last one's decisions, open actions, and KPI movement.
What to report: Could you actually run the room from prep? Does followup produce usable minutes? Does the next instance inherit the previous one's decisions/actions (the moat)?
6. Driving an AI agent with the contract
Open EAMOS with your agent of choice (Claude Code, Cursor, etc.) and let it prepare a meeting under AGENTS.md.
What to report: Did the agent respect the contract β confirm the manifest before rendering (manifest-confirmed), human-runs-the-room (it never invents the room's outcomes), the gates, branch / Conventional-Commits / one-PR-at-a-time discipline, never pushing to the default branch? Where did it go off the rails? Which model did you use? (Anecdotally we've seen the strongest adherence with high-capability models β your data points help.)
7. Docs & onboarding
Read the README, AGENTS.md, and CLAUDE.md cold and try to prepare a meeting without asking us anything.
What to report: Where did you get stuck? What did you have to guess? What did you expect to find and didn't?
How to give feedback
The lowest-friction path is best. In rough order of preference:
- π¬ Comment on this issue β even a one-liner ("installer worked on Fedora 40, zsh, no problems") is genuinely useful.
- π Open a separate issue for a concrete bug or feature request, and link it here.
- π If you want to contribute a change, note that EAMOS is owner-governed (
AGENTS.md Β§6, CONTRIBUTING.md): anyone β human or agent β may propose; the owner reviews, decides, and merges; nothing is pushed to the default branch and you are always credited. So please do propose things.
Suggested feedback template (copy/paste into a comment)
**Tester profile:** (first-time / facilitator / agent user / docs reviewer / multilingual)
**OS & shell:** (e.g. Windows 11 / PowerShell 7, macOS 14 / zsh, Ubuntu 24.04 / bash)
**What I tried:** (installer / meeting for <archetype> Γ <altitude> Γ <function> / output_lang <xx> /
agent run with <tool + model> / facilitation / docs)
**What worked:**
-
**What broke or confused me:**
-
**What I expected vs. what happened:**
-
**Severity for me:** (blocker / annoying / cosmetic / just a note)
**Would I use this again?** (yes / no / maybe β why)
Scope & expectations
- This is a call for evaluation, not a support contract β but we read everything and respond.
- No feedback is too small. "The README's third paragraph lost me" is as valuable as a stack trace.
- Negative feedback is especially welcome. We would rather hear it here than never hear it.
- Please be specific where you can: OS, shell, archetype, altitude, function pack,
output_lang, model, and the exact command β it helps us reproduce.
Getting started in 30 seconds
- π¦ Latest release: https://github.com/danielPoloWork/pgs-eamos/releases/latest
- π Docs: README Β·
AGENTS.md (the agent contract) Β· CLAUDE.md
- π§ What is EAMOS? A factory that reproduces the governed material and the regie for an enterprise meeting across 7 archetypes and 7 deliverable families β deterministic, grounded, human-gated β evolving into a phase-based meeting operating system.
Thank you for spending your time on this β every report, however short, directly shapes where EAMOS goes next. π
TL;DR
EAMOS (Enterprise Agentic Meeting Operating System) is a factory that interviews you and renders the fully governed material and the regie for an enterprise meeting β a board deck, a read-alone pre-read, an infographic, a KPI table, a mind map, an interview quiz, a target-architecture diagram, plus the facilitation agenda / script / minutes. Everything is gate-enforced, grounded, and human-gated: it frames and structures, it does not fabricate β missing data is rendered labeled (
β¨β¦ β to verifyβ©) and collected into a review appendix.It covers 7 meeting archetypes (review/QBR Β· decision/steering Β· post-mortem Β· planning Β· retrospective Β· discovery Β· 1:1) Γ audience-altitude / function / company-context overlays, projected into 7 deliverable IR families from one grounded source. Phase pipeline: intake β structure β draft β review β facilitate β follow-up. EAMOS is the second instance of the EADOS pattern β same machine, different output (meeting material, not repositories).
We have just shipped v0.1.0 and we are now actively looking for testers and feedback. If you run enterprise meetings, care about decision rigor / agentic workflows / reproducible deliverables, we would love to have you kick the tires and tell us what breaks, what confuses you, and what is missing.
Why this issue exists
EAMOS has reached a level of maturity (M1βM8 + Hardening delivered, the full Solution-Discovery capability, a guided cross-platform installer, 8 structural gates, a dependency-free 49-test suite) where the most valuable thing we can get is real-world usage by people who are not the author. Automated tests and a single maintainer's dogfooding only go so far. We want to know how EAMOS behaves:
Your friction is our roadmap.
Who we are looking for
You do not need to be an expert in the project. We specifically want a mix of:
AGENTS.mdcontract actually steers your agent to prepare a meeting well.output_langand tell us whether the localization holds up.What we would love you to test
Pick one or more β you do not have to do all of them.
1. The guided installer (cross-platform)
The installer downloads the governed factory bundle into a repository. It is fail-closed: it verifies the release
SHA256SUMSbefore extracting and refuses an unverified bundle (no blindcurl | sh), and it is additive / no-clobber.What to report: Did it run on your OS/shell? Was the checksum verification clear? Did it clobber anything it shouldn't? Were the messages understandable? Any
UnicodeEncodeError/ mojibake on your console? (We hit exactly this on a Windows cp1252 console β extra-curious whether you do too.)2. Preparing a meeting for your context
Run the interview and prepare a real meeting: pick an archetype (review/QBR, decision/steering, post-mortem, planning, retrospective, discovery, 1:1), an altitude (c-level / vp / manager / ic), a function pack (finance / engineering / pre-work), and an output language; then render the bundle (
render.pyβemit_md/emit_pptx/emit_docx/emit_svg/emit_xlsx). The deterministic core (emit_md/emit_svg) needs no dependencies; the.pptx/.docx/.xlsxhops are the cosmetic last step.What to report: Is the structure right for that meeting type and altitude? Does it say too much / too little for the audience? Are missing facts clearly labeled and collected into the review appendix β never silently invented? Anything an enterprise meeting in your world would need that's missing?
3. The deliverable families & grounding
The same grounded content projects into 7 IR families β deck, read-alone pre-read, infographic, KPI table, mind map, interview quiz, and the target-architecture (topology) diagram.
What to report: Does a value stay identical across every projection (deck vs pre-read vs table)? Does the computed weighted-scorecard total add up (it's deterministic, formula-free)? Does the topology diagram read like a real systems-and-integrations picture?
4. The Solution-Discovery / vendor-selection capability
Drive a build-vs-buy decision end-to-end: capability-first intake (L0/L1/L2 + a problem classification + an adaptive question tree that goes deeper only when warranted) β the pre-work pack (use-case matrix Β· MoSCoW Β· architectural constraints) β the computed scorecard β the no-action baseline β the Phase-G decision contract (residual risks + next step) β the topology diagram β the advisor (
tools/advisor.py: deterministic pattern matching over past decisions + what-if scorecard simulation).What to report: Does the flow feel like a real procurement decision? Does the adaptive questioning ask the right depth? Does what-if change the ranking in a way that makes sense?
5. Facilitation & follow-up (the regie + the moat)
facilitate.py prepproduces a timeboxed agenda + a facilitation script grounded from the deck (with the RACI roster and the discovery-decision timebox template);facilitate.py followupturns human-captured outcomes into minutes + a decision log + action items and carries them into the series store so the next instance opens knowing the last one's decisions, open actions, and KPI movement.What to report: Could you actually run the room from
prep? Doesfollowupproduce usable minutes? Does the next instance inherit the previous one's decisions/actions (the moat)?6. Driving an AI agent with the contract
Open EAMOS with your agent of choice (Claude Code, Cursor, etc.) and let it prepare a meeting under
AGENTS.md.What to report: Did the agent respect the contract β confirm the manifest before rendering (
manifest-confirmed), human-runs-the-room (it never invents the room's outcomes), the gates, branch / Conventional-Commits / one-PR-at-a-time discipline, never pushing to the default branch? Where did it go off the rails? Which model did you use? (Anecdotally we've seen the strongest adherence with high-capability models β your data points help.)7. Docs & onboarding
Read the README,
AGENTS.md, andCLAUDE.mdcold and try to prepare a meeting without asking us anything.What to report: Where did you get stuck? What did you have to guess? What did you expect to find and didn't?
How to give feedback
The lowest-friction path is best. In rough order of preference:
AGENTS.mdΒ§6,CONTRIBUTING.md): anyone β human or agent β may propose; the owner reviews, decides, and merges; nothing is pushed to the default branch and you are always credited. So please do propose things.Suggested feedback template (copy/paste into a comment)
Scope & expectations
output_lang, model, and the exact command β it helps us reproduce.Getting started in 30 seconds
AGENTS.md(the agent contract) Β·CLAUDE.mdThank you for spending your time on this β every report, however short, directly shapes where EAMOS goes next. π